mod_dav_fs currently writes a file to disk as it is created on disk. It does not atomically create the file from the upload. It is hard for external processes to tell when the upload is complete.
Created attachment 18472 [details] attempted fix for 2.2.x
This looks reasonable to me, although I haven't actually tested it. Only two comments. 1) The fpath variable could be const, and is declared with different spacing around the * than everything else in the file. 2) You could move the declaration of fpath and rv into the blocks where they're used, although I'm not sure if that style is used in this code or not, so no big deal.
ISTR from Greg trying this before that it breaks locking (because the lock is keyed off the inode); have you tried a litmus run with this?
(In reply to comment #3) > ISTR from Greg trying this before that it breaks locking (because the lock is > keyed off the inode); have you tried a litmus run with this? I tried litmus and got errors after applying the patch. In fact, locking does not work (first failed test: "DELETE of locked resource should fail"). I am looking into this issue now.
I'm sorry, but I could not find a quick fix. Someone with a stronger experience in Apache programming (or more spare time available) may come up with a solution, though.
This bug can also cause data loss: When something goes wrong with a PUT request that replaces a file, the old file will be deleted. I see three possible solutions: 1) Create a new hook that is called in dav_notify_created() to update the lock key. This breaks mod_dav's API compatibility and cannot be done in 2.2 2) Use a temp file that is moved over the old file as in Paul's patch, and switch the lock key from inode to filename. 3) Use a temp file that is copied over the old file. This is slow and doesn't solve the problem completely. I would vote for 2), in order to get this into 2.2.
Created attachment 23956 [details] also disable inode keyed locks and cleanup the tempfile if something goes wrong Switching to filenames in the lock keys is simple and fixes the litmus failures. Are there some numbers on what impact this has on performance? I have also added some code to remove the tmpfile when the new file is not committed. For the case that a file is opened seekable and the file existed before, the file should probably not be deleted on error.
solution 2) commited to trunk as r834049
fixed in 2.4.1