> I am working on a file system driver for linux, and have run into a
> problem with hard links. I am attempting to put per-directory quota
> support into the filesystem, rather than per-volume,
Nice! DG/UX could do that. Maybe you could track down a DG/UX admin.
> and hard links
> across quota-spaces causes some tricky semantic issues. My favored
> solutions are 1) eliminate hard links from the fs,
Coda prohibits hard links that span directories. This is because Coda
uses directory-based security data. (hmmm, Novell does this too)
I suppose hard links are supported because they are needed for some
file update methods. You'd have to do whatever coda does when a user
tries to move one of the links to another directory.
> or 2) cause link() to
> create a symbolic link instead, emulating it's predicted behavior. Does
I have a bad feeling about that... expect to lose files.
> anyone out there see any problems with the second solution that could
> arise? If it may cause problems, does anyone know of any popular
> applications that require hard links? Thanks in advance for your input!
Various mail programs, the passwd program, etc.
Hard links suck pretty hard, but you have to support them for now.
If you make them slow enough maybe app developers will stop using them.
You can do full hard link support. Create a circular linked list
through all the links of a file or store a list of directories in
the inode. You should support at least 8 links.
Here is a weird idea: have an inode bitmap to help allocate numbers,
but store inodes in directories. The bitmap lets you avoid all the
bugs that FAT suffers from. Hard links get done as a doubly linked
list, with each directory entry having the inode number, file type,
and a pointer to the next directory containing a link for the file.
In the normal case, there isn't a list to follow. Stick the inode
data on the first entry created and move it on delete, or maintain
a copy at each entry. Put version and generation numbers everywhere.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/