[ale] interesting problem

[Jim Kinney]

It's actually looking like a far simpler problem than originally surmised.

Originally I thought the bad symlinks were due to a relative path being outside of the rsync scope of operation. It's looking more like the original source just has tens of thousands of dangling symlinks that were created by mistakes (mostly students) and resolved/cleaned before the backup occured.

Find is working. So is the symlinks command.

On January 12, 2018 12:21:49 AM EST, Steve Litt <slitt at troubleshooters.com> wrote:
>On Thu, 11 Jan 2018 15:04:33 -0500
>Jim Kinney via Ale <ale at ale.org> wrote:
>
>> Imagine a giant collection of files, several TB, of unknown directory
>> names and unknown directory depths at any point. From the top of that
>> tree, you need to cd into EVERY directory, find the symlinks in each
>> directory and remake them in a parallel tree on the same system but
>in
>> a different starting point. Rsync is not happy with the relative
>links
>> so that fails as each link looks to be relative to the location of
>the
>> process running rsync.
>
>I can't exactly visualize what you want to do with the discovered
>symlinks, but my first thought would be to write a treewalker program.
>It's pretty easy to write a C tree-walker program that performs a
>specific action upon encountering a symlink. Because your wrote it in
>C, it will be as fast as its algorithm. Depth-first tree walker
>algorithms are pretty darn fast.
>
>HTH,
>
>SteveT
>
>Steve Litt
>January 2018 featured book: Troubleshooting: Why Bother?
>http://www.troubleshooters.com/twb

-- 
Sent from my Android device with K-9 Mail. All tyopes are thumb related and reflect authenticity.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ale.org/pipermail/ale/attachments/20180112/10908e74/attachment.html>