After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 560494 - g_file_copy always preserves permissions, even if G_FILE_COPY_ALL_METADATA flag is not set
g_file_copy always preserves permissions, even if G_FILE_COPY_ALL_METADATA f...
Status: RESOLVED OBSOLETE
Product: glib
Classification: Platform
Component: gio
2.16.x
Other Linux
: Normal normal
: ---
Assigned To: gtkdev
gtkdev
Depends on:
Blocks:
 
 
Reported: 2008-11-12 12:38 UTC by Josselin Mouette
Modified: 2018-05-24 11:38 UTC
See Also:
GNOME target: ---
GNOME version: 2.21/2.22


Attachments
Add option to use default perms (2.07 KB, patch)
2013-06-05 18:26 UTC, Colin Walters
none Details | Review

Description Josselin Mouette 2008-11-12 12:38:17 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.
Comment 1 Alexander Larsson 2009-03-03 15:43:28 UTC
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.

Comment 2 Maximiliano Curia 2009-03-15 18:08:18 UTC
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.
Comment 3 Colin Walters 2013-06-05 18:26:37 UTC
Created attachment 246109 [details] [review]
Add option to use default perms
Comment 4 Colin Walters 2013-06-05 18:29:21 UTC
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.
Comment 5 GNOME Infrastructure Team 2018-05-24 11:38:19 UTC
-- 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.