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].