how to tell what files changed?

[Erik Neumann]

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  
rsync:

$ sudo rsync -E -a -x -S --delete -v --stats ~/Documents/rsource ~/ 
Documents/rtarget
building file list ... done
rsource/._.DS_Store
rsource/._AdjectiveNounTemplate.java
rsource/._AdjectiveNounTest.java
rsource/._AdjectiveTerminal.java
rsource/._AdjectiveTerminalTest.java

(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  
Geeks"):

<quote>
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+:
</quote>

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?

--erikn


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
>
>     John
>
>
>

-------------- next part --------------
HTML attachment scrubbed and removed