in reply to Re^3: How to detect if file is in use?
in thread How to detect if file is in use?

I don't think gellyfish said anything about inodes.
If you look into /proc/*/fd/, you will find symlinks to all the files opened by the programs. By using readlink(), you can find out the path of those files (not the inodes).

Replies are listed 'Best First'.
Re^5: How to detect if file is in use?
by thor (Priest) on Mar 17, 2005 at 16:18 UTC
    Different paths do not imply different files. You can have a million symlinks that point to the same underlying file.

    thor

    Feel the white light, the light within
    Be your own disciple, fan the sparks of will
    For all of us waiting, your kingdom will come

      There is also the possibility that the file was opened by a link that was subsequently removed.

      /J\

      It appears that the links in /proc/*/fd are canonified, i.e. if you open a symlink to foo, then /proc/$$/fd/xx will also point to foo:
      $ perl -le 'symlink("foo","bar") o r die $!; open F, ">bar" or die $!; print readlink("/proc/$$/fd/".file +no(F))' /tmp/foo
      Therefore, you can be sure that the paths in the proc filesystem aren't symlinks. Hard links are a harder problem. fuser seems to always get it right, though.

        I thought this was interesting ... so I expanded it just a wee bit:

        $ (cd /tmp; perl -e 'symlink("foo","bar") or die $!; open F, ">bar" or + die $!; rename "foo", "blah" or die $!; print readlink("/proc/$$/fd/ +".fileno(F)),$/'; rm blah bar) /tmp/blah
        As should be expected(?), it follows renames. And, quite interestingly ...
        $ (cd /tmp; perl -e 'symlink("foo","bar") or die $!; open F, ">bar" or + die $!; unlink "foo" or die $!; print readlink("/proc/$$/fd/".fileno +(F)),$/'; rm bar) /tmp/foo (deleted)
        Wow. That's cool. Imagine the abuse one could wreak on a poor programmer by creating a file "/tmp/foo \(deleted\)" :-) I suppose that testing for the file being deleted means actually testing the symlink via stat (e.g., -e).

        Yes because as mentioned before fuser compares the inode and device number of the file in question with those of the files in /proc/*/fd and ignores the fact that they are links.

        /J\