如题！注意是快速地删除，正常删除的我能做到！
希望清空一个分区，用来保存一些隐私的数据和程序，当按下一组快捷键时，这个分区的数据瞬间清除！
分区的数据肯定是在使用中，所以清除时，要考虑到！我会的：
我只要把刻卷卸载了，用删除文件函数就能随便删除，但速度太慢！我不会的：
？
希望清空一个分区，用来保存一些隐私的数据和程序，当按下一组快捷键时，这个分区的数据瞬间清除！
分区的数据肯定是在使用中，所以清除时，要考虑到！我会的：
我只要把刻卷卸载了，用删除文件函数就能随便删除，但速度太慢！我不会的：
？
那就简单了。直接调用Dos命令“RD D:\*.* /s/q”，速度绝对比你写递归删除D盘要快得多。
要是再底层，可能就要自己写，涉及太多了，也不能保证安全和效率
也查了一下，并测试了一下．但它只是给出一个格式化的提示框．后来，就没有弄了，具体有多快或者和ｆｏｒｍａｔ比，哪个快，就不知道了？
曾经看过＂力克千年虫＂这部新加坡的电视剧，里面有一个ｉｔ职员，当它的笔记本被偷后，对方输入三次错误的密码，电脑中的数据全都删除了．如果在我的台式机中，按下某组键后，执行对某一个分区的快速删除，越快越好．以秒为单位，如果删除后，可以恢复，哪你就是神了，当然恢复可以不用考虑，我有备份．
2.format格式化硬盘的时候，如果该分区有文件使用，则格不掉。RD却可以，它会跳过删除不掉的文件继续执行。
另外，RD速度会非常快的，我不觉得比Format慢。不信可以试。
如果通过调用它，会出现一个提示．要你输入ｙ或ｎ，这个提示是无法取消的．98下可以自动格？
所以，这个达不到我的效果
唯有知道硬盘厂商的SDK，直接调用，绕过系统很多异常检查步骤。。速度肯定是很快，另外对一个盘快速格式化时并没有格式化数据，只是初始化引导扇区，速度是相当快的，不过却可以恢复数据。。 上哪知道厂商的ｓｄｋ呀？只是初始化引导扇区，速度是相当快的，不过却可以恢复数据。。
是不是说，初始化后，打开指定分区，里面怎么也没有，如果是，速度又快，就达到要求了．
4.3 FAT表和数据的存储原则 FAT表(File Allocation Table 文件分配表)，是Microsoft在FAT文件系统中用于磁盘数据(文件)索引和定位引进的一种链式结构。假如把磁盘比作一本书，FAT表可以认为相当于书中的目录，而文件就是各个章节的内容。但FAT表的表示方法却与目录有很大的不同。 在FAT文件系统中，文件的存储依照FAT表制定的簇链式数据结构来进行。同时，FAT文件系统将组织数据时使用的目录也抽象为文件，以简化对数据的管理。 ★存储过程假想： 我们模拟对一个分区存储数据的过程来说明FAT文件系统中数据的存储原则。 假定现在有一个空的完全没有存放数据的磁盘，大小为100KB，我们将其想象为线形的空间地址。为了存储管理上的便利，我们人为的将这100KB的空间均分成100份，每份1KB。我们来依次存储这样几个文件：A.TXT(大小10KB),B.TXT(大小53.6KB)，C.TXT(大小20.5KB)。 最起码能够想到，我们可以顺序的在这100KB空间中存放这3个文件。同时不要忘了，我们还要记下他们的大小和开始的位置，这样下次要用时才能找的到，这就像是目录。为了便于查找，我们假定用第1K的空间来存储他们的特征(属性)。还有，我们设计的存储单位是1KB，所以，A.TXT我们需要10个存储单位(为了说明方便，我们把存储单位叫做“簇”吧。也能少打点字，呵呵。)，B.TXT需要54个簇，C.TXT需要21个簇。可能有人会说B.TXT和C.TXT不是各自浪费了不到1簇的空间吗？干嘛不让他们紧挨着，不是省地方吗？我的回答是，如果按照这样的方式存储，目录中原本只需要记下簇号，现在还需要记下簇内的偏移，这样会增加目录的存储量，而且存取没有了规则，读取也不太方便，是得不偿失的。 根据上面所说的思想，我们设计了这样的图4.3.1所示的存储方式。 我们再考虑如何来写这三个文件的目录。对于每个文件而言，一定要记录的有：文件名，开始簇，大小，创建日期、时间，修改日期、时间，文件的读写属性等。这里大小能不能用结束簇来计算呢？一定不能，因为文件的大小不一定就是整数个簇的大小，否则的话像B.TXT的内容就是54KB的内容了，少了固然不行，可多了也是不行的。那么我们怎么记录呢？可以想象一下。为了管理上的方便，我们用数据库的管理方式来管理我们的目录。于是我把1KB再分成10份，假定开始簇号为0，定义每份100B的各个位置的代表含义如图4.3.2 这样设计的结构绝对可以对文件进行正确的读写了。接着让我们设计的文件系统工作吧。先改动个文件，比如A.TXT，增加点内容吧！咦？增加后往哪里放呀，虽然存储块的后面有很多空间，但紧随其后B.TXT的数据还顶着呢？要是把A.TXT移到后边太浪费处理资源，而且也不一定解决问题。这个问题看来暂时解决不了。 那我们换个操作，把B.txt删了，b.txt的空间随之释放。这时候空间如图4.3.3，目录如图4.3.4 这个操作看来还可以，我们接着做，在存入一个文件D.txt(大小为60.3KB),总共100簇的空间只用了31簇，还有68簇剩余，按说能放下。可是？往那里放呢？没有61个连续的空间了，目录行没办法写了，看来无连续块存储暂时也不行。 你一定能够想到我们可以在连续空间不够或增加文件长度的时候转移影响我们操作的其他文件，从而腾出空间来，但我要问你，那不是成天啥也不要干了，就是倒腾东西了吗？ 看来我们设计的文件系统有致命的漏洞，怎么解决呢？其实可以这样解决： 首先我们允许文件的不连续存储。目录中依然只记录开始簇和文件的大小。那么我们怎么记录文件占用那些簇呢，以文件映射簇不太方便，因为文件名是不固定的。我们换个思想，可以用簇来映射文件，在整个存储空间的前部留下几簇来记录数据区中数据与簇号的关系。对于上例因为总空间也不大，所以用前部的1Kb的空间来记录这种对应，假设3个文件都存储，空间分配如图4.3.5，同时修改一下目录，如图4.3.6 第一簇用来记录数据区中每一簇的被占用情况，暂时称其为文件分配表。结合文件分配表和文件目录就可以达到完全的文件读取了。我们想到，把文件分配表做成一个数据表，以图4.3.7的形式记录簇与数据的对应。 用图4.3.7的组织方式是完全可以实现对文件占有簇的记录的。但还不够效率。比如文件名在文件分配表中记录太多，浪费空间，而实际上在目录中已经记录了文件的开始簇了。所以可以改良一下，用链的方式来存放占有簇的关系，变成图4.3.8的组织方式。 参照图4.3.8来理解一下文件分配表的意义。如文件a.txt我们根据目录项中指定的a.txt的首簇为2，然后找到文件分配表的第2簇记录，上面登记的是3，我们就能确定下一簇是3。找到文件分配表的第3簇记录，上面登记的是4，我们就能确定下一簇是4......直到指到第11簇，发现下一个指向是FF，就是结束。文件便丝毫无误读取完毕。 我们再看上面提到的第三种情况，就是将b.txt删除以后，存入一个大小为60.3KB的d.txt。利用簇链可以很容易的实现。实现后的磁盘如图4.3.9 4.3.10 4.3.11 上面是我们对文件存储的一种假设，也该揭开谜底的时候了。上面的思想其实就是fat文件系统的思想的精髓(但并不是，尤其像具体的参数的意义与我们所举的例子是完全不同的。请忘掉上边细节，努力记忆下边)。
还能理解？
但我的却是ｎｔｆｓ文件系统看来，实现删除文件列表，是件难事
也不知，有没有操作磁盘的ａｐｉ，来读取某个分区的磁盘文件列表．或备份，或删除，恢复的
我想应该没有吧？