Re: [RFC][6/11][MANUX] Kernel compatibility : directory hardlinks

[Emmanuel Colbus <ecolbus@manux.info>]

Le 16/04/2014 00:01, Theodore Ts'o a écrit :
> On Tue, Apr 15, 2014 at 10:53:24PM +0200, Emmanuel Colbus wrote:

> 
>> The value means that the file is not a true directory, but a directory
>> hardlink. Directory hardlinks, which only appear in my ro-compatible
>> ext2l partitions, are special files that have no content, and simply
>> point to a directory inode by using its inode number. 
> 
> I'm not sure what's the value of having a directory hard link given
> the existence of symlinks.  I undersatnd what the difference is, but
> what value does it give to an end user?  It's confusing, and if there
> is a directory hard link to a directory, you won't be able to delete
> the directory, lest you leave a dangling reference (and you can't just
> remove the primary link to the directory, since then the ".." entry in
> the directory will be pointing to the old parent directory).  That
> makes hard links of files fundamentally different from a directory
> hard link, which will be even more confusing to users.

As for the end users, they aren't supposed to create any : this is a
privileged operation. However, for the operating system, this is very
useful.

Consider for example a program that stores some data within its /tmp. In
my OS, every process is chrooted, so he needs to have its own /tmp. But
then, this raises several issues :
1) Some applications use /tmp as a means of communication between each
other. POSIX explicitely allows this. So how is this supposed to work if
two applications, in two different chroots, try to communicate in this way?
2) How is this /tmp directory supposed to be cleaned when the system
shuts down?

The solution is to use directory hardlinks. This way :
 - applications that want to communicate through /tmp can simply specify
that they have a dependancy on a package that provides a /tmp directory
for them; this way, the package manager will create a directory hardlink
named "/tmp" towards it in their chroot, and they will be able to do
their thing;
- as for the cleaning of /tmp, it is done by having all the /tmp
directories of all the applications hardlinked within the chroot of the
script tasked with cleaning them.

Symlinks, of course, wouldn't work, as they would require giving at
least one application access to the other's root.

> 
> But if I were going to do such an insane thing, instead of trying to
> do it by repurposing an inode field and using an inode, I'd probably
> do it by using a bit in the file_type field of the directory entry to
> indicate that it's this special "directory hard link" thing.

Well, I'm using the underlying file as a mount point, so not having any
file seems tricky. And I'm considering using the file's *content* to
allow turning them into automatic cross-partition hardlinks. (Which
would certainly not be very *hard* -links anymore, but I think I
wouldn't be the first OS to implement not-so-hard hardlinks).

 This
> doesn't solve the semantic questions of what happens if you want to
> delete a directory that has one or more hard links to it, though.

Deleting a directory that has one or more hardlinks towards it simply
fails. (In my ext2l partitions, in the case of directories, I have used
the fragment address field as a counter of hardlinks). My directory
hardlinks are fundamentally different from other hardlinks, both in
their implementation (an additional inode type instead of an additional
directory entry) and in their behaviour (the first hardlink is different
from the other ones).

Regards,

Emmanuel