GNOME Bugzilla – Bug 560494
g_file_copy always preserves permissions, even if G_FILE_COPY_ALL_METADATA flag is not set
Last modified: 2018-05-24 11:38:19 UTC
[ Original report: http://bugs.debian.org/505398 by Maximiliano Curia ] gio's g_file_copy can be tested using gvfs-copy command from the gvfs-bin package or hacking nautilus from experimental to not set G_FILE_COPY_ALL_METADATA. A simple test: $ mkdir src dst; touch src/test; chmod 7777 src/test; cp src/test dst/cp $ gvfs-copy src/test dst/gvfs-copy; ls -l dst total 0 -rwxr-xr-x 1 maxy maxy 0 nov 12 2008 cp -rwsrwsrwt 1 maxy maxy 0 nov 12 2008 gvfs-copy This behavior is incompatible with acls default settings and users umask setting.
Not setting G_FILE_COPY_ALL_METADATA doesn't mean copying no metadata. It just means that we should only copy the default set of metadata. This includes permissions, but not e.g. owner and atime. The reason that permissions are copied is that this is what is what is typically expected in gui apps when requesting a file copy.
This behavior invalidates any UMASK setting and any acl default permissions settings, any user that did set those will want the system obey them. In a particular use case where a user would want to maintain a file permission (overriding UMASK) the user can change the destination file permissions. In the case the user uses ACL, gvfs can't help them to fix the ignored settings. The current acl implementation works well with non-acl aware applications, as long as the applications don't mess around with the file permissions. Also, gvfs does a two-pass algorithm to copy the files (one for content, and another for metadata) using an unnecessary number of resources (keeping all these in memory), that wouldn't be needed if applying only the first pass. Considering: - Not copying "metadata" would make gvfs behave as other system tools - A user of gvfs can change standard permissions but not acl - The current acl implementation "works as expected" for programs that don't touch metadata. - The way gvs uses to copy metadata is quite inefficient. I believe that a program must know it's limits and do the best effort to satisfy the users needs without making it impossible to fix "bad guesses", and given two valid options the "least resource consumption" should be, at least, the default option.
Created attachment 246109 [details] [review] Add option to use default perms
I found this bug while working on: https://bugzilla.gnome.org/show_bug.cgi?id=699959 With the above patch: $ mkdir src dst; touch src/test; chmod 7777 src/test; cp src/test dst/cp $ gvfs-copy -d src/test dst/gvfs-copy; ls -l dst total 0 -rwxr-xr-x 1 walters walters 0 Jun 5 19:23 cp -rw-r--r-- 1 walters walters 0 Jun 5 19:23 gvfs-copy $ So probably still not quite what people would want, but oh well, that's the semantics we have for g_file_copy(). While we could debate whether the possible flags and their semantics are right, I don't think we can change them now. Nautilus could choose to use G_FILE_COPY_TARGET_DEFAULT_PERMS nowadays, but that also seems like a bad idea.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/glib/issues/174.