[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [rdiff-backup-users] Curly braces in file names

From: KP
Subject: Re: [rdiff-backup-users] Curly braces in file names
Date: Wed, 22 May 2013 15:06:32 -0700

Hi Domonic,

It turns out that my ZFS filesystem doesn't allow renaming of symlinks *if* the target *doesn't* exist.  I've traced the problem to rpath.rename, when it's trying to rename the tmp.N symlink to the real name, and the target doesn't exist yet because it's later in the list.

Is it possible to prioritize the writing of symlinks' targets *ahead* of the symlinks themselves?

I don't know the code well enough yet where that could be handled, so I'm asking for help.  Maybe this can be resolved, but I'm also thinking of symlink targets located in a different subtree than the symlink.  Does rdiff-backup know that linkage exists without ingesting all of source directories' metadata?


On May 20, 2013, at 4:50 AM, Dominic Raferd wrote:

I'm sorry Kevin I don't take OS X (or any Apple sauce) so I'm out of suggestions...


On 17/05/2013 20:09, KP wrote:

I added --exclude-regexp '[{}]+' after checking Spotlight to see if any vital files would be affected (not at the moment, but future files named with {} may be).  That worked, for the narrow test case of /Applications/Adobe.

Then I modified the backup script with that exclude, to target the root again, and upped -v to 9.  It skipped the {} file fine, but then a new problem: it hits a symlink and terminates (on /Applications/Adobe Bridge CS6/Adobe Bridge CS6.app/Contents/Frameworks/AdobeACE.framework/AdobeACE ).

After reading other rdiff-backup-users threads on symlinks, I double-checked the timestamps of the symlink and its target file- identical, so it's not the future timestamp problem mentioned elsewhere.

Is there a cure for this symlink problem?


TimeDicer: Free File Recovery from Whenever

reply via email to

[Prev in Thread] Current Thread [Next in Thread]