[OpenAFS] hard link behavior

[Jaap Winius]

Hi all,

Regarding the way OpenAFS handles hard links, my understanding is =20
that, to prevent ACL conflicts, this is allowed to work between files =20
as long as they are in the same directory. This results in two types =20
of responses:

1.) If a hard linked file is moved to another directory in
     the same volume, the data is instead copied and the
     files are no longer linked.

Note that when they do exist, these hard links are retained even if =20
the volume is moved to a different vice partition. Subsequently, the =20
size of the volume remains the same.

2.) If an attempt is made to create a hard link to a file
     in a different directory, an error occurs:

        ln: creating hard link `README' =3D> `../README': \
        Invalid cross-device link

In the second case I half expected the file to be copied instead, but =20
I suppose that would not be as logical (as honest) as giving an error.

Question: Is there a way to alter the way OpenAFS works with hard =20
links on an individual volume?

For example, if it were possible to change the properties of a volume =20
so that only the ACL of the volume's root directory would apply to all =20
of its subdirectories, then in such cases there would never be any ACL =20
conflicts and the usual limitation that prevents hard links from being =20
created across directories could be suspended.

If this were possible, such volumes would be great for making =20
disk-based backups on. These solutions typically make heavy use of =20
hard links to save space, but the problem is that they are stuck on =20
the partitions on which they are created. But if they could be created =20
on an AFS volume, they could be moved to other partitions or servers =20
with ease. In addition, their contents could also be made available =20
via the AFS namespace. Sure, you'd still lose the AFS ACL information =20
when making these backups, but I wouldn't care much about that: even =20
without retaining the ACL information, this would still be a great way =20
to take advantage of AFS when making disk-based backups.

Cheers,

Jaap