Permissions problem I don't understand

[Alan Chandler]

On Tuesday 29 Nov 2005 16:28, Wayne Davison wrote:

> This is an error from your OS, so it I have no way to discern (without
> probing your system) what reason the rename() call has for failing.
> The options you gave should cause rsync to try to rename this file:
>
>     "/bak/rabbit/backup/My Documents/test.file"
>
> to this file:
>
>     /bak/rabbit/archive/test.file
>

Thanks for that - I just tried (as my user backup) to manually do the 
operation with the mv command.  It also failed.

Looking at the reason, I discovered that the first-level directories ( such as 
My\ Documents) created by another rsync operation (not sure what - see below) 
are set to 555 (ie no write permission).  How did I get there.

This whole difficulty came because having been given a new laptop at work, 
that upgraded me from windows 2000 professional (with fat32) to windows xp 
professional (with ntfs) I tried to get rsyncd to run under cygrunsrv  
(because my previous backup regime was a such from my linux server) and 
although it would give a list of modules, had permission denied errors as 
soon as a tried to read any directories.  Never found an answer to that.

So I have changed, to use windows schedular to run a cywin bash shell script 
to do the rsync backup the other way round.  Thats been failing exit code (2) 
- not sure what that is yet.

Now I realise the problem I have examined what I am trying to see what cgywin 
says about the directories on the laptop by running a bash shell and ls -l 
from it.  It says all the "Standard" directories (such as "My Documents") all 
have permissions of 555.


-- 
Alan Chandler
http://www.chandlerfamily.org.uk
Open Source. It's the difference between trust and antitrust.