>>> I have named it "Meta File Information". They consists in data
>>> associated with the single file that user process can set and
>>> read.
>>>
>>> Does anyone ever thinked on it or implemented in some way ? I
>>> need tips and suggestions on possible implementations.
>>
>> It is already implemented. It is called a "directory".
>
> Yup... and IMO its a good way to do it.
Nope... but you could reuse most of the directory code.
Implementation suggestion for add_fork() call: allocate a new inode,
put the existing data there, place a directory where the old inode
was, and set an attribute bit to mark the directory as a forked file.
(after the first fork is added, you don't need to repeat all that)
The forked file must never appear as a directory, unless of course
you added a fork to a directory.
> MacOS files can fork into two - but why two? Is two really that
> special in this case? And why can't these forks have forks?
>
> NT has multiple forks, but those forks can't fork, etc.
Fine, we could have forks with forks. That might be cleaner.
(though a fork is _not_ a file and directories may have forks)
What is important: unlink() and other operations are atomic
and they work as expected for files. You need an atomic move
operation, and might as well support directories too.
Any implementation should consider multi-level secure directories
(Trusted Solaris and similar systems) as well as the NT filesystem.
If you can do NTFS, the Mac and OS/2 support is easy.
BTW, don't let anyone explicitly open the default fork!
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html