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.
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.
I'll now prepare a wikipage which handles an injective (but bijective wanted) translation of acls.
Michael B. Trausch wrote:
Rick Langschultz wrote:
Personally this would be my choice.
Tell me what you all think.
I think that it would make sense to implement whatever filesystems we can -- leaving it to the user to be able to use what they like/trust/want to tinker with.
Here's a question, again, from an uneducated vantage point: Would it be possible and not terribly complicated to incorporate "virtual" IFS drivers that would allow for compression and encryption to be shared among all filesystems, so that they happen in the kernel, and the kernel can support it on filesystems that natively support it as well as those that don't by means of an index file per drive or directory to store the "extended" attributes of a file (compressed, encrypted, whatever)? This would then in theory allow filesystems such as FAT to have transparently compressed and/or encrypted files, even though I would not recommend FAT to and end user to be used in the first place, but that's just my own personal opinion.
- Mike
Ros-dev mailing list Ros-dev@reactos.com http://reactos.com:8080/mailman/listinfo/ros-dev