You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Current filelock implementation set permission by a fixed permission in open and fchmod. The default 644 is reasonable, but this also disables the default acl write.
withsuppress(PermissionError): # This locked is not owned by this UID
os.fchmod(fd, self._context.mode)
But this inconvenience won't happen when we create files normally, say using touch with umask 022. If there is default acl, the group write bit will still be on so the default acl is effective. Turns out the umask is handled by operating system with regard to default acl, but a specified 0 mode bit in open and fchmod are not.
Then why not let umask handle mode? I think the main reason is for multi-threading where each thread may change umask (#204). But this acl problem really cause great inconvenience when locks needed to be updated by different users (file locks are not removed after release). My case is sharing huggingface datasets under .cache with default acl, but now the user who creates the lock has to manually delete it or others cannot recreate it. I believe there are many scenarios like this and this is not those packages' fault.
Currently I haven't found any good solution. I thought of checking default acl to decide whether to turn on group perm but didn't find a python function that can check acl without executing command. Hope to get some help.
The text was updated successfully, but these errors were encountered:
In modern unix-like system, a directory can have default access control list (acl) applied to newly created files under it (
setfacl -d
). To make acl effective, the corresponding group permission must be open. https://unix.stackexchange.com/questions/328806/acl-named-group-permissions-not-overriding-file-permissions-whyCurrent filelock implementation set permission by a fixed permission in open and fchmod. The default 644 is reasonable, but this also disables the default acl write.
filelock/src/filelock/_unix.py
Lines 42 to 44 in ee4c7ba
But this inconvenience won't happen when we create files normally, say using
touch
with umask 022. If there is default acl, the group write bit will still be on so the default acl is effective. Turns out the umask is handled by operating system with regard to default acl, but a specified 0 mode bit in open and fchmod are not.Then why not let umask handle mode? I think the main reason is for multi-threading where each thread may change umask (#204). But this acl problem really cause great inconvenience when locks needed to be updated by different users (file locks are not removed after release). My case is sharing huggingface datasets under .cache with default acl, but now the user who creates the lock has to manually delete it or others cannot recreate it. I believe there are many scenarios like this and this is not those packages' fault.
Currently I haven't found any good solution. I thought of checking default acl to decide whether to turn on group perm but didn't find a python function that can check acl without executing command. Hope to get some help.
The text was updated successfully, but these errors were encountered: