I have made this simple class for safe deletion on windows operating system. I have read that your deleted files are even recovered after completely formatting your hard disk. Following deletion guidelines, I have made a a program that deletes files but first writing over the file many 7 times or as many times as the user has mentioned.
I want your participation to make it more foolproof. Maybe some member here is using windows and he is going to format his computer. I want him to test this with a small text file, say "new.txt" on the drive he is going to format. Later he may try to recover the file using some powerful data recovering software and see if the data is recovered. Other member may give some idea...
The text file "new.txt" may contain: "JAVA" only. It makes it 4 bytes.
You can't do this kind of thing this way. The 13 copies of your file might all use different blocks on the filesystem!
The only way to do this is to use low-level OS-specific I/O calls to talk directly to the disk itself, addressing the specific sectors that you want to secure-delete. You're not going to be able to do this in Java.
It might work if you use RandomAccessFile, keep seeking back to the beginning and overwriting the data without closing the file. But it also might not; there's no guarantee the data will actually go out to the disk.
Finally, note that you're mixing up two different issues here: one is that deleting a file generally doesn't delete the data, on most system; it just removes a directory entry, leaving the data intact. This is why something like "Norton Undelete" had such a successful run, back when the FAT filesystem made this very simple to fix.
Then there's the other issue which is that even if data is overwritten, magnetic traces of the original data can still remain. This data is hard to recover, and requires special tools (possibly including opening up the disk in a clean room.) But for industrial espionage and other high-stakes data recovery attempts, it is sometimes used.
To be fair, you can use a RandomAccessFile, then force the associated FileChannel by calling getChannel().force(). Or call getFD().sync(), which should provide the same effect. It seems a rather poor design that these methods were not included directly in RandomAccessFile, but they're still available. They're just hidden.
"I'm not back." - Bill Harding, Twister
Joined: May 09, 2002
Well thank you for these replies. Please don't say that it is a bad design jim. maybe they had in mind that local writing was not needed! But I still did not grasp the difference between Java writing to a file and the real writing to the disk. How does the disk then store the file written by Java?
Now I wait for someone who will actually format his drive after using program and then try to recover data with the most powerful tool that he has
Maki Jav [ December 22, 2007: Message edited by: Maki Jav ]
Originally posted by Maki Jav: But I still did not grasp the difference between Java writing to a file and the real writing to the disk. How does the disk then store the file written by Java?
It is not specific to Java. The same would be true of any ordinary user application writing to disk via the ordinary APIs.
Most operating systems have facilities to delay or buffer data written to disk by ordinary APIs. They do this for performance. And, potentially, if many writes to the same part of the disk occur, in a short time, the operating system may never actually write some of those to the real disk; in the worst case, only the last would really get written.
One can also imagine that disk drives themselves may implement write buffers. They certainly implement read buffers.
Betty Rubble? Well, I would go with Betty... but I'd be thinking of Wilma.