in reply to Finding Hard links

I don't know it there's a module available to do that. But I suppose that as a general rule it won't be an easy thing since, AFAIK while filesystem and related system calls return relevant information in the direction filename => inode, they do not do the opposite. So you can gather them from comparing files. Of course this is made easier by the fact that

Update: ok, here I try my hand at this with a minimal example/proof of concept:

#!/usr/bin/perl -ln use strict; use warnings; BEGIN { @ARGV='find . -xdev|' } our %files; my ($ino, $nlink)=(stat)[1,3]; next unless $nlink and $nlink > 1; if ($nlink == push @{ $files{$ino} }, $_) { print "$_ => $ino" for @{ $files{$ino} }; delete $files{$ino}; } __END__

Replies are listed 'Best First'.
Re^2: Finding Hard links
by powerman (Friar) on Nov 09, 2005 at 03:54 UTC
    Original question was about perl module... but if you start using `find` command, then:
    my $original_file = '/path/to/file'; my $dir = '/where/to/find/hardlinks/'; chomp for @hard_links = `find \Q$dir\E -inum \$(find \Q$original_file\E -printf "%i")`;

      Oh, well of course! I used an external find command because as I stressed, I just wanted to keep minimal and using File::Find, as I would most probably do in a more realistic case1, was not substantial for the technique I wanted to explore...

      You'll also notice that I used -ln on a slightly longer script than I would usually do in "production", whatever that is.

      But in the above you're fundamentally using Perl as a shell script. That is really "kinda too much". Incidentally you're using the "inner" find just to print the inode number. In that case the external stat command would suffice:

      $ stat -c %i work/ 18972756

      OTOH I didn't know about -inum, so I thank you - I know it's out there in the docs, but I tend to learn by example...

      Also, as a final observation, I think that indeed the OP was really asking about how to find hard links sharing the same inode as a given file, that is what you actually do. But if you want to search a whole directory hierarchy like I did, a "pure-find" approach along the lines of your example would be unpractical, since I think it would necessarily take two nested find's.



      1 And if I called an external find cmd, I'd probably use an explicit open.