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(a)reactos.com
http://reactos.com:8080/mailman/listinfo/ros-dev