Hi All, I have been getting reports from users of backuplist+, my wrapper application for rsync (currently with build of 3.0.6), about odd behavior after updating to OS 10.6 Snow Leopard. Basically: the problem occurs backing up a directory to a local mounted network volume. Previously all worked fine but after updating to 10.6 there are reports that no files get copied and the destination fills up with thousands (yes thousands) of .DS-Store files which on OSX are invisible and carry metadata about the directory that contains them (usually just one per directory...) The destination files are visible and labeled ..DS_Store.0aecRT ..DS_Store.0afcRT ..DS_Store.0cecRT ..DS_Store.0cfcRT (Note the "two dots" prefix?) on an on and on. One user reported 97,000 of these with seemingly random names attached. rsync log shows>> file has vanished: "/Volumes/MacMini/Users/rg/..DS_Store.ZxgavW" >> file has vanished: "/Volumes/MacMini/Users/rg/..DS_Store.ZygavW" >> file has vanished: "/Volumes/MacMini/Users/rg/..DS_Store.ZzgavW"So before any files are copied it fails on the "missing" files that aren't there in the first place! The basic command line is pathtoRsync -aHAXN --fileflags --force-change --stats -v -u --progress pathttoSourceDirectory pathToDestinationNetworkDirectory &> pathToOutputLogFile echo $! This works fine when going to an external mounted Volume or a partition, just not to a local mounted Network Volume. I haven't been able to get any more detailed information from users so far. Has anyone seen this or have a clue to what's happening? Something to do with the Network and DS_Store files it seems. I'm not sure where to even begin. Thanks, Rob DuToit
With rsync 3.0.7 I have exactly the same problem. I am using rSync to sync my Userdirectory to another Mac in a home network. I am not 100% sure, but the problem occurred after the latest update of the MacOS (Mac OS X 10.6.3 (10D573)) of the Source. My macmini (the Dest of rSync) is also running (Mac OS X 10.6.3 (10D573)). I tried several options but till now without any results. Eric
Hi Eric et al, It seems this is not an rsync problem though I am not sure.... The same thing happens with the Apple supplied rsync as with 3.0.7 (someone emailed me about the same problem using the old apple supplied rsync) and I wonder if other file transfer options might have similar results. I am still mystified about the cause of this except that it started with the latest OS update. Perhaps having to do with security "enhancements?" This is a big problem as administrators have been using rysnc to sync their network machines and everything is failing suddenly. Any one else have a clue? Rob On Apr 4, 2010, at 3:34 PM, Eric Jan Pot wrote:> With rsync 3.0.7 I have exactly the same problem. > > I am using rSync to sync my Userdirectory to another Mac in a home network. > I am not 100% sure, but the problem occurred after the latest update of the MacOS (Mac OS X 10.6.3 (10D573)) of the Source. > > My macmini (the Dest of rSync) is also running (Mac OS X 10.6.3 (10D573)). > > I tried several options but till now without any results. > > Eric > > > > > -- > Please use reply-all for most replies to avoid omitting the mailing list. > To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync > Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
On Sat, 2010-04-03 at 18:12 -0400, Robert DuToit wrote:> I have been getting reports from users of backuplist+, my wrapper > application for rsync (currently with build of 3.0.6), about odd > behavior after updating to OS 10.6 Snow Leopard. > > Basically: the problem occurs backing up a directory to a local > mounted network volume. Previously all worked fine but after updating > to 10.6 there are reports that no files get copied and the destination > fills up with thousands (yes thousands) of .DS-Store files which on > OSX are invisible and carry metadata about the directory that contains > them (usually just one per directory...)In order to investigate this phenomenon from the rsync side, we'll need strace output (or whatever the Mac equivalent is). -- Matt
Matt, I forgot to mention, If I add an exclude for .DS_Store* it doesn't generate the odd .DS_Store files. However, if I copy directories with other types of hidden files like .bash_history then it generates odd versions of those too. So I added an exclude for every hidden (dot prefix) file .* and it seems to work ok. This might be ok as an emergency measure of course but not desirable since a lot of hidden files are needed and at root level indispensable. Rob
Robert DuToit wrote: > On Apr 6, 2010, at 9:14 AM, Benjamin R. Haskell wrote: > >> On Mon, 5 Apr 2010, Robert DuToit wrote: >> >>> Hi Matt, >>> >>> I set up a simple test with a nest of directories ( aa > bb > cc >>> > dd &ee) with 1 file in each. running rsync from OS 10.6 to >>> another Mac with OS10.5 there seems to be no problem. When doing >>> the reverse I am seeing the odd behavior. >>> >>> Below is the log from running the options >>> >>> -aHAXN --fileflags --force-change -stats -vvv Please specify _exactly_ how you're building rsync. Those options don't exist without applying some extra patches. I can't replicate the problem with stock rsync, which means it's either a problem with the patches, or I'm not triggering the bug properly. Can you replicate this without a 10.5 box? Can you replicate it with Apple's rsync? Unpatched 3.0.7 rsync? Patched 3.0.7 rsync? Nightly snapshot? I really don't want to spend time investigating an old release, and I need to be able to reproduce the problem before I can help fix it. I have 10.6 and OpenSolaris easily at hand to test with, but no 10.5 boxes. > I checked out dtrace (OSX version of strace) but it seems a bit > complicated and I don't know how to use it yet. If anyone has maybe > they can let me know. sudo dtruss -f /path/to/rsync --whatever src dest 2>/tmp/mydtrusslog should dump all the syscalls into /tmp/mydtrusslog -- Carson
> Basically: the problem occurs backing up a directory to a local mounted network volume.If you are using the -a flag then you may have problems preserving the permissions of files on the mounted network directory. This will greatly depend upon you or your users setup. Unfortunately, I do not believe this is the problem you are seeing. ---------------------------------- This email is protected by LBackup http://www.lbackup.org