If I understand your problem, you wish to treat an archive file as if it
was a directory. Thus, in the ideal situation, you could do the following:
gcc hello.zip/hello.c -o hello
Rather than complicate matters with a second tree, use FUSE with an
explicit directory. For example, ~/expand could be your shadow, thus to
compile hello.c from ~/hello.zip:
gcc ~/expand/hello.zip^/hello.c -o hello
I think no kernel change would be required.
I'm not keen on the caret. One of the early claims made in
The claim is wrong. UNIX systems have traditionally allowed the
superuser to create hard links to directories. See link(2) for 2.10BSD
Having got that wrong throws doubt on the argument; perhaps a path can
simultaneously be a file and a directory.
Learn to read. Linux has never allowed that. Most of the Unix systems
do not allow that. Original _did_ allow that, but at the cost of very
easily triggered fs corruption (and it didn't have things like rename(2) -
it _did_ have userland implementation, of course, in suid-root mv(1),
but that sucker had been extremely racy and could be easily used to
screw filesystem to hell and back; adding rename(2) to the set of primitives
combined with multiple links to directories leads to very nasty issues on
I did read the claim and it is ambiguous, in that it can reasonably be
read to mean that most UNIX systems never allowed such links, which is
wrong. All UNIX systems allowed it until relatively recently.
FVO"relatively recently" exceeding a decade and half. In any case,
it's _trivial_ to get fs corruption on any system with such links -
play with rename() races a bit and you'll get it. And yes, it does
include 4.4BSD and quite a chunk of even later history.
Anyway, you are quite welcome to propose a sane locking scheme capable
of dealing with that mess.
As for the posted patch, AFAICS it's FUBAR in handling of .. in such
directories. Moreover, how are you going to keep that shadow tree
in sync with the main one if somebody starts doing renames in the
latter? Or mount --move, or...