dslreports logo
 
    All Forums Hot Topics Gallery
spc
uniqs
4

Kilroy
MVM
join:2002-11-21
Saint Paul, MN

Kilroy to bbear2

MVM

to bbear2

Re: File Shredder for Network Drives

I'm not sure you can do this. There is a reason that you need to have the drives connected. You need more than standard file access. When you're accessing a network share you only have file level access.

I don't see being able to do this if the NAS doesn't have some security type setting and/or pulling the drive and connecting it locally.
dave
Premium Member
join:2000-05-04
not in ohio

dave

Premium Member

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:
quote:
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.