Re: Deleting files on temporary network dropouts

Mo B <[email protected]> writes:

> I'm syncing clients against a central WebDAV server, using davfs2+unison on 
> Linux (and Foldersync on Android).
> When having a weak uplink, sometimes a bunch of files gets detected as 
> remotely missing, going to delete locally. In the next sync turn having a 
> stable uplink, the files get deleted remotely as expected...
> This is dangerous. Who is responsible for that? I guess it's the 
> filesystem, is it?

It's hard to be 100% sure as "detected as remotely missing" could be
various things.  You'd have to use ktrace/etc. or debug logging to be
sure.

> A FUSE file system should return something like IO errors or just
> block, but nothing like "file not found" on a weak network.

Nothing to do with FUSE, but indeed EIO is appropriate.

But if you think that davfs2 can return status that says a file is not
there when that's not true, then it's buggy, and you should fix it or
stop using it.   I'm not really sure what you think is going on, if the
operation to list a directory will return a partial result (with an
success code), or something else?

> Having seen that it's highly risky to do my syncs via public (VPN secured) 
> networks.

and at least somewhat over any other network, even a LAN.

> While unison has some user interaction and I don't run it headless I often 
> can check before applying this issue. But on hundreds of files I often need 
> to check if unison is right about deletions. On Android with Foldersync 
> running always completely headless (accepting/deleting latest file version) 
> I have never seen this issue and it runs almost always on uncertain mobile 
> uplinks.

I don't know anything about Foldersync but I think you mean that
Linux/davfs2 is not involved, in which case it's just a data point that
some other software isn't broken :)



Unison does have -confirmbigdel which is default on, but that's more to
guard against syncing with /mnt when the removable disk isn't mounted.
In your case, I can't think of a reliable heuristic, and I wouldn't want
to add that kind of complexity to work around other buggy software, when
really that other software should be fixed.


I would suggest one of

  ssh to the server and run unison remotely, so you aren't using webdav

  set up a local computer near the server, and ssh to that, so the
  davfs2 hop sees a benign network environment

  debug and fix this.  That's out of scope for unison.

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