Copying Files From CD/DVD Sets Permissions To Read Only

Thanks for your bug report. This bug has been reported to the developers of the software. You can track it and make comments here: http://bugzilla.gnome.org/show_bug.cgi?id=523129

I have the same problem to me, but I ussed x-term in Blackbox and the problem continues.
In Gutsy this is not happened. I confirmed this bug in 3 computers.

I have also this bug, and it's very annoying.

I have set "make=0777" ISO-9660 file system parameter under CD - Properties - Device - Mount Options, and files copied are rwx, but folders are stil r-x so I have to chmod +w "folder" to have control over files anyway.

I have an idea to put chmod +w -R /home/user/ into a /etc/crontab to run this command every minute.

Regular users will maybe tolerate it that way.

I have the same problem when copying files from read-only drives. I fix it using chmod in the destination folder, but it's annoying. Hope it is corrected.

there is no need to add comments to say you have the same issue on a confirmed bug

the bug has been fixed upstream now

Is this fix available trough automatic update for Hardy?

On Tue, Oct 14, 2008 at 9:19 AM, Sebastien Bacher <email address hidden> wrote:

> the bug has been fixed upstream now
>
> ** Changed in: gvfs (Ubuntu)
> Status: Triaged => Fix Committed
>
> --
> Copying Files From CD/DVD Sets Permissions To Read Only
> https://bugs.launchpad.net/bugs/200462
> You received this bug notification because you are a direct subscriber
> of the bug.
>

the hardy task has not been closed yet which means the fix has not been uploaded to hardy, in fact the change is not in intrepid either and will not be available before next cycle. the way it works require new glib function and that's not something which usually qualify for stable updates so not likely to go to hardy

So I guess support has already ended for Hardy? That was fast. I thought
it was supposed to be an LTS release.

Sebastien Bacher wrote:
> the hardy task has not been closed yet which means the fix has not been
> uploaded to hardy, in fact the change is not in intrepid either and will
> not be available before next cycle. the way it works require new glib
> function and that's not something which usually qualify for stable
> updates so not likely to go to hardy
>
>

So I guess a lot of people will quit using that stable (Hardy Heron) bugware
release.

Explain to simple users that they have to do chmod on files they simply copy
from a CD...

On Wed, Oct 15, 2008 at 12:37 AM, Jeremy LaCroix
<email address hidden>wrote:

> So I guess support has already ended for Hardy? That was fast. I thought
> it was supposed to be an LTS release.
>
> Sebastien Bacher wrote:
> > the hardy task has not been closed yet which means the fix has not been
> > uploaded to hardy, in fact the change is not in intrepid either and will
> > not be available before next cycle. the way it works require new glib
> > function and that's not something which usually qualify for stable
> > updates so not likely to go to hardy
>

those are not really constructive comments nor motivating for the people who contribute for free at fixing all those issues, hardy still get fixes and security updates but backporting is lot of work and the team doing this job is small and overworked and can't possible backport every code change made in intrepid

Sorry for harsh word...

Thank You for this fix. But guess I'll have to give up on Hardy, at least
when I install Ubuntu on simple users PCs.
Keep up the good work.

This bug still exist for me in Ubuntu 8.10 Intrepid. According to the discussion above it should be fixed already... ?!

the bug has been fixed upstream but not in ubuntu yet, it should be fixed in jaunty when GNOME 2.25 is uploaded

the issue is fixed in jaunty now

is there any possibility to fix this in hardy?

the change is non trivial and the issue is not a security or a data corruption one so it's low priority for a stable update

Permissions as set up during install.

keith@keith-desktop:/media$ ls -al
total 36
drwxr-xr-x 5 root root 4096 2009-04-02 21:44 .
drwxr-xr-x 20 root root 4096 2009-03-05 13:55 ..
lrwxrwxrwx 1 root root 6 2009-03-05 12:10 cdrom -> cdrom0
drwxr-xr-x 2 root root 4096 2009-03-05 12:10 cdrom0
drwxr-xr-x 2 root root 4096 2009-03-05 12:10 cdrom1
drwx------ 3 keith root 8192 1970-01-01 01:00 disk
-rw-r--r-- 1 root root 110 2009-04-02 21:44 .hal-mtab
-rw------- 1 root root 0 2009-04-02 21:44 .hal-mtab-lock

Change the permissions

keith@keith-desktop:/media$ sudo chmod 777 cdrom0
keith@keith-desktop:/media$ sudo chmod 777 cdrom1
keith@keith-desktop:/media$ ls -al
total 36
drwxr-xr-x 5 root root 4096 2009-04-02 21:44 .
drwxr-xr-x 20 root root 4096 2009-03-05 13:55 ..
lrwxrwxrwx 1 root root 6 2009-03-05 12:10 cdrom -> cdrom0
drwxrwxrwx 2 root root 4096 2009-03-05 12:10 cdrom0
drwxrwxrwx 2 root root 4096 2009-03-05 12:10 cdrom1
drwx------ 3 keith root 8192 1970-01-01 01:00 disk
-rw-r--r-- 1 root root 110 2009-04-02 21:44 .hal-mtab
-rw------- 1 root root 0 2009-04-02 21:44 .hal-mtab-lock

Looks 'good'. However having written to a rewritable disk using the unmodified permissions inserting that disk into, in this case cdrom1, causes this to happen....

keith@keith-desktop:/media$ ls -al
total 34
drwxr-xr-x 5 root root 4096 2009-04-02 21:44 .
drwxr-xr-x 20 root root 4096 2009-03-05 13:55 ..
lrwxrwxrwx 1 root root 6 2009-03-05 12:10 cdrom -> cdrom0
drwxrwxrwx 2 root root 4096 2009-03-05 12:10 cdrom0
dr-xr-xr-x 4 root root 2048 2009-04-02 20:21 cdrom1
drwx------ 3 keith root 8192 1970-01-01 01:00 disk
-rw-r--r-- 1 root root 110 2009-04-02 21:44 .hal-mtab
-rw------- 1 root root 0 2009-04-02 21:44 .hal-mtab-lock

The previously changed permission for cdrom1 have picked up on the permissions used during creation of the volume and reverted to their original settings. I apologise. Before investigating this further I had had a play trying to 'fix' it so the 'original' install settings as presented here might not be the actual ones. I'm slightly confused that Brasero and other GUI tools were able to write to a blank disk in the first place on a non-root account. Obviously they can but then fall over later. As I say, sorry, I haven't been very stringent about the way I've investigated this. I've been typical me and just started mashing about with things.

If I remove the disk then....

keith@keith-desktop:/media$ ls -al
total 36
drwxr-xr-x 5 root root 4096 2009-04-02 21:44 .
drwxr-xr-x 20 root root 4096 2009-03-05 13:55 ..
lrwxrwxrwx 1 root root 6 2009-03-05 12:10 cdrom -> cdrom0
drwxrwxrwx 2 root root 4096 2009-03-05 12:10 cdrom0
drwxrwxrwx 2 root root 4096 2009-03-05 12:10 cdrom1
drwx------ 3 keith root 8192 1970-01-01 01:00 disk
-rw-r--r-- 1 root root 110 2009-04-02 21:44 .hal-mtab
-rw------- 1 root root 0 2009-04-02 21:44 .hal-mtab-lock

The permissions revert to the ones that I changed them to. This looks good....

In the mean time if you look at the mounted volume properties under Gnome...

http://www.overkill.talktalk.net/ubuntu/020409/
http://www.overkill.talktalk.net/ubuntu/02...

Hardy has seen the end of its life and is no longer receiving any updates. Marking the Hardy task for this ticket as "Won't Fix".