Lee Cullens wrote:
Wayne Davison wrote:
On Sun, Aug 21, 2005 at 02:43:50PM -0400, Lee Cullens wrote:
The most logical place to ask this question is this rsync forum, but
no one has yet even acknowledged the issue.
I was hoping that a MacOS user would respond and help you out since this
issue appears to be specific to MacOS.
As for why the rename is happening, that's how rsync updates all the
files (unless overridden via options) -- it creates a new version and
renames it over the old version. The main reason for this is because of
how the rsync algorithm works, but it is also a very safe idiom in that
any process that has the file open (such as when a program is using the
binary as read-only swap) is not disrupted as it would be if new data
was simply written out to the old inode.
I assume the root issue has to do with something non-Posix going on with
the files in that directory, but I don't know enough about MacOS to be
able to speculate about what that might be.
..wayne..
Thank you for the reply Wayne,
Yes, that makes sense and, of course, yet another reading of the man
pages gives that impression if one is properly attuned :-) So, the
option to override this behavior would be "--inplace" I assume, and do
yo know of any caveats regarding such locally?
If I might be so naive, may I also ask about the "-H" option? OS
X Darwin is BSD with Apple's own twists thrown in, and uses a lot of
hard links, symbolic links and their own "aliases" to present the file
system to the GUI user. I am creating first a full direct (no
intermediate image) clone with asr of my working volume
"Mirrored_HD_Set" to an external HD "LaCie_Disk_A" (or B or C ...) as
a bootable volume and I know from testing that just reversing source
and destination in asr restores a fully functional working volume. In
the file system "LaCie_Disk_A" is a mount point in /Volumes/ but I
notice the mount point of "Mirrored_HD_Set" is actually a symbolic
link to (guess what) "Mirrored_HD_Set/" (wherever that is) just to
give you an idea of the hijinks.
Now, I am using the rsync options "-axEuvv --delete
--exclude-from=..." (so far) to differentially update the clone. On
initial readings of the rsync man pages I included the -H option, but
on subsequent readings I took it out. Can you tell me if I might be
wrong in doing so?
Thanks again for your reply - it was greatly appreciated,
Lee C
Wayne,
Sorry for missing such an obvious (in hind sight) thought. I removed
/System/Library/CoreServices/ from my excludes file and included the
rsync --inplace option and the issue is resolved :-) The differentially
updated clone is still bootable and seems ok. I might add that the issue
is resolved locally at least, because using the --inplace option is
probably not the best way for a remote transfer. Maybe the rsync
developers will think about the OS X peculiarities in the future and
possibly find a solution :-)
Anyway, as a last consideration before the ultimate test of restoring to
my working volume from the updated clone, I'm reviewing my choice of not
using the -H option. On initial readings of the rsync man pages I
included the -H option, but on subsequent readings I took it out. Any
thoughts?
Thanks for your help,
Lee C
--
To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
