Tags:
create new tag
, view all tags

WebDAVPluginDev Discussion: Page for developer collaboration, enhancement requests, patches and improved versions on WebDAVPlugin contributed by the TWikiCommunity.
• Please let us know what you think of this extension.
• For support, check the existing questions, or ask a new support question in the Support web!
• Please report bugs below

Feedback on WebDAVPlugin

-- CrawfordCurrie - 14 Apr 2004

More work will be done and released to the community. We (my daytime workplace) asked Crawford to work on this.

-- PeterThoeny - 15 Apr 2004

I understand that AndreaSterbini was also working on webdav - can you Peter give us an update as to whether and how the initiatives are related?

-- MartinCleaver - 15 Apr 2004

Sure. AndreaSterbini and FrancoBagnoli have attacked it from a different angle, and developed a modified SessionManager that caches the protections from the TWiki topics into a MySQL database. These protections are then used in determining access rights to topics. The DB cache is necessary because dynamic access to TWiki protections is too slow for an Apache server. I have a copy of Franco's code, but have been unable to get it working so far, though I haven't tried too hard.

Andrea and Franco have not addressed the problem of versioning, and this is where twiki_dav kicks in. Standard mod_dav is a class 2 DAV server, which means it handles most of the DAV protocol, but none of the DeltaV protocol for version control (see http://webdav.org/ for more info). twiki_dav is still a class 2 server, but it knows about TWiki topics and attachments being under VCS control, and is able to invoke TWiki scripts to correctly check-in modified files. twiki_dav also knows a bit about protections, and I have a version that will invoke TWiki scripts to check permissions before permitting a GET on a file arrived at though a specific DAV URL. I don't think this is practical, however, due to the poor perfomance of such permission checks, and will probably have to turn to Andrea and Franco's solution.

-- CrawfordCurrie - 15 Apr 2004

The latest version, just uploaded, has transmogrified into a plugin - the Addon label is only marginally applicable, this is a plugin that happens to ship with an additional Apache module wink

Now supports cacheing of protections - thanks to FrancoBagnoli and AndreaSterbini for the ideas on this. This means that DAV browsing on attachment directories is now access-controlled. Come to that, a minor extension would allow it to be used to let Apache check protections on any files in the tree, which in turn would mean you could switch off TWiki's internal protections scheme (which is cumbersome and slow IMHO)

-- CrawfordCurrie - 19 Apr 2004

I renamed the topics to preserve the attachments and the revision history.

Crawford, small detail, but how about naming the Plugin WebDavPlugin instead of WebDAVPlugin? That way the word boundaries are more clear.

-- PeterThoeny - 20 Apr 2004

Thanks Peter! Small details are always important, and I did agonise over that one. But "DAV" is a TLA - standing for "Distributed Authoring and Versioning" and I thought in the end it was better to be consistent in it's use. In a way, we should consider it fortuitous that http://www.webdav.org/ chose a wikiword for their name!

-- CrawfordCurrie - 21 Apr 2004

Am looking forward to trying this - way too busy at present. One thing I noticed in XP today "Publish this file to the web" on the "File and folder tasks" (the default "Explorer Bar" on the left hand side).

It turns out that this invokes a HTTP Post from the Windows Shell. If you have Yahoo Messenger installed it contains a feature to send to Yahoo Briefcase, i.e. nice integration from windows shell to a http post.

Back end details are here: http://msdn.microsoft.com/library/default.asp?url=/workshop/management/tools/overview.asp

-- MartinCleaver - 24 Apr 2004

Instructions on installing this plugin mention httpd.conf, apache configuration, directive with TWikiDir. Starting up apache with this directive causes error. ./apachectl configtest yields:
Invalid command 'TWikiDir', perhaps mis-spelled or defined by a module not included in the server configuration

Please assist.

-- CharlieSmith - 05 May 2004 - 13:25

You need to have the apache module built and installed, as per the instructions, or apache will not see it. Read the instructions, and follow them carefully.

-- CrawfordCurrie - 06 May 2004

Also see http://www.netmag.co.uk/ie5/default.htm

-- MartinCleaver - 25 Apr 2004 - 01:54

If the module was not installed wouldn't you get the error when it tried to resolve DAV. Charlie's error appears to be after DAV has been located and the next config element (e.g. TWikiDir) is being read

-- MarkKoch - 06 May 2004 - 22:25

Crawford, I have seen that you attach the hidden Plugin topic text and include it in the Plugins page. The motivation is probably to save time when publishing a new version. However it has these disadvantages:

  • Search is excluded from attchments
  • Reports like PluginPackage show incomplete information, e.g. missing short description, Submitted by, and Last Author

I suggest to revert to the full text, it is not much additional work. Alternatively add key points as hidden text for search and reports (and update with each release as needed)

-- PeterThoeny - 07 May 2004

I've put back the CommentPlugin directive as PTh seems to have accidently removed it. I also note that TWiki.org is not running the latest version of CommentPlugin. (CrawfordCurrie has updated according PeterThoeny's requirements - I believe it is out of date because, for instance, I'm told the latest release no longer puts the leading '-' on the comment.)

-- MartinCleaver - 07 May 2004

Peter, including the topic was in the spirit of an experiment. The reason is that the topic text for all my plugins is auto-generated during the release process, and as such the text here is a derived object and must be regarded as uneditable. Though on the whole I agree it's good to be able to search, and in the next version of my release script I'm planning to use curl to automatically update the topic on twiki.org at the same time as automatically uploading the zip (the update will be released as part of SharedCode).

Mark, Charlie may have mod_dav already installed in his apache server, so the DAV directive would be recognised. But default mod_dav does not recognise the twiki_dav directives.

-- CrawfordCurrie - 07 May 2004

Thanks Crawford, so to use WebDAV the default mod_dav needs to be replaced with the mod_dav project pointed to in the instructions? Or are there other alternatives?

-- MarkKoch - 07 May 2004 - 09:29

If you previously downloaded Greg Stein's mod_dav from http://www.webdav.org, it has to be replaced with the twiki_dav module shipped with this plugin (confusing also named mod_dav, though there's a good reason for that). twiki_dav is a superset of mod_dav, and even fixes some bugs in the original. The replacement module includes a bunch of "TWiki magic" for invoking TWiki checkin scripts.

-- CrawfordCurrie - 08 May 2004

I did get the mod_dav from Greg Stein's web page.

Oh, now I see "The Apache module is based on mod_dav version 1.0.3 and includes all of the functionality of that module, so should be a drop-in replacement on Apache 1.3 servers" This does imply that there is indeed a TWiki version of mod_dav - makes sense to me now. I need to replace my current mod_dav with this Plugin's version. Now we're making apache module dependent on this Plugin, rather than visa versa. I wonder if that's a good idea?
One of the things I like about Apache and TWiki is the decoupling of web server from CGI scripts. Very attractive over tomcat portal stuff where you have to restart the listener whenever you modify a struts application for example. I know we don't have to restart Apache every time we make a change to a CGI script, and hope that we're not setting a presedent here. Would rather see Greg incorporate changes to support TWiki. For that matter, it would be nice to see Greg's mod_dav available on Apache site, as well. (I wonder why it isnt' there yet). Perhaps with the TWiki stuff (or something very similar to) it could get there? (Sorry to get off the subject. I've been thinking lately that a nice module - apache or otherwise - would be WebDAV on top of RCS with versioning and locking. So as implementation of webdav wouldn't break applications relying on RCS - example TWiki. Then, maybe that's what this plugin is all about - I'm hoping. I've got a filemanager application for TWiki, complete with user interface for viewing previous versions, locking, uploading and downloading that I'd like to contribute back to TWiki at some time. A colleague actually wrote most of it, and I've got an initial approval to contribute this back to TWiki. If it were to work with WebDAV, would even be better.)

Otherwise, back to the installation procedure:
Instructions for Win32 indicate a compile for mod_dav is needed. I am running Unix/Linux. "Drop In" replacement under unix needs compile also? RE: evidently, given the makefile stuff under twiki_dav dir supplied by this plugin. I've not had to compile many modules for Apache yet (other that perl and php), and am unsure of the process for mod_dav. I would assume that the libdav.a is created in the process. I followed Greg's instructions on installing mod_dav with the twiki version and found problems My apache configure command: ./configure "--with-layout=Apache" "--enable-module=ssl" "--activate-module=src/modules/php4/libphp4.a" "--enable-module=php4" "--activate-module=src/modules/perl/libperl.a" "--enable-module=perl" "--enable-module=rewrite" "--activate-module=src/modules/dav/libdav.a" "--enable-module=dav" I copied twiki_dav under my apache source tree, cd'd to twiki_dav,

$./configure --with-apache=../apache_1.3.28
make
make install

make went fine but make install gave following error:
>make install
mkdir -p ../apache_1.3.28/src/modules/dav; cp libdav.a mod_dav.c mod_dav.exp Makefile.tmpl Makefile.libdir libdav.module dav_shared_stub.c  ../apache_1.3.28/src/modules/dav
cp: cannot stat `mod_dav.exp': No such file or directory
make: *** [install] Error 1

Because the libdav.a file had actually been created and copied, I hoped that the apache make would work, but got errors during the make on Apache:

...
modules/dav/libdav.a(dav_twiki.o): In function `dav_twiki_accessible':
/opt/ApacheDev/src/twiki_dav/dav_twiki.c:134: undefined reference to `tdb_open'
/opt/ApacheDev/src/twiki_dav/dav_twiki.c:161: undefined reference to `tdb_close'
/opt/ApacheDev/src/twiki_dav/dav_twiki.c:147: undefined reference to `tdb_firstkey'
/opt/ApacheDev/src/twiki_dav/dav_twiki.c:150: undefined reference to `tdb_fetch'
/opt/ApacheDev/src/twiki_dav/dav_twiki.c:153: undefined reference to `tdb_nextkey'
modules/dav/libdav.a(dav_twiki.o): In function `getKey':
/opt/ApacheDev/src/twiki_dav/dav_twiki.c:249: undefined reference to `tdb_fetch'
collect2: ld returned 1 exit status
make[2]: *** [target_static] Error 1
make[2]: Leaving directory `/opt/ApacheDev/src/apache_1.3.28/src'
make[1]: *** [build-std] Error 2
make[1]: Leaving directory `/opt/ApacheDev/src/apache_1.3.28'
make: *** [build] Error 2
../twiki_dav/dav_twiki.c:134: undefined reference to `tdb_open'


Please assist.

-- CharlieSmith - 11 May 2004 - 07:05

I'm sorry, my previous post maybe too long. In running the make install on twiki_dav, I get error: cannot stat `mod_dav.exp'

Please assist.

-- CharlieSmith - 11 May 2004 - 03:11 pm.

I tried to compile twiki_dav on an windows environment and got the following error:

...

In file included from apache/src/include/ap_config.h:114,
                 from apache/src/include/httpd.h:72,
                 from dav_twiki.c:25:
apache/src/include/os.h:197: warning: `struct tm' declared inside parameter list
apache/src/include/os.h:197: warning: its scope is only this definition or declaration, which is probably not what you want
dav_twiki.c: In function `invoke_command':
dav_twiki.c:440: error: `P_tmpdir' undeclared (first use in this function)
dav_twiki.c:440: error: (Each undeclared identifier is reported only once
dav_twiki.c:440: error: for each function it appears in.)
make: *** [dav_twiki.o] Error 1

-- NorbertWindrich - 12 May 2004

Zowie, lots of comments! Great!

Charlie, first off, mod_dav for Apache 1.3 isn't on the Apache site because development of mod_dav for Apache 1.3 is frozen, and only the Apache 2 mod_dav is being advanced. This is now a standard part of Apache 2. I haven't touched the Apache 2 version of mod_dav because it is pretty much a total rewrite of the 1.3 version, and because TWiki has had problems working with Apache 2. The Apache 2 version includes proper support for third-party implementations of version control, and a TWiki module to fit with that would have been much simpler to write. But it would still be a specialised Apache server, at the end of the day.

The changes I made to mod_dav to support TWiki are not compulsory. You can use standard md_dav just fine with TWiki directories, though don;t expect it to work with RCS. What twiki_dav does is to translate DAV operations - such as COPY, MOVE, DELETE into TWiki operations, and it does it within the context of the TWiki protections scheme. I can't think of any reason why your filemanager wouldn't work with DAV just the same as any other filemanager, such as Explorer or Konqueror - both of which work just fine.

At the end of the day, TWiki integration with mod_dav really needs a smartening up of the TWiki store so that it is a proper version control system, rather than the hybrid mixture it currently is. At the moment the version control and other functions of TWiki are too interwoven to be able to separate them. For example, meta-data is stored embedded into the actual topic file, making it impossible just to do VC operations directly on attachment files.

I think the problem with mod_dav.exp you encountered is my fault. I didn't anticipate anyone building the module statically, or on Win32, so I didn't bother checking the .exp and other files into CVS. Oops. Try getting it from the standard mod_dav distribution.

Norbert, I haven't attempted to build on Win32 - you are in totally uncharted territory! But P_tmpdir is just a standard define for a temporary directory, from stdio.h of stdlib.h, I forget which. You should be able to edit that source file (dav_twiki.c) and at the start put something like:

#ifndef P_tmpdir
#ifdef WIN32
#define P_tmpdir "C:\\Windoze\\TEMP"
#endif
#endif
.... but I'm only guessing.

-- CrawfordCurrie - 12 May 2004

Thanks for your reply Crawford. I will try pulling the mod_dav.exp from the old build. (see below 'Ok. I grabbed...') I was concerned that it might be different from or created by the twiki_dav install.

I'm actually quite pleased with the TWiki store stuff, and have taken advantage of it in the current filemanager that we use/wrote. So, an ideal project, in my mind, would be to implement WebDAV on top of RCS versioning. I also added a locking feature with relative ease for the filemanager. Used filename,lck as a semaphore. Because all file manipulations currently go through a 'file' or 'fileview' script, it's easy to enforce this locking mechanism. I would like to see this also be incorporated into any possible rewrite of a mod_dav.

What are TWiki's issues with Apache 2? I know, in trying to get to work under Apache 2, myself, that I found numerouse issues with mod_perl, but seemed to work ok without, other than it was bit slower. Then, I haven't had enough time to get at all the possible problems yet.

Ok. I grabbed the mod_dav.exp from Greg Stein's mod_dav build. 'make install' gave no errors this time. I configured apache with command mentioned, then tried a make. Got following error:

modules/dav/libdav.a(dav_twiki.o): In function `dav_twiki_accessible':
/opt/ApacheDev/src/twiki_dav/dav_twiki.c:134: undefined reference to `tdb_open'
/opt/ApacheDev/src/twiki_dav/dav_twiki.c:161: undefined reference to `tdb_close'
/opt/ApacheDev/src/twiki_dav/dav_twiki.c:147: undefined reference to `tdb_firstkey'
/opt/ApacheDev/src/twiki_dav/dav_twiki.c:150: undefined reference to `tdb_fetch'
/opt/ApacheDev/src/twiki_dav/dav_twiki.c:153: undefined reference to `tdb_nextkey'
modules/dav/libdav.a(dav_twiki.o): In function `getKey':
/opt/ApacheDev/src/twiki_dav/dav_twiki.c:249: undefined reference to `tdb_fetch'
collect2: ld returned 1 exit status
make[2]: *** [target_static] Error 1
make[2]: Leaving directory `/opt/ApacheDev/src/apache_1.3.28/src'
make[1]: *** [build-std] Error 2
make[1]: Leaving directory `/opt/ApacheDev/src/apache_1.3.28'
make: *** [build] Error 2

I made sure that the TDB_file module from CPAN has been installed.

Please assist. -- CharlieSmith - 13 May 2004

TWiki issues with Apache2 are widely discussed in the Codev web.

RTFM, Charlie. You also need the tdb library installed (the C library), including tdb_devel, which contains is the developer include files. TDB is used to cache the protections.

You don't need another locking mechanism because mod_dav handles locks for you. It would not be sensible to work around or replace that implementation. Note that twiki_dav does not recognise the TWiki locks ( .lock semaphore file) on files, as the twiki locking model is time based and that just doesn't make sense in DAV.

You have to decide how you want to handle the Delta-V extensions; the support for Delta-V in the 1.3 mod_dav is pretty brain-dead, which is the major advantage of building on the Apache 2 module. I only support auto-versioning in twiki_dav.

My recommendation would be to start with the Apache 2 mod_dav implementation and build a brand new module to do RCS versioning using the extensions mechanisms built into mod_dav. This would avoid you having to change any code in mod_dav. Subclassing the RCS versioning module to support TWiki as well would ultimately be easier than hacking around in the 1.3 module. of course you won't be able to support Apache 1.3, but hey, life moves on.

An alternative approach would be to re-implement the mod_dav module in Perl, in which case it would be portable between 1.3 and 2. However this is an awful lot of work!

-- CrawfordCurrie - 14 May 2004

What manual? I'm sorry, I didn't realize there was one. Please assist. Where is it?

-- CharlieSmith - 14 May 2004

WebDAVPlugin is the manual, Charlie. Specifically the bit that reads:

Add-On Installation Instructions

-- CrawfordCurrie - 14 May 2004

Hi again. I'm now using this plugin. Very cool. Couple of observations, I can't get drag and drop to work, at least for MS Word. It just pastes the url into the document. Opening via the URL works just fine. Also, when I save from a DAV enabled app, the changes are saved but the RCS versioning doesn't appear to be working. For example, if I have a DAV enabled folder twiki/pub/MyDocs and I change a doc in MyDocs ( say MyWordDoc.doc ), MyWordDoc.doc is updated but the MyWordDoc.doc,v file remains unchanged. An rlog MyWordDoc.doc verifies that RCS only recognizes the original version. I'm not an RCS user so I don't know if I'm just under-RCS-educated or if something's not working properly. Can someone comment?

Thanks for your help and thanks for making TWiki document editing and mgmt easier.

-- MarkKoch - 14 May 2004 - 19:42

I'm a bit hamstrung, because I don't own a copy of MS Word to test against, but a wild guess is that you are dropping on the document body rather than on the window border. As I recall, MS apps have a different behaviour depending on where you drop the doc.

The lack of RCS changes is more serious; that indicates that the link to TWiki is screwing up somehow. You don;t mention it but I suspect the attachment table in TWiki topics isn't getting updated either. Check the content of your apache error_log. Check for a file called /tmp/vsnlog and if it exists check the content. Failing any clues emerging that way, put the top-level directive "DAVMonitor 3" into your Apache log (7 is a bitfield; bit 0 is transaction monitoring, bit 1 is versioning logging and bit 2 is protections monitoring in agonising detail, 3 will give you bits 0 and 1), restart apache and perform a save. Read the error_log again.

-- CrawfordCurrie - 15 May 2004

I discovered what was causing the RCS problem. I installed the Plugin on the stable version of TWiki. This does not include the TWiki::UI::Upload.pm package. I installed the alpha version and the WebDAV plugin is working correctly.

MS Word will not allow me to drop the document on the window border. It gives me the universal "NO" icon ( a circle with a slash through it ) when I try to do so.

-- MarkKoch - 15 May 2004 - 06:44

- Arrrgh yes, thank you Mark. I should have written some install instructions about that, but in the rush.....

-- CrawfordCurrie - 15 May 2004 - 09:32

Yes, evidently I have already installed the tdb c library. I've got the tar and the tdb.h file is in /usr/local/include I checked dav_twiki.c line 134 in attempt to walk through c code and locate error on line 134 of dav_twiki.c(see May 13 posting). It seems odd to me that 'make install' on the twik_dav stuff gives no error messages, and the tdb c library gave no error on 'make install', but when apache is compiled, errors indicated problem with references in dav_twiki.c. Ex. line 134 if dav_twikic: undefined reference to `tdb_open'.

Line 134 references a define on line 52: #define DBM_OPEN(_f,_m,_p) tdb_open((_f),0,TDB_DEFAULT,(_m),(_p))

So, looks like I did follow the instructions in the manual, but something seems to be missing. Would appreciate any help on this one.

-- CharlieSmith - 18 May 2004

You say "when apache is compiled" which is confusing me. You are attempting to build a statically-linked apache? As I said before, I have not compiled a statically-linked version, only the dynamically linked version. With the dynamically linked version, if the TDB library (usually /usr/lib/libtdb.so or /usr/local/lib/libtdb.so) was not visible to the apache user on apache restart (not compile), I would expect to see the error you describe above.

Check that the tdb library is visible to the apache user. That's all I can suggest without a better idea of what you are trying to do. If that's not the problem, tell me the command-lines you are using, and I can try to reproduce the problem.

-- CrawfordCurrie - 19 May 2004

Hi again, I've got a couple questions on how locking works. User A opens a DAV controlled document at t1. User B opens the same document at t2. If user A then saves at t3 and user B saves at t4, do the changes by user A get lost? Thx again.

-- MarkKoch - 19 May 2004 - 19:30

Sadly in most cases locking doesn't work, or at least not very well. There are two types of lock, DAV locks and TWiki locks. DAV locks are proper locks; once a lock on a document has been claimed it has to be explicitly released by the locking user. TWiki locks are the time-based locks used on TWiki topics. These two locking schemes operate as follows.

DAV locking depends on the application requesting a DAV lock from the server, and at the time of writing most applications just don't do that. So in general a DAV-mounted folder is just like an ordinary file folder; A's changes will indeed be overwritten by B. If you are editing a TWiki file, the changes won't be lost, because they will be recorded in the previous RCS version of the file. If you have an application that does respect DAV locks, then once a document is locked it can only be opened read-only by another user.

TWiki locks are only respected on document save. In terms of your example above, if A left the document locked at t3 and (t4 - t3) < 60 minutes then B's t4 save will be blocked (HTTP Forbidden). Otherwise the save will silently overwrite. Note that the lock is on the topic, not the attachment. twiki_dav automatically unlocks topics on successful save.

The solution to all this is to improve TWiki's locking scheme so it can be replaced by, or at least run alongside, the DAV scheme.

BTW, the latest zip extends DAV support to TWiki topics, as well as attachments.

-- CrawfordCurrie - 20 May 2004

Yes, I was trying a static build. I'll try to build dynamically on next try. Will let you know outcome. Thanks for responsiveness of reply. wink

-- CharlieSmith - 18 May 2004

np. Thanks for testing! Latest upload is the first proper release.

-- CrawfordCurrie - 22 May 2004

Ok. I got apache built dynamically. But get following error on starting up httpd file: Cannot load /opt/ApacheDev/src/apache_1.3.28/src/modules/dav/libdav.so into server: /opt/ApacheDev/src/apache_1.3.28/src/modules/dav/libdav.so: undefined symbol: tdb_open I made sure that tdb.h was in my path. Couldn't find tdb_open. So downloaded tdb and tdb-devel and installed them.

My system shows: tdb 1.0.6-100 System/Libraries A trivial database system tdb-devel 1.0.6-31 Development/Libraries/C and C++ Development package for tdb

Probably something very simple, but I'm stumped. Please assist.

-- CharlieSmith - 26 July 2004

Charlie, libtdb.so has to be on your path. The library should normally go into /usr/lib, though it can be placed in /usr/local/lib. If the lib is there somewhere, then I would guess that the directory containing it is not on the path for the apache user. I guess you should be able to set that path somehow, though I'm not sure how. Alternatively you could copy the tdb library files into /opt/ApacheDev/src/apache_1.3.28/src/modules/dav and that should work OK.

-- CrawfordCurrie - 28 Jul 2004

Wonder if anybody could help explain a locking problem I'm having with this... I think I have everything loaded correctly, and can see the various topic.txt files (with the *,v hidden, which does not occur if using plain mod_dav). I can open them remotely, etc., but when I try to save back, I get an error 409 that seems to be complaining about locking. What I note is that when the "lockfile" is touched, mod_dav seems to be trying to use something besides the same lock file format that twiki_dav wants... I get a TWiki.pag and TWiki.dir file, which seem to be gdbm??? They get updated when my DAV client locks a file... but then twiki_dav seems to try to use a tdb file or somesuch, and they are different formats. I have convinced mod_dav to just use a single TWiki file via

I tried using #define DAV_USE_GDBM in dav_fs_dbm.c, but it didn't seem to help... this make any sense to anybody???

I'm running on Gentoo, with apache-1.3.31 , and the latest TWiki production (Sept. release)

-- BruceDillahunty - 19 Sep 2004

A quick DAV tutorial:

twiki_dav is based on mod_dav, the standard Apache DAV module. DAV has multiple levels of support for versioning interactions. The simplest of these is a RCS-like lock/unlock strategy, implemented using the LOCK method. A client can lock a file for it's exclusive use. These locks are implemented in mod_dav using an SDBM database.

This is nothing to do with the TWiki TDB database, which is used to implement cacheing of the TWiki permissions database (read WebDAVPlugin), and nothing to do with TWiki "locks" which are implemented using .lock files in the TWiki data directories.

  • The SDBM lock database is in the .dir and .pag files
  • The twiki permissions DB is cached in the TDB database (TDB is used because it has record-level locking, which SDBM lacks)
  • TWiki locks are implemented in .lock files in the TWiki data directory
Do not use GDBM (support is there historically, IIRC).

To debug further I would recommend you download a command-line DAV client such as DAVE or Cadaver and watch what happens when you LOCK. Note that there is a known bug in Apache 1.3.31 that maight be affecting you. If it is, then there will be error messages relating to the parsing of XML in your Apache error log.

BTW what DAV client are you using?

-- CrawfordCurrie - 20 Sep 2004

Just uploaded a version that has improved debugging and fixes a minor irritation with the conversion of tabs to spaces and vice-versa.

-- CrawfordCurrie - 20 Sep 2004

Well... I think I have it working (thanks for the help!).

I am using Goliath (Mac) and/or DAVExplorer (PC) as a client. The native clients both have "issues" with my setup that I haven't gotten resolved yet.

It seems like the biggest issue I was having was the fact that I had my data and pub directories "outside" of the twiki directory. When I put them inside and got the apache.conf file straight, it seems to be working. I don't know if I just had a problem in my apache.conf file, or if the plugin code isn't handling the "strange" configuration.

Once I'm more comfortable (and can get caught up on some work which is why I was wanting the WebDAV access :-)) I'll try to play with that a little more and see what's up.

Thanks!

-- BruceDillahunty - 20 Sep 2004

Is anyone working on making this webdavplugin for Apache 2.0???

-- JohnCavanaugh - 30 Oct 2004

Not me. I'd be happy to do so, if someone would pay me to do it (gotta eat).

Note that it would be far more interesting to work on making TWiki work with a WebDAV based store (i.e. write a Store.pm imlementation that used Neon). Then you wouldn't need the plugin (or the Apache module) at all. Of course you'd have to work out how to store TWiki metadata, but hey, TANSTAAFL.

-- CrawfordCurrie - 30 Oct 2004

Moved my question to the Support web. Sorry for the bother. -- SeanHare - 08 Nov 2004

I've installed WebDAVPluginOnFreeBSD, and left a trail for those following.

I'm successful in reading, locking, unlocking, and deleting text files in the data area. I get the "409 conflict" when I try to put a file back into the data area . This occurs for a new file or an existing file, using Cadaver or Novell NetDrive from Windows. I've turned on DAVMonitor 7, looked in the Apache and TWiki logs, dumped the WebDAV database, looked at file permissions, and wiki permissions. Any advice appreciated.

The NetDrive Client Version 4.1 Build 862 - TID2965552 is very nice, effective WebDAV could revolutionize TWiki.

-- DanDees - 10 Nov 2004

I am currently trying to build and install mod_dav for apache and get the following error when I run the make command:

gcc -c  /usr/local/include -I/usr/include/apache-1.3 -I/usr/include -g -O2 -DLIN
UX=22 -DEAPI -DTARGET="apache" -DHAVE_SET_DUMPABLE -DDB_DBM_HSEARCH=1 -DDEV_RAND
OM=/dev/random -DUSE_HSREGEX -O1  -g -Wall -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BI
TS=64 -fPIC -DSHARED_MODULE /usr/local/include  dav_props.c -o dav_props.o
gcc: cannot specify -o with -c or -S and multiple compilations
make: *** [dav_props.o] Error 1

I also get the identical error when I try to build the non-modified release. I suspect it is something in my build environment and would appreciate any suggestions.

-- RickMach - 05 Mar 2005

Dan, sorry, I never noticed your problem here. Here are some possibilities:

  • you are using soft links in a path, and it can't resolve them
  • you are trying to check out an already checked out resource (maybe you checked it out in some other tool e.g. cadaver)
There should be a message associated with the 409 in your error_log or access_log.

Rick, it looks like a strange version of gcc. I used 3.3.1 to build the module.

-- CrawfordCurrie - 05 Mar 2005

I am using gcc 3.3.5 on Debian. I did get it to build on a second Debian box with the same compiler version. It must be something in my environment on the one machine I am still trying to track down.

I can now see the directories and can successfully read the contents. I have successfully saved a new attachment by dragging and dropping the contents on the directory. I have also opened the file in a text editor (Word). I was only able to put it back into the server by saving the file locally and dragging it into the folder (like I did with the new attachments). I get a generic error (like error occurred while transfering one or more of the selected files) when I did these operations with the base document and attachements however the changes show up in the wiki.

-- RickMach - 05 Mar 2005

Can anyone tell me of a hosting plan that will allow me to run this plugin? Thanks.

-- MartinCleaver - 07 Mar 2005

Rick, check your definition of the various environment variables like CPPFLAGS that may be impacting the build. it looks like you have /usr/local/include somewhere where you should have -I/usr/local/include.

Martin, no, I'm afraid not. There are various hosts that offer mod_dav, but none on twiki_dav AFAIK.

-- CrawfordCurrie - 07 Mar 2005

Crawford, on 19 Apr 2004 you said that "This means that DAV browsing on attachment directories is now access-controlled.", but we cant get it to work with attachment access control. For normal topics in data everything works fine. You have a clue what we did wrong?

-- AndreUlrich - 11 May 2005

Protection of pub via WebDAV is not supported at the moment. You may want to take a look here: IRC-log.

-- OliverKrueger - 12 May 2005

I created a quick & dirty patch to enable access control for the pub resource. The patch touches lib/twiki_dav/dav_twiki.c. You need to recompile the apache module.

-- OliverKrueger - 31 May 2005

Well, here's an interesting twist of FOSS. There is a new version of TDB_File (0.90) on CPAN, which is "supposed" to work with tdb-1.0.6 from sourceforge, but it expects constants that aren't defined in the sourceforge release. Instead, I had to build the tdb included in samba-3.0.10, which of course doesn't build a shared library therefore I copied the samba source over the top of the sourceforge source to get all the autoconf makefile goodness.

Here is what I did:

  1. cp samba-3.0.10/source/tdb/*.* tdb-1.0.6/
  2. tdb-1.0.6$ ./configure --prefix=/usr
  3. edit Makefile and add '-DSTANDALONE' to CFLAGS, then comment the noinst_PROGRAMS so they won't be built:
    CFLAGS = -g -O2 -DSTANDALONE
    PROGRAMS =  $(bin_PROGRAMS) #$(noinst_PROGRAMS)
  4. tdb-1.0.6# make && make install
  5. # perl -MCPAN -e 'install TDB_File;'

-- WadeTurland - 03 Jul 2005

This Plugin does not work in TWiki 4.0 as reported in Support.ErrorsWithWebDAVPlugin. It uses TWiki internal functions and variables TWiki::Store::getAllWebs, $TWiki::egrepCmd, $TWiki::cmdQuote, $TWiki::wikiPrefsTopicname, $TWiki::webPrefsTopicname. Please consider upgrading this Plugin so that it runs on Cairo and Dakar codebase.

-- PeterThoeny - 16 Feb 2006

  1. Any progress yet on upgrading?
  2. I can't manage to install TDB_File (Linux Redhat). Where can I obtain a compiled version?

-- ArthurClemens - 23 Mar 2006

I have clients with an interest in a TWiki-4/Apache 2, so there's a good chance this may happen. I am unlikely to put much effort into porting the Apache 1.3 version to TWiki-4, unless people start clamouring for it.

TDB_File is a perl module; did you mean tdb (the C-code)? Don't Wade's instructions work?

  • Wade Turland's instructions have helped me for tdb, but after that I can't install TDB_File. -- ArthurClemens - 23 Mar 2006

-- CrawfordCurrie - 23 Mar 2006

Currently availability of this plugin is what is keeping us from upgrading to TWiki-4. Any effort would be appreciated!

-- RickMach - 23 Mar 2006

1.3 or 2?

-- CrawfordCurrie - 23 Mar 2006

Sorry. We are using Twiki V3 on Apache 1.3. We want to upgrade to Twiki V4 but the lack of this plugin is what is a show stopper for us. I don't have a problem upgrading to Apache 2 at the same time assuming Twiki 4 and various plugins work fine with Apache 2. (We are using no other plugins that require Apache modules. I don't know if standard plugins care about the underlying version of Apache being used.)

-- RickMach - 23 Mar 2006

Hm, why does this Plugin not work on Apache 2? Will this be supported some day?

-- FranzJosefSilli - 11 Apr 2006

It's available on TWiki-4 now. The reason it doesn't work on Apache 2 is that the plugin includes an apache module (a twiki-tailored version of mod_dav) and the Apache project changed all the APIs between 1.3 and 2, so the module doesn't work with 2.0. But unless I get a client prepared to fund me to port it to Apache 2 (or someone else tackels the job), it will be staying on Apache 1.3.

Rick, WebDAVPlugin is not a standard plugin, not by any stretch of the imagination! It includes an Apache module; it is very non-trivial. wink

-- CrawfordCurrie - 14 Apr 2006

wouldn't this plugin still work with TWiki-4 running under Apache 1.3? TWikiSystemRequirements doesn't list a specific apache version, but twiki-4 still runs under apache 1.3, right?

-- WillNorris - 15 Apr 2006

Right.

-- CrawfordCurrie - 17 Apr 2006

Thanks for porting this module to TWiki-4! One problem: When I PUT new files into a Dav-Resource, the file is truncated to 0 Bytes... Any reason? Thanks!

-- JensHassler - 26 Apr 2006

Can you give me a specific test case (a set of steps to follow to reproduce the problem) please?

-- CrawfordCurrie - 26 Apr 2006

Nested Web support would be nice for nested folder file stores.

-- JeffPelton - 25 May 2006

Most of new Twiki installations would be done on Apache 2 and non availability of WebDav plugin for Apache 2 would be a major limitation.

-- GauravSharma - 29 May 2006

The zero-sized attachment problem is fixed. Sorry about that.

-- CrawfordCurrie - 02 Jun 2006

Is there update about the possibility of porting this to Apache 2? This is the only thing missing from my TWiki and it would be a great addition!

-- ScottRogers - 02 Jun 2006

MartinCleaver: with apache 1.3, is it possible to get the server to tell you all commands implemented by a given module?
DrBacchus: MartinCleaver: Yes. httpd -L does that.
MartinCleaver: even ones loaded with mod_so?
DrBacchus: MartinCleaver: No. But mod_info will do that.
MartinCleaver: ok, so I have the output of mod_info in front of me
MartinCleaver: I can see the LoadModule line 
MartinCleaver: and I can see detail for other modules that look like they are loaded with mod_so
MartinCleaver: but the one I am interested in has no detail
MartinCleaver: does that mean it failed to load?
DrBacchus: MartinCleaver: No. If it failed to load, you'd get an error on restart
MartinCleaver: no, I got no error on restart (unless I attempt to use a directive from the module)
MartinCleaver: so can it successfully load yet fail to register any details in server-info ?
MartinCleaver: (apache 1.3)
MartinCleaver: so there should be an error message somewhere?
BillTheCat: MartinCleaver: is this FC or ?
DrBacchus: MartinCleaver: do a full stop and start.
DrBacchus: MartinCleaver: Perhaps it didn't in fact actually restart.
DrBacchus: mod_info is weird on 1.3 - it shows what you have in the config file, not necessarily what is loaded.
MartinCleaver: ok thx
MartinCleaver: has anyone written a better diagnostic mod_info for 1.3?
DrBacchus: MartinCleaver: Yeah. It's called "upgrade to 2.2" ;-)
MartinCleaver: heh
MartinCleaver: What's the point of AddModule once you've done LoadModule?
MartinCleaver: aha. got it. I was missing AddModule

-- MartinCleaver - 27 Jun 2006

http://httpd.apache.org/docs/1.3/mod/mod_info.html

-- MartinCleaver - 27 Jun 2006

Thanks very much for fixing the 0-filesize bug. Now it's working, but... there are still 2 problems:

Files having names with spaces in them (like "Test File.doc") simply disappear when uploaded through WebDAV.

And the second problem are special chars in filenames (Umlauts) - this is serious, because we have several umlauts in Germany. The non ASCII chars are displayed wrong in TWiki when uploaded with WebDAV, and the versioning doesn't take place. The WebDAV folder on the other hand displays the file correctly. Where do I have to search for a solution?

More to the umlaut problem:

- When I upload a umlaut-named file via TWiki-Upload, it is shown correctly in the attachment table. But it is shown with "%f6" or something instead of the umlaut "" when viewed via the WebDAV folder. And so, it's also not editable from the WebDAV folder.

- The other way around (uploading the file via WebDAV) the file is displayed correctly in the WebDAV folder but not in TWiki.

So I think there should be some charset options or something related to WebDAV. But there are many places where they can happen (TWiki, your module, Apache, Linux system) and I don't know where to look and what I have to change.

The "spaces in filename" problem is only with your WebDAV module. When I upload such a file with TWiki, the filename gets converted (" " are changed to "_").

Thanks for any help!

-- JensHassler - 05 Jul 2006

I'm going to echo the earlier question about Apache 2... any ideas what needs to be done to make this available on an Apache 2 server? Thanks!

-- DenisHaskin - 07 Sep 2006

Jens, first, TWiki doesn't support filenames with spaces in. For webdav to apply the same renaming rules as TWiki does would be fairly complex (though certainly not impossible). Second, I never tested 8-bit characters in filenames; it was never a requirement for my client.

Denis, the choices:

  1. Rewrite the plugin based on mod_dav for Apache 2
  2. Leverage the work the UseMod guys did on a perl implementation of a mod_dav handler
  3. Pay someone else to do either of the above (e.g. me)

-- CrawfordCurrie - 08 Sep 2006

This looks like a very promising plugin.

I'm doing some experimentation and have the following questions:

1. I've implemented a DAV-edit button in the attachment table at the bottom of a topic. Now when I open an attachment from my web browser, it opens up in word, I make edits and click save. What is suppose to happen here? In my setup word prompts me to save the file to my C:\ drive. I would expect it to prompt me to save it back to the webdav folder.

  • I don't have a copy of Word, so I can't comment authoritatively, but it sounds like Word is too stupid to recognise a DAV URL.

2. Assuming the above works as I expect. My second question has to do with versioning (TWiki's versioning) of attachments. If I have a file open in word and I save it back into a webdav folder, shouldn't the version of the file be incremented on the "Version History" section of the manage screen?

  • Yes, it should.

3. My third question has to do with authentication. It seems like webdav/TWiki is now authenticating me a lot more than before. Is this necessary or have I configured something incorrectly? Everytime I open an attachment and try to close word/excel/etc. I'm prompted with a login box. Also when I use file explorer OR internet explorer and browse to the attachments of a topic, and then attempt to open an attachment file i'm presented with a auth box too. Shouldn't I already be authenticated since i'm able to browse?

  • The browser caches credentials for websites, other applications are not so smart and require you re-authenticate for every access.

Thanks for your help!

-- SamMingolelli - 09 Nov 2006

Is there a specific reason why this plugin is still for apache1.3 only or is it more a lack of developers to port the code to apache 2.X? I ask because I'm one of the developers of the Catacomb WebDAV server (http://catacomb.tigris.org) and could imagine that it would be nice to bring this two pieces of software together. It would act like a kind more powerful kind of Sharepoint. Unfortunately Catacomb is a Apache 2.X module - so at this moment this won't work.

-- MarkusLitz - 07 Dec 2006

Purely a lack of developer(s).

-- CrawfordCurrie - 08 Dec 2006

Maybe I could enthuse some developers to work with me together on that task. I would do much on the server side, but don't want to do all by myself. If there is someone please post here so we could find together.

-- MarkusLitz - 11 Dec 2006

This plugin fits well into teh TWikiMission. Done right (intuitive & seamless integration), this plugin can be a good competition to SharePoint.

-- PeterThoeny - 12 Dec 2006

I totally agree with you on this. But there are some necessary functions needed I think:

  • support of apache 2.x is essential.
  • at the end there should be no limitation of functionality.
  • the installation should be easy or there should be a alternative installation package.
I think (and I know I'm not alone), that this really could be an alternative to SharePoint that is more comfortable to work with. Like I said, I'm familiar with apache module programming and would do some work on that side.

-- MarkusLitz - 12 Dec 2006

Markus, the starting point would be a set of requirements. Since I did the work on the module for Peter, the TWiki internal APIs have moved on a lot, and there is new thinking about things like permissions management that we need to take into account. I'd be happy to talk with you on this; perhaps starting a new topic in Codev would be an appropriate place to work, it's getting a bit cramped in here wink

-- CrawfordCurrie - 13 Dec 2006

Ok, I'll start a new Page: WebDAVPluginDevRequirements

-- MarkusLitz - 14 Dec 2006

Topic attachments
I Attachment History Action Size Date Who Comment
Unknown file formatdiff dav_twiki.c.diff r1 manage 0.2 K 2005-05-31 - 11:25 OliverKrueger quick&dirty: enables access control for pub
Edit | Attach | Watch | Print version | History: r91 < r90 < r89 < r88 < r87 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r91 - 2006-12-14 - MarkusLitz
 
  • Learn about TWiki  
  • Download TWiki
This site is powered by the TWiki collaboration platform Powered by Perl Hosted by OICcam.com Ideas, requests, problems regarding TWiki? Send feedback. Ask community in the support forum.
Copyright © 1999-2017 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.