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 550816 - [PATCH] Don't set r/o permissions when copying from r/o locations
[PATCH] Don't set r/o permissions when copying from r/o locations
Status: RESOLVED FIXED
Product: nautilus
Classification: Core
Component: File and Folder Operations
2.23.x
Other All
: Normal normal
: ---
Assigned To: Nautilus Maintainers
Nautilus Maintainers
: 523129 570593 (view as bug list)
Depends on: 550795
Blocks:
 
 
Reported: 2008-09-04 10:39 UTC by Nelson Benitez
Modified: 2009-05-15 16:22 UTC
See Also:
GNOME target: ---
GNOME version: 2.23/2.24


Attachments
Set G_FILE_COPY_TARGET_DEFAULT_PERMS when copying from r/o locations (4.07 KB, patch)
2008-09-04 10:47 UTC, Nelson Benitez
accepted-commit_now Details | Review

Description Nelson Benitez 2008-09-04 10:39:48 UTC
Please describe the problem:
Hi!,
this is a regression from bug 167102 , the feature was lost in the migration to gio, the gio patch for this is in bug 550795 , I'm attaching here the patch for nautilus.

Steps to reproduce:
1. 
2. 
3. 


Actual results:


Expected results:


Does this happen every time?


Other information:
Comment 1 Nelson Benitez 2008-09-04 10:47:35 UTC
Created attachment 117995 [details] [review]
Set G_FILE_COPY_TARGET_DEFAULT_PERMS when copying from r/o locations

Set G_FILE_COPY_TARGET_DEFAULT_PERMS flag to files in a copy job when they're in a readonly filesystem ("filesystem::readonly" attribute), also set the flag when doing g_file_copy_attributes() on foldres being created as part of that copy job..
Comment 2 Christian Neumair 2008-09-04 19:00:30 UTC
Thanks, good job! Feel free to commit it as soon as you have approval from the gvfs people - and raise the required gvfs version in configure.in.
Comment 3 Nelson Benitez 2008-09-22 16:02:46 UTC
It's now commited, marking as fixed, thank you!
Comment 4 Claudio Saavedra 2008-09-23 14:02:43 UTC
Wait a sec... you need to branch before doing that!
Comment 5 Cosimo Cecchi 2008-09-24 17:39:52 UTC
Nelson, I reverted your commit as we can't depend on GLib 2.19.0 before branching.
Setting patch status as "commit_after_freeze" so that we can commit it after branching.
Comment 6 Nelson Benitez 2008-09-24 17:55:44 UTC
(In reply to comment #5)
> Nelson, I reverted your commit as we can't depend on GLib 2.19.0 before
> branching.
> Setting patch status as "commit_after_freeze" so that we can commit it after
> branching.
> 

Ok, thanks Cosimo, and sorry for the incovenience, I thought it could be commited to trunk.
Comment 7 Alexander Larsson 2008-09-25 12:15:43 UTC
*** Bug 523129 has been marked as a duplicate of this bug. ***
Comment 8 Alexander Larsson 2008-09-26 08:01:12 UTC
Actually, I'm not sure we can apply this as is when we branch fro gnome 2.26 either. The release cycle of glib is generally longer than for Gnome, so we might not be using the new glib in Gnome 2.26.

I'd recommend adding a configure check for G_FILE_COPY_TARGET_DEFAULT_PERMS and using it if availible instead.
Comment 9 Nelson Benitez 2008-10-07 08:51:24 UTC
Ok, I prefer to wait to when nautilus can use glib 2.19.0 than cluttering the code with #ifdefs.
Comment 10 Cosimo Cecchi 2008-10-09 15:55:50 UTC
(In reply to comment #8)
> Actually, I'm not sure we can apply this as is when we branch fro gnome 2.26
> either. The release cycle of glib is generally longer than for Gnome, so we
> might not be using the new glib in Gnome 2.26.
> 
> I'd recommend adding a configure check for G_FILE_COPY_TARGET_DEFAULT_PERMS and
> using it if availible instead.

It seems that GLib 2.20 will be released in time for GNOME 2.26, so I guess we could commit this to trunk?
Comment 11 Alexander Larsson 2008-10-13 12:56:51 UTC
Yes, we now depend on 2.19.0, so this can go in again.
Comment 12 Nelson Benitez 2008-10-13 18:55:40 UTC
(In reply to comment #11)
> Yes, we now depend on 2.19.0, so this can go in again.

 I have committed it, so this is now fixed, thank you :) 

Comment 13 Alexander Larsson 2009-03-05 12:39:14 UTC
*** Bug 570593 has been marked as a duplicate of this bug. ***
Comment 14 Cristiano Almeida 2009-05-15 12:58:45 UTC
I'm under Ubuntu 9.04 and this bug still annoys me, since 8.04 to be exact. I'm new here and haven't understood how to apply this patch to solve the problem. Can you please write here a step-by-step to aply the patch in Ubuntu 9.04 (nautilus 2.26.2)?
Comment 15 Nelson Benitez 2009-05-15 13:31:02 UTC
Hi Cristiano, I'm also on ubuntu 9.04 and this works fine for me, so it's probably a problem with your setup.
Comment 16 Cristiano Almeida 2009-05-15 16:22:37 UTC
Thanks Nelson. I was using a modified Ubuntu 9.04 I get on the web. Now I've just checked it out on the normal Ubuntu and it works fine. Sorry for the inconvenience.