dslreports logo
    All Forums Hot Topics Gallery


how-to block ads

Search Topic:
share rss forum feed

not in ohio
·Verizon FiOS
reply to Kilroy

Re: File Shredder for Network Drives

You need more than standard file access. When you're accessing a network share you only have file level access.

I don't believe that to be the case. Here, for example, is how Russinovich's sdelete works:

said by sysinternals :
The second approach, and the one SDelete takes, is to indirectly overwrite free space. First, SDelete allocates the largest file it can. SDelete does this using non-cached file I/O so that the contents of the NT file system cache will not be thrown out and replaced with useless data associated with SDelete's space-hogging file. Because non-cached file I/O must be sector (512-byte) aligned, there might be some left over space that isn't allocated for the SDelete file even when SDelete cannot further grow the file. To grab any remaining space SDelete next allocates the largest cached file it can. For both of these files SDelete performs a secure overwrite, ensuring that all the disk space that was previously free becomes securely cleansed.

That's all normal file-access stuff. Non-cached writethrough I/O is a simple option in the CreateFile API (welll, two separate options, to be exact).

I'm not sure where the "don't do this over SMB" restriction arises. I think you could code it up reasonably well; maybe it's just related to being a good network citizen. NAS is typically shared (that's why SMB has "shares") and it's not nice to consume all of shared storage.

cipher /w operates in pretty much the same way.

The sysinternals writeup does present an alternative approach:

Cleaning free space presents another challenge. Since FAT and NTFS provide no means for an application to directly address free space, SDelete has one of two options. The first is that it can, like it does for compressed, sparse and encrypted files, open the disk for raw access and overwrite the free space. This approach suffers from a big problem: even if SDelete were coded to be fully capable of calculating the free space portions of NTFS and FAT drives (something that's not trivial), it would run the risk of collision with active file operations taking place on the system. For example, say SDelete determines that a cluster is free, and just at that moment the file system driver (FAT, NTFS) decides to allocate the cluster for a file that another application is modifying. The file system driver writes the new data to the cluster, and then SDelete comes along and overwrites the freshly written data: the file's new data is gone. The problem is even worse if the cluster is allocated for file system metadata since SDelete will corrupt the file system's on-disk structures.

In other words, an implementer would be nutty to attempt to do it like that.