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?
Kevin
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...
>
> Dominic
>
> On 17/05/2013 20:09, KP wrote:
>> Dominic,
>>
>> 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?
>>
>> Kevin
>>
>>
>
> --
> TimeDicer: Free File Recovery from Whenever
_______________________________________________
rdiff-backup-users mailing list at rdiff-backup-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/rdiff-backup-users
Wiki URL: http://rdiff-backup.solutionsfirst.com.au/index.php/RdiffBackupWiki
