15 May
2005
15 May
'05
8:56 p.m.
Rick Langschultz wrote:
There has been much talk about a file system that would
be compatible with
Microsofts implementation of NTFS. There has also been discussion about
using something like the ext variants of filesystems, so here are my
thoughts:
Option 1 - Write an EXT3 - NTFS VFAT translation driver to allow ext3 to be
the underlying filesystem.
I believe Mac OS X uses something like this with the way it can translate
Mac OS X:Applications:Utilities into /Applications/Utilities.
Keep in mind there is *not* a unique view of system name space: that's
how environment subsystems work in NT and in ROS. The client library for
the subsystem S will give a process running in the environment S it own
view (the "correct one" the process expects) of the system name space.
For instance, the Win subsystems makes ("kernel32.dll makes") its
processes belive logical volumes have letters attached to them.
A possible macosx.dll would simply translate "Mac OS
X:Applications:Utilities" into "\Devices\HarddiskVolume1\Mac OS
X\Applications\Utilitites".
Option 2 - Build your own proprietary filesystem
incorporating things that
people would like in the filesystem.
That's what every file system driver usually does: otherwise only one
would exist.
Option 4 - Build a filesystem that encrypts itself
throught the kernel or a
program on the system with a public and a private key, kind of like SSL.
?
Option 5 - Keep the same file system intact, write a
driver that allows
users to encrypt a "folder" which is actually a file on the drive, when a
user double clicks on a file the folder is either mounted based on a
ticketing system or credentials, or, asked for a master password or a
password that will give certain but not all priveleges.
That's a filter driver. It's a regular NT IFS technique.
Personally this would be my choice.