Re: Reverse engineering a file handle

This really depends on the operating system, for instance on Linux stat the /proc/self/fd/0 and then search the file system for a file that has the same device and inode numbers, this is really the reverse of how Linux::Fuser does it. However on other operating systems, I really don't have a clue.

/J\

Comment on Re: Reverse engineering a file handle Select or Download Code

Replies are listed 'Best First'.
Re^2: Reverse engineering a file handle by ikegami (Patriarch) on Jun 09, 2005 at 19:07 UTC
The caveats with the above answer: When the above method works, it's not guaranteed to return the right name. More than one file name can have the same inode (rare), or a symbolic link might have been be used on the command line (common). Wouldn't that take a long time on drive with many files? (common) And there are times when the above approach (and all others) would fail: When STDIN and/or STDOUT isn't a file. STDIN and/or STDOUT could be associated with a pipe, a device, etc. Can you possibly rewrite the script and caller to pass the file names as arguments? You could make the name arguments optional and use STDIN and STDOUT when no names are provided.	[reply]

Replies are listed 'Best First'.

Re^2: Reverse engineering a file handle
by ikegami (Patriarch) on Jun 09, 2005 at 19:07 UTC

The caveats with the above answer:

When the above method works, it's not guaranteed to return the right name. More than one file name can have the same inode (rare), or a symbolic link might have been be used on the command line (common).

Wouldn't that take a long time on drive with many files? (common)

And there are times when the above approach (and all others) would fail: When STDIN and/or STDOUT isn't a file. STDIN and/or STDOUT could be associated with a pipe, a device, etc.

Can you possibly rewrite the script and caller to pass the file names as arguments? You could make the name arguments optional and use STDIN and STDOUT when no names are provided.

[reply]