Re: Deleting files on temporary network dropouts

Greg Troxel <[email protected]> Fri, 09 Jan 2026 08:58:16 -0500
Newsgroups gmane.network.unison.general
Message-ID <[email protected]>
T=C3=B5ivo Leedj=C3=A4rv <[email protected]> writes:

>> I tried that, ran ls and stat on a remote file in a loop while switching=
 networks. The output was blocking, then resuming after a while but I've ne=
ver seen a
>> ls: cannot access
>> like it is returned for non-existing files.
>
> This is interesting. If you are seeing the weirdness only with Unison
> and noth with other tools/ls/stat then I'd look into tracing system
> calls.

Basically there are system calls to read a directory.  In davfs2 that
will get turned into "do this DAV operation and return the results".
There is surely some "tell me the files in this directory" DAV
operation.

Now I am speculating:

What if the DAV operation is supposed to return 400 files, but the
connection is broken during that, and only 230 are returned before
failure.   That should then cause the entire operation to be reported as
EIO.  But if "connection closed wrongly" is misinterpreted as "normal
EOF", then it could return "success, there are 230 files, here they
are".

If there are caches, then "returns when it shouldn't" could also be
"stores in cache as a valid result when it shouldn't".


So, find some big direcotry.    Write a script to do ls and save it (in
a date-stamped file) and do that repeatadly, during some time when you
don't touch that directory, and see if they are all the same.   Then add
some command to clear your davfs2 cache in between.

To unsubscribe from this group and stop receiving emails from it, send an e=
mail to [email protected].