On Wed, Feb 19, 2020 at 11:58 AM David Howells <dhowells@xxxxxxxxxx> wrote:
>
> Actually, in many ways, they're more akin to symlinks (and are implemented as
> symlinks with funny attributes). It's a shame that symlinkat() doesn't have
> an at_flags parameter.
Interesting. Then you'd get the metadata as the symlink data. Is the
size of the available buffer (PATH_MAX) sufficient?
In fact, would PATH_MAX-2 be sufficient?
Because POSIX actually says that a double slash at the beginning of a
filename is special:
"A pathname consisting of a single slash shall resolve to the root
directory of the process. A null pathname shall not be successfully
resolved. A pathname that begins with two successive slashes may be
interpreted in an implementation-defined manner, although more than
two leading slashes shall be treated as a single slash"
so you _could_ actually just make the rule be something simple like
symlink(target, "//datagoeshere")
being the "create magic autolink directory using "datagoeshere".
The advantage of that interface is that now you can do things from
simple perl/shell scripts etc, instead of using any magic at all.
> mknod() isn't otherwise supported on AFS as there aren't any UNIX special
> files.
Well, arguably that's a feature. You _could_ decide that a S_IFCHR
mknod (with a special number pattern too, just as a special check)
becomes that special node that you can then write the data to to
create it.
So then you could again script things with
mknod dirname c X Y
echo "datagoeshere" > dirname
if that's what it takes.
But the symlink thing strikes me as not unreasonable. It's POSIXy,
even if Linux hasn't really traditionally treated two slashes
specially (we've discussed it, and there may be _tools_ that already
do, though)
Linus
