On Sun, 18 Nov 2012 13:38:39 +0000, Anonymous writes:
>/instantly/.  It is physically impossible for the upload to happen
>that fast.  

you're correct, of course.

>This means that whole 50mb file is being cached by davfs2,
>and other commands touching the remote filespace are forced to wait in
>a queue.  To confirm this, a simple "ls" command was given upon the
>instant return of the prompt (after starting an upload), it takes a
>staggering ~5 min for the "ls" command to return.

and that's fine, too. davfs2 blocking accesses for a while is fine, that's
within what posix specifies as proper filesystem behaviour.

but if davfs2 wants to cache then it must *properly* cache all aspects 
of the filesystem. it can't just cache a few things but return a 
silly, misleading error to an application that accesses files davfs2 has
already given an ok for.

>What duplicity does not know is that
>when it tries to do anything with that file location after the upload
>begins, the next command will take ~5 min to process, even if it's a
>command that would in itself normally be very quick.

and that's because duplicity *cannot* know anything about this: it's told
the os to create a file, the operating system has said 'done, we're good' 
and that's it from the application's perspective. 

there is no magic 'are we there yet?' system call that duplicity could 
issue to second-guess the previous, authoritative ok from the os. 

davfs2 (playing the role of the os's secretary) must mend its
ways and either only report done when it's done, or divert subsequent 
requests into its cache until it's *really* done pushing data.

>However, this will remain a stumbling block for other users.  At a
>bare minimum, I would suggest at least correcting the error message,
>so that it states that it timed out instead of erroneously citing
>permissions.

sorry, no can do: there is no duplicity timeout involved here. 
duplicity reports that permission denied error because that is what 
it was given by the os/davfs2. 

regards
az


-- 
Alexander Zangerl + GPG Key 0x42BD645D or 0x5B586291 + http://snafu.priv.at/
Unix *is* user-friendly. It is not ignorant-friendly and idiot-friendly.

Attachment: signature.asc
Description: Digital Signature

Reply via email to