On Fri, Dec 04, 2015 at 10:03:41AM +0100, Jean-Pierre André wrote: > For creating a new compressed file, the procedure would be : > - create a new void file > - "truncate" it to the desired size (hence a void sparse file) > - set reparse data for the desired compression mode > - feed the data sequentially. > > Only the last step would go through the plugin, and the plugin > knows how much space has to be reserved for the pointers to > compression blocks.
Interesting idea. I hadn't considered how, if at all, the plugin should support *creating* system compressed files. I think it is actually already possible for a 3rd party application to create a system compressed file on a volume mounted by a released version of NTFS-3g --- either with FUSE driver or directly with the library. The process would be as follows: 1. create empty file and truncate it to the desired size (same as you described) 2. open the "WOFCompressedData" named data stream of the file and write the compressed data to it 3. create the reparse point The hard part is, of course, creating the compressed data stream. I think what you're suggesting is that *uncompressed* data would be written to the file and the plugin would automatically compress it, which would mean users wouldn't have to deal with that part. I think it will be possible, provided that the uncompressed size is known ahead of time and the writes are made sequentially. The plugin could detect out-of-order writes and fail them. I would still have to do my own thing in wimlib if I wanted to extract files as system-compressed, since it uses libntfs-3g directly. So this ability would be for FUSE driver users. Of course, the same will also apply to reading system compressed files. I think the audience for *reading* system compressed files is much larger than the audience for *creating* system compressed files, since you always have the option of just creating standard uncompressed files, whereas users might have no choice in reading compressed files created by Windows. Something else to keep in mind is that allowing a system-compressed file to be opened for writing would conflict with any attempt by the plugin to emulate Windows' behavior where it automatically turns the file into a standard uncompressed file when it is opened for writing (perhaps it could otherwise be done in the ->open() hook). Eric ------------------------------------------------------------------------------ Go from Idea to Many App Stores Faster with Intel(R) XDK Give your users amazing mobile app experiences with Intel(R) XDK. Use one codebase in this all-in-one HTML5 development environment. Design, debug & build mobile apps & 2D/3D high-impact games for multiple OSs. http://pubads.g.doubleclick.net/gampad/clk?id=254741911&iu=/4140 _______________________________________________ ntfs-3g-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/ntfs-3g-devel
