如何在文件过滤驱动中实现压缩？

  如题

好像很少有人做过这个的。关注！

关注ing~~~~~~~~~

学习中。。。。。。。。。

我认为可以,但是没有做过.

方法1: 得到BUFFER,直接压缩.
方法2: 当文件写磁盘结束后,在完成例程中,用ZWCREATEFILE ZWREADFILE ZWWRITEFILE等,重新写这个文件

GOOD LUCK

是不是应该创建一个新文件，压缩后把老文件删除掉

ifs专门有一个压缩层的group

应该可以压缩,因为win2k支持压缩功能

压缩是一定可以压的,但是看你想压成什么.
如果你想压成RAR ZIP等标准格式,只能再建立一个文件了.然后操作完以后改名改回来.

如果只是随便压缩,那就和加密一样.得到BUFFER操作字符串就行了.

It's not that easy. Some problems I can see are:

Read/Write buffer offset and length should be changed in MJ_READ/MJ_WRITE
File size, EOF, Allocation Size are changed on the fly
Some algorithms require either header or trailer appended
Some algorithms may require re-compressing whole file even there's only one-byte change.

But of couse it's doable.

不是所有的需求用驱动作都是很好的解决方案。

类似加密一样，很多的需求用驱动来做并不是什么好的注意，利用驱动来实现在功能和实用性方面都很难获得满意的效果。

我觉得用驱动来做，主要优点是可以完全透明地处理。另外有时候也
不得不使用驱动，有时候则不一定。

我也认为在驱动中做会有一些好处。但现在遇到一个问题，就是解压的时候buffer的长度变化问题。当一个buffer是一个满页传进来的时候，解压后肯定长度发生变化。但多出来的那一块buffer怎么处理？我认为肯定要在下一个buffer来之前将他传上去，但没有好的思路。请各位大佬不吝赐教！

一定要创建临时文件，微软就是这么做的。不信你去调试一下。

下面是引用idaxsy于2005-07-29 10:41发表的:
一定要创建临时文件，微软就是这么做的。不信你去调试一下。

微软创建临时文件,主要用于备份恢复之用，是怕压缩过程中出意外（比如断电）导致原文件损坏，是否跟压缩有关，还不甚清楚

主要是微软的临时文件打不开，搞不清里头是些什么东西。
我想办法禁止了微软删除临时文件，可是打不开这个文件，在ring0和ring3都试验了一下。

不过我在write例程里看到向临时文件写入的确是明文。
看来这个文件的确如bmyyyud所说，是备份恢复用的。

而且没有发现有改名的动作，可以证明确实如此。

我这里只考虑压缩写：
我只处理cache写，因为直接写硬盘时，是以簇为单位的，已经没有了文件指针的概念。
在写例程中，我不改变IrpSp-> Parameters. ByteOffset,也不改变FileObject-> CurrentByteOffset,
也不改变IrpSp-> Parameters. Write. Length,在写例程中我将数据压缩到一个临时Buf中，并获得了压缩后的长度len，仅仅在拷贝数据的时候，我只返回len个字节的Buf给用户区。为了使下一个IRP包的写指针偏移落在压缩数据的末尾，我们必须记住len值，并传到完成例程中做进一步处理。

在写完成例程中，Irp->IoStatus.Information维护了写成功的长度，也就是说Irp-> IoStatus.Information=="写例程中IrpSp-> Parameters. Write. Length的值",在写完成例程中，文件系统已经将Irp-> IoStatus.Information累加到了FileObject->  CurrentByteOffset上了，下一个写IRP包的写偏移就是依赖于这个累加后的值。所以为了使下一个写IRP指针的偏移能紧挨着上次压缩的数据尾部，我这样来做：
        IrpSp-> FileObject-> CurrentByteOffset. QuadPart -= Irp->IoStatus. Information;
        IrpSp-> FileObject-> CurrentByteOffset. QuadPart += len;

事实证明效果不是很好。

如果用压缩算法问题还比较艰巨，哎～

我只处理cache写

So you have compressed data in cache. I don't think this is good for MM file nor performance.