Ability to ignore permissions errors

[simonbuerger]

trafficstars

Thanks for this awesome tool!

I have a scenario where the root1 file system only supports 777 permissions. I want the 777 permissions to be propagated to root2, which works on the first sync. But any files created/modified on the root2 normal file system do not have 777 permissions, obviously, so on the watch task the chmod fails to propagate new files back to root1. I can't set perms to 0 and dontchmod because I still need new files from root1 to propagate to root2 with 777 permissions intact.

I can't think of any way around this currently

First prize would be the ability to have different perms/dontchmod preferences depending on the direction (root1->root2 or root2->root1). If that is too much of a change then perhaps a way to try set permissions but to ignore any resulting errors?

[simonbuerger]

For context, the strange 777 volume in question is a mounted Azure app service storage volume on a docker container.

[gdt]

This seems like a really unusual case, and I'm not sure even if there were a prepared PR I'd want to merge it, as the codebase would bear the complexity for the benefit of very few. But it might be ok if it's small. Please see #638 and perhaps treating this like FAT on unix would mostly solve it. And, I probably would want any change to untangle the #638 issues as it all seems related. If you'd like help exploring solutions please follow up on unison-users@.

[tleedjarv]

I can see a way out of this situation, a way which could be very simple to implement (and probably confusing to use). The question is if this solution is of wider interest or will it cause confusion and bugs for other users.

The solution would be:

• add a new preference, something like forceperms or minperms, which you could set to 777
• when reading file permissions, the new preference is used either as a fixed value (in other words, all files seemingly have the same permissions, forceperms) or as a minimum value (in other words, all files seem to have permissions minperms | st_mode)
• comparing and setting the permissions remains the same

This is a bit of a tricky solution. It effectively disables syncing permissions (treats them as constant in case of forceperms) but unlike perms = 0 and dontchmod, it will still actively chmod to your desired permissions. It will also not fail if after setting the permissions something different is read back (which I presume is the point that currently fails for you).

Open questions:

• differences between file and dir permissions? I don't see a use case for the minperms variant above, except perhaps for file and dir difference.

Unless I've overlooked something very obvious and this is a complete dud, it could be implemented with a very few lines of code.

Now, I agree with @gdt, this seems like a very (very) niche usage. I guess the most common non-default usage is perms = 0.

[gdt]

Having let this sit a few minutes, my reaction is that a filesystem that doesn't do permissions, while of course deficient, is just a fs without permissions. I am not inclined to get into treating it like it was permissions that are semantically valid but that you can't set for some reason. I suspect if someone digs into #638 we'll end up with a general treatment of "this fs doesn't support permissions (and maybe uid/gid)", and this fs will be a case of that.

[tleedjarv]

Is it really that? Anyone, including the original reporter, can set perms = 0 (and perhaps also dontchmod), this is not related to #638. What I understand this issue to be about is that the reporter does not want to set perms = 0.

Maybe the question is, in this situation, why would one not want to set perms = 0 in the first place? @simonbuerger perhaps you can clarify why do you want to propagate the 777 permissions back to root2? Then the question is, is it the synchronizer's job to set requested permissions for the files it creates, even if the other end does not support permissions?

[gdt]

I see it as related because my view is that the normal approach is that all filesystems meet POSIX and if you want to sync, you want to sync everything. Then there are accomodations for deficient filesystems and for preferences. So agreed that this is not strictly related in what should perhaps change, but I see it as related in that I'd like a coherent and consistent theory of what we are doing about all these issues and why instead of accumulating point solutions.

[vogu66]

Hello, Just started to use unison and I ran into the issue as well: NTFS file systems -- which may be kept for Windows compatibility -- only support 777, when mounted through fstab as user partitions.

[gdt]

I'm calling it a dup of #867.