Welcome to the MacNN Forums.

If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below.

You are here: MacNN Forums > Software - Troubleshooting and Discussion > Mac OS X > Convert hard links to symlinks/aliases

Convert hard links to symlinks/aliases
Thread Tools
Fresh-Faced Recruit
Join Date: May 2003
Status: Offline
Reply With Quote
Feb 28, 2013, 12:08 AM
 
Picking up where this thread left off,
http://forums.macnn.com/90/mac-os-x/...s-to-symlinks/
Originally Posted by kent m
Hello,
Is there a script available to convert aliases to symlinks?
...
Thanks very much,
Kent
I used a duplicate checker & removal program (DeCloner) to free up dozens of GB of duplicate files, having it replace them with hard links (its only option). However, hard links are not satisfactory for relinking files in Adobe CS (InDesign, Illustrator) documents. Symlinks work as expected. So now i have hundreds of hard links that i need to convert to soft links or aliases. The utility from this previous thread works great for going from aliases to symlinks (or vice versa), but now i find myself in need of v 2.0 -- support for hard link conversion as well!

I hereby invoke CharlesS!
Are you up for the challenge?
     
Clinically Insane
Join Date: Mar 2001
Location: yes
Status: Offline
Reply With Quote
Feb 28, 2013, 01:51 AM
 
Maybe something like this?

for i in *; do find . -samefile "$i";done

This will find the symlinks in the current path (this does not work recursively). You can add an -exec to the find command to eventually include the hard to symlink conversion, but does this work in your circumstances to find the hard links?
     
Posting Junkie
Join Date: Dec 2000
Status: Offline
Reply With Quote
Feb 28, 2013, 04:42 AM
 
It can't be done. Not practically, anyway.

Hard links are fundamentally different from aliases and symlinks. Symlinks and aliases point to another catalog entry — i.e. an object which shows up as a file or a folder in the Finder, which has a path in the file system. Hard links, on the other hand, just point to a chunk of data somewhere on the disk. Every file on your hard drive is, effectively, a hard link; it's just that most files are the only hard link to their particular chunk of data, so there's usually a one-to-one correspondence. When you have two hard links to the same chunk of data, though, the two hard links are total peers in every way, so neither one points to the other — they just point to the same data on the disk — so it's not possible to discover what file a hard link "points" to and replace it with a symlink, since it doesn't really point to anything that could be symlinked to.

Besson's idea could, in theory work, but if you've done this globally to your entire disk, what you'd have to do would be to scan the entire disk for any files with a link count of more than one, then run find / -samefile for each one of them. This would get you a list of hard links that all point to the same inode, but:

1. It would be incredibly slow, as you'd have to do a complete search of the hard disk all over again for every single hard link on the drive with a link count of 2 or more, which, considering the number of hard links that are likely on your drive, would take a very, very long time. It would, of course, be worlds faster if you used searchfs instead of find, since you'd be doing a catalog search instead of a directory tree traversal, but even then it's likely going to take a really long time.

2. Even when you do get a list of hard links to the same inode, it's impossible to tell which of those is supposed to be the "original", since hard links don't have any concept of the "original." They're all equal peers as far as the file system is concerned.

3. There are plenty of files that are part of the OS that are supposed to be hard links. Even if you could get past problems #1 and #2, you wouldn't be able to convert hard links to symlinks as a blanket rule, because you'd mess up a bunch of system files.

If you ask me, your best bet is to restore your Time Machine backup from before you ran DeCloner, and then never run these stupid "space-saving" apps again.

Ticking sound coming from a .pkg package? Don't let the .bom go off! Inspect it first with Pacifist. Macworld - five mice!
     
P
Moderator
Join Date: Apr 2000
Location: Gothenburg, Sweden
Status: Offline
Reply With Quote
Feb 28, 2013, 08:52 AM
 
What is not satisfactory about the hard links? I seem to remember that PS does something fancy when writing to files (writing a copy, then deleting the original and renaming the copy) - I suppose that that wouldn't work very well with hard links, if the other Adobe apps do the same thing.

Charles: Your statement is correct for file systems in general, but HFS+ employs a massive hack to implement hard links - the HFS+ Private Data directory. It seems one should be able to circumvent the problem by simply trawling that directory for hard linked files. Mostly a theoretical discussion as your objection #3 is still perfectly valid, but it's an interesting problem.
The new Mac Pro has up to 30 MB of cache inside the processor itself. That's more than the HD in my first Mac. Somehow I'm still running out of space.
     
Posting Junkie
Join Date: Dec 2000
Status: Offline
Reply With Quote
Feb 28, 2013, 01:50 PM
 
P: Not really, since the hack works, IIRC, by using the HFS+ Private Data directory to represent the inodes. Hard links are implemented as aliases to those inodes, but there's no way that I know of to quickly list all aliases to a file. So again you'd be having to do a full search of the hard drive for each one of those inodes, finding every alias on the drive, following it, and seeing if it leads to your inode. In effect, it would be no different from find / -samefile. It would also be extremely icky and hack-ish.

Although, thinking about the problem overnight, one could maybe get this done in a less crazy amount of time by scanning the drive for multi-linked files, and for each one of them, storing the path in an array in a hash table using the inode as a key. Assuming you didn't have so many hard-linked files that this structure would eat up an inordinate amount of memory, this could work.

Ticking sound coming from a .pkg package? Don't let the .bom go off! Inspect it first with Pacifist. Macworld - five mice!
     
Posting Junkie
Join Date: Dec 2000
Status: Offline
Reply With Quote
Mar 1, 2013, 05:10 AM
 
I've made a quick-and-dirty Perl script which will scan your hard drive, and make you a list of hard links which are linked to the same inode. However, because of points #2 and #3 in my post above, you'll need to do any fixing by hand.

To use this script, paste this code into a plain text (not RTF) file in a text editor of your choice (TextEdit works well for this), give it a .pl extension, chmod it to 755, and run it in the Terminal.

Code:
#!/usr/bin/perl use strict; use warnings; use File::Find; no warnings 'File::Find'; our %link_hash = (); File::Find::find({ wanted => \&callback, preprocess => \&preprocess }, '/'); foreach my $each_ino (sort keys(%link_hash)) { print "Files with inode $each_ino:\n"; foreach my $each_file (sort @{$link_hash{$each_ino}}) { print "$each_file\n"; } print "\n"; } sub callback { if (-f $_) { my ($dev, $ino, $mode, $nlink) = lstat($_); if ($nlink > 1) { push(@{$link_hash{$ino}}, $File::Find::name); } } } sub preprocess { if ($_ eq 'Volumes') { return (); } return @_; }

Ticking sound coming from a .pkg package? Don't let the .bom go off! Inspect it first with Pacifist. Macworld - five mice!
     
   
Thread Tools
Forum Links
Forum Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts
BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are On
Top
Privacy Policy
All times are GMT -4. The time now is 08:02 PM.
All contents of these forums © 1995-2014 MacNN. All rights reserved.
Branding + Design: www.gesamtbild.com
vBulletin v.3.8.8 © 2000-2014, Jelsoft Enterprises Ltd., Content Relevant URLs by vBSEO 3.3.2