Can Inode and Crtime Be Used as a Unique File Identifier

When rm a file but hard link still there, the inode will be marked unused ?

i-nodes contain a link count (visible in ls -l output). Each hard link increments that count. Unlinking (removing a link, be it the original filename->inode link, or some hard link added later, which is the only thing users can request) decrements the count. The file won't be deleted until the count reaches 0 and there are no open file descriptors left pointing at that file (which is similarly tracked by an in-kernel reference count).

Is there any function to retrieve the path associated with an inode?

inode numbers are only unique within a filesystem, so you need at least device and inode number to identify a file.

On the HFS+ file system, the inode number is in fact identical to the "Macintosh File Id", and there is a special "/.vol" filesystem that allows you to find a directory by device and inode.

Example:

$ cd /.vol/234881029/342711
$ pwd
/Volumes/Data/tmpwork/test20/test20.xcodeproj
$ stat .
234881029 342711 drwxr-xr-x 5 martin staff 0 170 ......

As you can see, 234881029 is the device number of "/Volumes/Data", 342711 is the inode number of "tmpwork/test20/test20.xcodeproj" within that filesystem, and

cd /.vol/<deviceNo>/<inodeNo>

transferred you directly to that folder. You could now use getcwd() to determine the real path to that folder.

The "/.vol" filesystem is documented in the legacy Technical Q&A QA1113.

Disclaimer: I tried this only on OS X 10.7 and I am fairly sure that it works on older systems. I have no idea if you can rely on this feature in future versions of OS X. Also it is very HFS specific.

inode - move a file which is already opened

Using rename() on a file within the same file system just changes the name that points to the inode. You can even use rename() to move that name into another directory - as long as it's in the same file system:

The rename() function shall change the name of a file. The old
argument points to the pathname of the file to be renamed. The new
argument points to the new pathname of the file. ...

Note that the POSIX specification for rename() is a lot more specific than the C Standard rename() specification:

7.21.4.2 The rename function

Synopsis

#include <stdio.h>
int rename(const char *old, const char *new);

Description

The rename function causes the file whose name is the string pointed
to by old to be henceforth known by the name given by the string
pointed to by new . The file named old is no longer accessible by
that name. If a file named by the string pointed to by new exists
prior to the call to the rename function, the behavior is
implementation-defined.

Returns

The
rename
function returns zero if the operation succeeds, nonzero if it fails,
269)
in
which case if the file existed previously it is still known by its original name.

(That's the entire C Standard specification for rename(). Read the POSIX link for a lot more information.)

So how can you rename a file while your watching it in an application? The underlying inode that your movie-watching process's open file descriptor uses to access the file that you just rename()'d doesn't change.

That's the same reason why you can unlink() (delete) a file while it's in use - all you're doing is removing the entry that points to the inode - one of the links to the inode. The space used by the file isn't freed until the last link to the inode is removed - and an open file descriptor counts as a link. That's also why the function that deletes the directory entry for a file is called unlink() - that's all it does. And yes, a file (inode) can have more than one link pointing to it.

Are inode limits by directory or by drive?

Inodes are the *nix representation of disk files. They are identified by a number, not by the path where they are in the directory structure. So the limit is across the whole file system, regardless of which hard link(s) (file entry you see in a directory) point(s) to the inode.

---

Related Topics