Hello,
there seems to be some confusion about the problem Martin Samuelsson
reported. So here is my (upstream) point of view:
It is no longer the IIS-bug. This is fixed in davfs2 0.2.8.
The problem only occurs with a custom WebDAV module used by Martins
provider. To see what is the 'failsafe' way of handling this, I have to
explain first:
- By default, whenever a file is opened for writing, davfs2 will lock it
on the server, to prevent the lost update problem. This is one of the
main features of WebDAV.
- As long as the user does not choose the 'nolock' option, the user
should be able to trust in this behavior.
- The broken WebDAV server: When davfs2 requests a lock, this WebDAV
implementation will send back invalid XML, violating the DTD (it sends
an empty timeout element which *must* not be empty).
- The neon leibrary - correctly - refuses to parse this invalid XML.
So what is the failsafe action?
- I think neon is correct, as the response is invalid. There is no way
to evaluate whether there is a time restriction on the lock, and if so,
how long the lock is valid.
- davfs2 must not open the file for writing. As davfs2 did not receive a
reliable response from the server on it's lock request, it must not rely
on the file being locked. Opening the file for writing might result in
data loss. But the user relies on davfs2 locking the file.
- So davfs2 must respond with an I/O-error instead of opening the file.
This is what davfs2 is doing. It is not a bug, it is the failsafe way.
The user may choose to use the nolock option. This will change the
situation, as the user knows there is no locking.
Greetings
Werner
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
