opendir(my $dh, "/home/anonymous_monk") or die("ack - $!");
my @list = ();
while(my $fl = readdir($dh)) {
    push @list, [ (stat($fl))[1,8] ];
}
print "inode: $_->[0]\n" for sort { $a->[1] <=> $b->[1] } @list;
[download]

_________
broquaint

I had thought about using the stat function, but while it does get the information, it doesn't do it the way I'd like. Let me explain further.

Execution speed is critical to the application I'm writing. Any process that relies upon navigating the file system's directory tree will probably be too slow. That rules out things involving ls, find, or perl's stat. My understanding is that the inode table is a block of binary data sitting on the disk just after the superblock. If I read and parse through it, I can get the information I need without the overhead of navigating the file structure.

I had also looked into using C instead of Perl. Every C snippet I found seemed to use a different set of header files. In no case did I have all of them present upon my system. I'd prefer to only write the thing once rather than have to port it for different Unix flavors.

That at least is the theory. It's been put together from an awful lot of odds and ends and there may be some erroneous assumptions in there. If you spot one, please let me know.

I am root on the box(es) that this will be running on.

Cerian

If execution speed is **really** critical then you'll have to go to C (or something else low-level and fast) as the mere overhead of running perl will be enough to slow you down from the sounds of it. Also, if you really want to grok the inode table you'll have to rule out perl as it doesn't have the functionality to do *really* low-level file-system stuff (unless you use XS or Inline::C).

I'm not a file-system ninja but I'd say the best place to look for inode info without actually reading straight off the 'metal' is to use the stat() function in C which should be in your standard library (and if you don't, you've got quite an unusual C install and a magical version of perl) and subsequently is very portable so worry not (too much ;-) about migrating it to other *nixes.
HTH

_________
broquaint

Execution speed is critical to the application I'm writing. Any process that relies upon navigating the file system's directory tree will probably be too slow.

It might be, but you won't know until you test it. I suggest you try the easy way - code up a solution that uses readdir() and stat(). If that isn't fast enough then start working on the hard way.

I had also looked into using C instead of Perl. Every C snippet I found seemed to use a different set of header files. In no case did I have all of them present upon my system. I'd prefer to only write the thing once rather than have to port it for different Unix flavors.

I think you'll have to pick your poison: slow and portable or fast and non-portable. As far as I know there's no Unix standard for the binary structure of an inode. If you want to get the best possible speed you'll need to drop to C and access the inode directly. If you do that you can't expect it to work without changes on different OSes.

-sam