rsync - Feb 2008 - Rsync problems with some files & timestamp

Hi,

rsync 2.6.8 on OES 2 Linux

On an OES 2 Linux server I mount a Netware volume (ncpmount) that is the
destination server.

All volumes are NSS.

Some files are renamed in the destination volume.

For example :

(/media/backup is the NCP mount point )


rsync: rename "/media/backup/USR/SYSTEM32/.AUTOCHK.EXE.xDMw7T" ->
"USR/SYSTEM32/AUTOCHK.EXE": Permission denied (13) 
 
Why only some files? Why rsync try to rename them? Why Permission denied?
The script is launched with root. Is that some temp files? 
The Netware volume is mounted with a user that has all rights on the volume. 

If I rsync from the source NSS volume locally (on the etx3 fs), then the
problem does not occurs.

Another thing is that the timestamp is not correct on the destination
server, but only for some files! These file are one hour less in the
destination server.

Here is the parameters I use with rsync :

 

rsync -v -t --delete --exclude=$EXCLUDE -e --ignore-errors $SRCPATH
$DSTPATH
>> mail.txt 
 
Tanks in advance!
-- 
View this message in context:
http://www.nabble.com/Rsync-problems-with-some-files---timestamp-tp15476237p15476237.html
Sent from the Samba - rsync mailing list archive at Nabble.com.

On Thu, 2008-02-14 at 00:49 -0800, Zemitch wrote:
> rsync 2.6.8 on OES 2 Linux
> 
> On an OES 2 Linux server I mount a Netware volume (ncpmount) that is the
> destination server.
> 
> All volumes are NSS.
> 
> Some files are renamed in the destination volume.
> 
> For example :
> 
> (/media/backup is the NCP mount point )
> 
> 
> rsync: rename "/media/backup/USR/SYSTEM32/.AUTOCHK.EXE.xDMw7T"
->
> "USR/SYSTEM32/AUTOCHK.EXE": Permission denied (13) 
>  
> Why only some files? Why rsync try to rename them? Why Permission denied?
> The script is launched with root. Is that some temp files? 
> The Netware volume is mounted with a user that has all rights on the
volume.
Rsync transfers a regular file by writing its data to a temporary file
in the destination and then renaming the temporary file over the
original.  This is why rsync is attempting renames; I don't know why
they are failing on your particular filesystem.  Possibly another client
of the destination NSS volume had AUTOCHK.EXE open and the NSS
filesystem wouldn't allow the file to be replaced while it was open?
> Another thing is that the timestamp is not correct on the destination
> server, but only for some files! These file are one hour less in the
> destination server.
This is probably related to daylight savings time.  Rsync copies mtimes
in seconds-since-the-Epoch, but if the two machines convert these times
into human-readable times according to different conventions, there may
appear to be differences.  See if there are any NSS configuration
settings for daylight savings time.
> Here is the parameters I use with rsync :
> 
> rsync -v -t --delete --exclude=$EXCLUDE -e --ignore-errors $SRCPATH
$DSTPATH
Matt

Matt,

Thanks for your response.

These settings are working quit well :

rsync -av --exclude=$EXCLUDE --delete --ignore-errors --no-o --no-p
--chmod=ugo=rwX $SRCPATH $DSTPATH >> mail.txt

I will now try to find a solution about timestamps issue. As far as I know
there is no NSS configuration
settings for daylight savings time.



-- 
View this message in context:
http://www.nabble.com/Rsync-problems-with-some-files---timestamp-tp15476237p15480795.html
Sent from the Samba - rsync mailing list archive at Nabble.com.