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 514084 - Executable bit cleared when copying files.
Executable bit cleared when copying files.
Status: RESOLVED FIXED
Product: nautilus
Classification: Core
Component: [obsolete] GIO
2.21.x
Other Linux
: Normal major
: ---
Assigned To: Nautilus Maintainers
Nautilus Maintainers
Depends on:
Blocks:
 
 
Reported: 2008-02-03 15:03 UTC by Francesco Fumanti
Modified: 2008-02-14 11:00 UTC
See Also:
GNOME target: ---
GNOME version: 2.21/2.22



Description Francesco Fumanti 2008-02-03 15:03:36 UTC
Please describe the problem:
When I duplicate a folder by using the Edit->Duplicate menu item, the executable bit is not set in the copy of files where it was set. 

Steps to reproduce:
1. go to a folder that contains some files with 755 permission (for example a source folder with a configure script) 
2. create a copy of the folder by using the Edit->Duplicate menu 
3. 


Actual results:
In the example of the source package: the executable bit of the copy of the configure file will be cleared. (It also happens with the other files whose original was an executable file.) 

Expected results:
The state of the executable bit of the copy should be the same as that of the original file. 

Does this happen every time?
I think so. 

Other information:
Comment 1 Alon Zakai (kripken) 2008-02-12 13:50:10 UTC
I can confirm this bug (running the latest Ubuntu Hardy).
Comment 2 Cosimo Cecchi 2008-02-12 19:28:45 UTC
Confirming and increasing severity.

This happens also if you try to just copy the file, and is because in copy_move_file () in nautilus-file-operations.c, we do not specify G_FILE_COPY_ALL_METADATA for the copy, and the attribute G_FILE_ATTRIBUTE_ACCESS_CAN_EXECUTE seems to be not in the default set for the copy, so my guess is that this is a GLib bug.
I think we should add this to the default set, at least for the local files.
Comment 3 Cosimo Cecchi 2008-02-14 00:29:31 UTC
I think bug #515777 is caused by the came thing.
Comment 4 Alexander Larsson 2008-02-14 11:00:35 UTC
Fixed:

2008-02-14  Alexander Larsson  <alexl@redhat.com>

        * glocalfile.c:
	Copy permissions with file on copy (#514084)
	This is what cp does and makes sure e.g. the
	exec permissions are kept.
	Its kinda weird in that it keeps the permission bits
	the same while the uid and gid are different. However
	the new uid is the user so its not a security issue,
	and I've heard no complaints about cp on this issue.