Robert Köpferl wrote:
Actually 'Compression' or the C-bit is one of the file system capability flags an ifs reports to the IO-manager. So in case of NTFS this is an FS-feature But it is also possible to write Filter driver that somehow manages to compress or decompress files (i.e. last part of name is 7z ). The EFS is implemented like that. It lays over NTFS devices to add encryption.
If the compression is something that is handled by the file system driver itself, then would there be a way to make (most, if not all) of the ReactOS drivers support fs-level compression by making use of one of the better compression libraries (bz2 or lzma comes to mind). In this way, each filesystem driver would only be responsible for how to determine what files are compressed or not, and then passing the compressed files to the operating system kernel to be decompressed transparently before an application accesses it.
So, BUT: Please, all, tell me, what are you insisting so much on so unimportand features like transparent encryption and transparent compression. In my eyes the first step is to have a FS which is better than FAT and allows ACLs+EA or xattr+posix-acls (NOTE these are mostly isomorphisms). Most people can pass on enc+compr at all. Some use it but they can wait or also pass on it until it can/will be implemented or not implemented. There exist ways to come around that. Even GPL. See 7zip and TrueCrypt. For my requirements TrueCrypt beats NTFS-EFS. So why bother.
Transparent encryption and compression are two highly important things, IMHO. It's one of those things that probably would be better off being in the back of someone's mind as they're thinking about how to write the code that will handle the IFS drivers, or the IFS drivers theirselves.
Also, there are some applications that like to silently try to mark it's files both, so in a filesystem that supports it, and even Windows compresses a good bit of %SystemRoot% so that you save space on your hard disk drive.
I think that it might be smart to have ReactOS create and use a GPG key on the user's behalf, solely for the purpose of encrypting their filesystem data when the file owner selects a file to be encrypted on the filesystem. I think that would be smart, and similar to the approach that Windows XP uses in having it's EFS "key" that is encrypted by your Windows XP logon password, be that a local password or your domain password.
Since GPG is fairly strong encryption technology, with fairly speedy results, it seems to me like it is a wise choice. Also, it's generally considered trustworthy by most of those that I have discussed it with.
I'll now prepare a wikipage which handles an injective (but bijective wanted) translation of acls.
Cool. It ought to be interesting. In the end, I agree with you that I'd like to see other, non-FAT file systems supported with good features, such as ACLs and the like, but, since FAT's layout is so simplistic, it probably makes those drivers the easiest ones to create a testbed set for since the filesystem isn't terribly complicated.
Just an idea. Again, I will say up-front, that I have no clue with the code behind ReactOS or the layout of the Win32 API is or would be like in terms of possibility of the ideas mentioned... but if it can be interpreted to be that flexible and yet still be compliant, that could mean a whole new level of security that Windows doesn't (yet) have.
It seems like with some of the rumors going around about Longhorn that they may be doing something similiar, I know someone at one point fairly recently told me that they are trying to get rid of the "must be a Windows administrator to do anything" security problem. Not sure how much actual low-level FS type work would need to really be done with that, I would imagine almost none.
- Mike