Subject: symbolic links and "file flags"
To: None <current-users@NetBSD.ORG>
From: John F. Woods <firstname.lastname@example.org>
Date: 10/30/1997 21:59:48
Since it was recently decided that symbolic links should have owners and
permissions, why don't "file flags" work on symbolic links?
And while I'm on the subject, are there any plans for using the
remaining 25 file flags? Having noticed that one can perfectly easily
set the 0x10 flag and have it be completely ignored by the kernel, it
occurs to me that a sufficiently perverse site could make use of the
unused file flags for interesting local purposes (as long as there was
a reasonable guarantee that they won't *all* be system defined within
one or two releases). Perhaps setting aside 8 flags (4 super-user
only, 4 owner) would be reasonable.
(Why am I asking? Someone with a huge filesystem with lots of lookups
and substantial numbers of symbolic links noted that he could save a
lot of disk accesses if he could tell by inspecting a symbolic link
whether it pointed to a directory or a regular file. He wondered
about hacking his kernel to commandeer the 0x80 bit of the first byte
of the link pathname (i.e. sand it off so he can use readlink() instead
of fstat()); I suggested using conventional names (/../ if he's using
absolute pathnames in the links, maybe ././ if they're relative), but
it occurred to me that IF file flags worked on symbolic links, his
application could test that instead of a gross naming scheme hack.
I know, he probably wants a real database, but filesystems are easy to