On Sat, Dec 27, 2003 at 04:39:08PM -0800, Jim Salter wrote:
> JW: in this instance, since he used the -a switch, shouldn't have rsync
> sync'ed the file again anyway, since the file modification date would
> (should?) have been updated when he renamed the file?
Renaming a file (per SUSv3 and POSIX) does not change the
mtime of the file (read inode). All that is changed with a
rename is the directory (whose mtime should be changed).
If he had touched the file it should have done an update
which would have created a temp file, then renamed the temp
file. I'm not sure whether he would wind up with both files
or just the new one. That would depend on the behavior of
rename(2) but i suspect he'd get both. A subsequent run
with --delete _should_, i think, get rid of the old one.
> Alain: *does* Panther "touch" the file (and update the file modification
> datestamp) when you rename it?
>
> -J
>
> jw schultz wrote:
> >On Sat, Dec 27, 2003 at 12:28:06PM +0100, alain content wrote:
> >
> >>Hi,
> >>I found this surprising behavior with rsync (version 2.5.7 protocol
> >>version 26) on Mac OS X (Panther, 10.3.2) :
> >>
> >>Suppose you have a folder "Source" containing a file named "abc", and its
> >>backup as folder "Clone", created by rsync :
> >>
> >>rsync -a ~/Desktop/Source/ ~/Desktop/Clone
> >>
> >>
> >>Now change the name of file "abc" into "ABC" and re-sync :
> >>
> >>rsync -av ~/Desktop/Source/ ~/Desktop/Clone
> >>
> >>
> >>>building file list ... done
> >>>wrote 141 bytes read 20 bytes 107.33 bytes/sec
> >>>total size is 6148 speedup is 38.19
> >>
> >>Not good : the change has not been done !
> >>And suppose you do this:
> >>rsync -av --delete-after ~/Desktop/Source/ ~/Desktop/Clone
> >>
> >>>building file list ... done
> >>>deleting a file named abc
> >>>wrote 145 bytes read 20 bytes 330.00 bytes/sec
> >>>total size is 6148 speedup is 37.26
> >>
> >>Much worse, the file is not preserved in the backup.
> >>There is a workaround though :
> >>
> >>rsync -av --delete ~/Desktop/Source/ ~/Desktop/Clone
> >>
> >>>building file list ... done
> >>>deleting a file named abc
> >>>./
> >>>a file named ABC
> >>>wrote 181 bytes read 36 bytes 434.00 bytes/sec
> >>>total size is 6148 speedup is 28.33
> >>
> >>However, the behavior is inconsistent and can result in incomplete copies
> >>or
> >>backups.
> >
> >
> >That sounds like a filesystem that preserves case but is
> >insensitive to case.
> >
> >Rsync uses lstat to see if a file exists. On case
> >insensitive filesystems lstat("abc", buf) will succeed if
> >the correct name is "ABC". In other words, it isn't rsync's
> >fault if it believes the OS when the OS lies.
> >
> >Case insensitive filesystems are not safe destinations for
> >rsync because if two paths exist with only a difference in
> >case ("Mail" and "mail") they will conflict.
> >
> >There might be an option to mount the filesystem with case
> >sensitivity turned on. Using that option would fix this
> >problem.
> >
>
> --
> To unsubscribe or change options:
> http://lists.samba.org/mailman/listinfo/rsync
> Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
>
--
________________________________________________________________
J.W. Schultz Pegasystems Technologies
email address: [EMAIL PROTECTED]
Remember Cernan and Schmitt
--
To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
