permissions: make files on CD writable when copying to hard disk

[gumb]

This must be a common issue: I've set up my parents' machine running KDE 4.5 and want them to use the Gwenview import function from the Device Manager popup when transferring image files off photo CDs or other inserted media, since it's the easiest method for them to comprehend.

All the files on their photo discs are r-xr-xr-x by default so they're unable to rotate or modify the images once copied to their hard disk. I want to set one specific images folder on their system to automatically force any files placed there to be rw-r--r-- (and rw-rw-r-- for another shared images directory elsewhere). It seems that umask won't work since that can only take permissions away and not add them, and I'd rather avoid getting into messy ACL configuration.

Is there a way to achieve this either generically or some hidden config in Gwenview itself? I use KRename myself for such tasks but this is way too complex for my parents to understand so I need something that works without them having to do anything.

[Knurpht]

I know the problem, exactly the same with my parents. IIRC (their PC is not on, they're not at home) I handled it by a cron which runs a script that changes the perms. They don't have a shared folder though. I also remember having looked for another, more elegant solution, but it's too long ago.

Create a script which does the 'chmod 755 path-to-imagefolder && chmod 644 path-to-imagefolder/*' for the imagefolders and 'chmod 775 path-to-shared-imagefolder && chmod 664 path-to-shared-imagefolder/*' for the shared imagefolders. Then use Systemsettings - Taskplanner to create a cronjob which does that every 2, 5 or whatever # of minutes.

[hcvv]

Your observation of the masking function of umask is correct.

Why it works as it works is imho:

1) Permission bits are faked/simulated on non-Linux file systems (like the one used on the CD, but also for VFAT and other MS types) by the software drivers that interface to those file systems. Logicaly the r bit is amongst them because you could not even read file on the CD. The x bit is added because the file could contain something executable. The w bit is normaly also added at least for the owner, but not on a CD because of the nature of the device.

2) Copying files (by all sorts of tools) normaly tries to give it the same access bits as the original has. Of course the umask of the process is used to mask bits off when applicable.

The result of this is not what you want for reasons you explained, but they are not illogical from the Unix/Linux point of view. In general many people would not be pleasantly surprised when such a tool would add w bits without asking.

It is possible that someone has a better solution for this problem then I have, but in a similar case I created a cron run (when this is all within the realm of one user, put it in her/his crontab, else root could do this), that contains the appropriate chmod -R statements. And then let cron run this every 5 mins (or when that is not enough to stop all confusion, every minute).

EDIT: I see Knurpht posted something similar , but he is faster!

[ken_yap]

Your observations are correct. You might be able to force the write permission using Posix ACLs. Otherwise you'll need an auxiliary script to change the permissions. Perhaps you could ask the author of gwenview for an enhancement request in future.

If you are making your own CD/DVDs you can turn on Rock Ridge mode with -R to genisoimage to capture to the original owner and permissions instead of forcing them to root and read-only. This is what I do when I backup my home directory to a DVD so that the permissions will be correct on a restore. But this won't help you with CDs from elsewhere.

[gumb]

Thanks for all the swift replies. I've never dabbled with scripts before but from reading the suse help files I assume I simply create a file as follows:

#!/bin/sh

chmod 755 /home/abcde/Albums && chmod 644 /home/abcde/Albums/*
chmod 755 /home/shared/photos && chmod 644 /home/shared/photos/*

I will run this as root but which folder do I put the script in? Will this propogate through all sub-directories?

@ken_yap
I had thought Gwenview's import facility already had some of these advanced functions but maybe that's in an upcoming release. In 4.5 it only has a few basic renaming tools. I'll have a look through the developer Aurelien Gateau's blog and see if he's got anything planned. I'm sure it would be a popular feature.

[hcvv]

You can put the script e.g. in /root/bin (when you are loged in as root from a terminal /root is the home directory of root and it has allready a bin directory). Give it a name of your liking, e.g. sharepics. Do not forget to set the x bit for the owner:

chmod u+x sharepics

There you can do

crontab -e

and add the line (move down with the down arrow, then type o)

*/5 * * * *     /root/bin/sharepics

(after you typed this, press the Esc key and then type :wq)
which will run it every 5 minutes.

[robin_listas]

On 2011-01-03 16:06, hcvv wrote:
>
> You can put the script e.g. in -/root/bin- (when you are loged in as

Why root? It should also work as user. You need to change permissions, not
ownership, no?

Just an idea: create an icon for it and run it (click) after importing a
CD, instead of every five minutes. They should be able to learn that trick.

--
Cheers / Saludos,

Carlos E. R.
(from 11.2 x86_64 "Emerald" at Telcontar)

[hcvv]

I support Carlos.As I stated in post #3 above: "when this is all within the realm of one user, put it in her/his crontab".

And I like the icon idea, but it is up to you.

[gumb]

Yes the icon idea could work. The reason I was intending to run it as root was because I'd originally set root as the owner of the entire shared folder, but that's no longer the case. Also, being a multi-user system, I wanted to ensure that another user would be able to edit files copied into that shared folder, but I guess if I put the script in that folder and make it executable by the group 'users' I can get around that problem.

[hcvv]

When you want more users to edit the same files, both users should be in the same group and the file should be group writable.
Take care, for chmod a file the rules are a bit different. Ownership and accessbits of the directory are then also important.

In my case where files of several users go into a directory, I decided to chmod from the root crontab. But I admit that this is second choice.