how to tell what files changed?
erikn at myphysicslab.com
Thu Apr 6 20:03:29 GMT 2006
Here is what I've learned so far about using rsync on Mac OS X 10.4.6
("Tiger") in case others find it useful:
I did a test where I rsync a small directory with a few text files,
from one directory to another directory on the same Mac OS X hard
disk (disk was formatted with Apple's default HFS+ filesystem). The
first time I rsync, everything gets transferred, of course. If I
immediately rsync again using rsync with --verbose option, then it
seems that only the so-called "Apple Double" files are being
transferred (or examined). For example, I see output like this from
$ sudo rsync -E -a -x -S --delete -v --stats ~/Documents/rsource ~/
building file list ... done
(The .DS_Store file is a hidden file where Apple's Finder puts file
metadata like where the icon is dragged to, etc.) Here is some
background on these Apple Double files (from "Mac OS X Tiger for Unix
Although UFS doesn't natively support resource forks or HFS+
attributes, Mac OS X finds a place to stash that info. If the file
has either a resource fork or any attributes that depend on HFS+
semantics, this information goes into a file named ._filename, where
filename is the name of the original file (this is known as the Apple
Double format )
Before Mac OS X Tiger, you had to be very careful with what you did
at the command line. If you used cp, mv, rsync, or any of the other
command line utilities that move stuff around, you could have lost
part of your file. It was easy to miss this sort of mayhem, since
this metadata isn't apparent until you go looking for it, and it
wasn't always a disaster.
Fortunately, Mac OS X Tiger finally makes this problem (mostly) go
away by making all the cp, mv, and rsync command-line utilities aware
of the resource forks and HFS+:
So, my hypothesis is this: Apple has modified rsync so that any
files with resource forks or HFS+ attributes appear to rsync as two
files: the regular data fork, plus the Apple Double file that begins
with "._". These Apple Double files do not seem to exist before or
after the rsync, only DURING the rsync process. (This is when the
volume is an Apple HFS+ volume... if it was UFS then the Apple Double
files probably would appear). At least they aren't visible with ls -
la in the Terminal, which I take to mean they don't exist.
I guess the bottom line for me is to not worry and be happy. Meaning
I should just ignore or filter out all the messages from rsync about
the Apple Double files.
(P.S. I'm not doing rsync between Windows and Mac, its just that I
recently moved all my files from Windows to Mac, and noticed that the
creation dates are missing)
Any other ideas on this subject?
On Apr 6, 2006, at 12:54 AM, John Van Essen wrote:
> On Wed, 5 Apr 2006, Erik Neumann <erikn at myphysicslab.com> wrote:
>> Seems that many of the files I just transferred from Windows to
>> Mac OS X came across with ***blank creation dates***.
> Egad - rsyncing between different OSes and neither OS is *nix.
> That's pretty rare. Although Mac OS X is technically *nix I guess.
>> When rsync makes copies on the target, those copies get a creation
>> date that is equal to the modification date.... therefore the two
>> files are not the same (the creation date is blank on Mac OS X file,
>> but is not blank in the target archive), and rsync has to check all
>> these "blank creation date" files.
> Rsync doesn's care about creation dates - only modification dates.
> [ snip ]
>> BTW, here is the command I've been using:
>> sudo rsync -E -a -x -S --delete --exclude=Library/Caches --
>> stats ~ /Volumes/backup_40GB
>> the -a option includes -t so that wasn't the problem.
> Right. Where are you running this - on the Mac and copying to a
> mounted Windows filesystem? If so, then you are probably falling
> victim to the 2 second granularity mentioned in the cited section
> in the FAQ, and roughly half your files will be getting re-synced
> every time if you are transferring files to a Windows filesystem.
> Try adding --modify-window=1
-------------- next part --------------
HTML attachment scrubbed and removed
More information about the rsync