Closed pianohacker closed 7 years ago
I think what you'd really want here is a "don't trust permissions on the local filesystem" flag which would probably work by pretending the client permissions were actually those on the server (if present), which would be activated with some kind of optional flag in the sync mode (maybe like cud/cud+m
?) or possibly a sync rules flag outside the sync mode. This is less logic and doesn't clutter all sync modes to accomidate a filesystem quirk.
Having new mode bits would allow for [ab]using ensync to handle "I botched the permissions on one replica, let me restore from another" by using -Mu-/--u-
or --u-/-Mu-
, but it's not really the kind of thing ensync is for and is probably better accomplished with mtree
anyway. (Apparently debian doesn't have mtree
anymore though?)
VFAT filesystems
vfat of course brings other problems that are far harder to address, like not having symlinks and preventing ensync from doing case-change-only renames.. sometimes due to its weird case-sensitive-only-for-long-filenames behaviour.
touch foo # Ok, created "foo"
touch Foo # Error, "File already exists"
touch 'Program Files' # Ok, created "Program Files"
touch 'PROGRA~1' # Ok, touched "Program Files"
touch 'Program files' # Ok, created "Program files" (!)
Yeah, that seems reasonable as a per-client setting.
Implemented in 0.2.1. You can put something like this in the config:
[[rules.root.files]]
trust_client_unix_mode = false
Currently, the sync configuration syntax (cud/cud) ties syncing of mode bits and file contents together. There are a number of circumstances (VFAT filesystems/noexec) where it is either impossible or undesirable to sync mode bits, and it would be handy to be able to selectively turn off mode bit syncing.
One possible option would be to add a field to the sync syntax (cmud/cmud), though cm-d doesn't make a ton of sense.