Warning! Possible serious bug.

A

Anonymous

Guest
OS = XP Pro SP2

Steps to reproduce:
Drag a folder populated with files to the CD-RW in My Computer in order to be copied. XP by default places a copy of the folder and files in "C:\Documents and Settings\*user*\Local Settings\Application Data\Microsoft\CD Burning" until you actually write the files. If you then open the CD (view files to be written) and open the folder within the CD, then select all the files, then right-click and then erase, the files in the original location become zero length and unuseable. The files in the CD Buring folder completely disappear (which is to be expected). What isn't expected is that eraser zero's out the files from the original location too. The original folder is still there and the files are all there but they are all zeroed out (empty as verified with Disk Invetigator). If I go through the same steps and simply delete (using XP's Delete) the files in the CD Burning folder (from the CD drive in My Computer) the original files are left intact. I know an easy workaround would be not to use eraser to delete files that are pending to be burned, but I think Eraser is a great program and have got into the habit of right clicking and selecting erase instead of delete any time it is available. This time however it bit me hard. These were photos of my best friend's recent birthday and as far as I can tell by looking at the raw disk data sector by sector, the original files have indeed been over-written.

Users please be careful! To the author, please take a look at this behavior and see if it can be fixed or if it's another one of MS's undocumented gotcha's. BTW, I was using v5.3 when I noticed this so I unistalled completely and installed the latest v5.7 and can still reproduce the problem.

If you need any additional details you can email me at:

kgoods at aiainsurance dot com

Kind regards,
Ken Goods
 
reply

perhaps u could just delete them & then use eraser to "erase" recycle bin to be sure nothing LiKe tha happens.
 
I believe this is why...

XP, like Unix and other OS's, has the ability to create symbolic
links to files. With a sym-link, a file stored in folder A and one in folder B CAN actually access the exact same location on disk. When you add
files to the CD burner using XP's built in IMAPI service, it
creates symbolic links to the files. Thus, when you erase the files
from the CDBurning folder it overwrites the SAME LOCATION
as if you had erased the originals. Then, it erases the sym-links
in the CD-Burning folder. It never actually delves into the original
files folder. Thus, the files in the original folder still exist, but the
information (which was pointed to by sym-links in the CDBurning folder)
is overwritten. This is a MAJOR draw back to having a system that allows
sym-links and having programs for that system that don't take them into considaration. This is also a major security hole. For example, suppose
I have a file A, and a file B. Let A = pagefile.sys (your system's page
file) and let B = a sym-link to A. Now, A is being used by the system and
is locked, but B is not. So, I can theoretically erase B (the contents of it)
and this will also erase A. Of coruse, the solution to this is to lock not
the file but the HD sectors. I haven't checked, but I would hope XP
handles this properly. In any case, Eraser is not malfunctioning when
it erases the file in CDBurning. It is simply erasing the data represented
by a sym-link that is pointing to the same disk sectors as the original
file. The underlying "problem" here, if you wish to call it one, which I
don't, is that Eraser accesses the information in a "low level" manner.
It does not ask the OS "What kind of file is this, a real one or a sym-link"?
It simply Erases the sectors pointed to by the link. End of story.

I suppose in the future they could implement a check under XP to
see if you are erasing a true file, or a symlink. However, to make you
feel even better, the sym-links do not need to be "wiped" since they
never contain any of the actual data anyways. They just point to
a HD location.

To check this, follow these steps:
1) Open my computer, and and right-click your system drive.
2) Copy down the amount of used space (in bits).
3) Go through the process of adding, say, 500MB, of files
to a CD (don't actually record it, just add them).
4) Repeat steps 1 and 2.
5) The used space after adding the files should be very close to
the used space before adding them. This is because sym-links
allow you to have N copies of a file without taking up N times
the space required by the file.

I did this just now. I copied 134MB of files to the CD, but the used
space on the drive only increased by 4MB (the amount of space it
took to create the links). However, when I checked the used space
in CD Burning it reported 134MB because it was reporting the total
size of all the files that the sym-links in the folder were referencing.

If it makes you feel better, remember this: a sym-link never actually
moves any of the original file's data on the disk. It simply creates
a reference to the sectors on the disk where the original files were
stored. Therefore, you don't need to wipe them because they contain
no sensitive data (asside from a reference to the original file name).
Therefore, if you are really concerned that someone would gain a lot
of information from the file names, simply do a normal erase on the files
and then wipe the free-space on your disk.


RJS
 
P.S.

Shouldn't the admin/developers have known this if they are
developing a "security" tool? Hopefully, they just haven't
bothered to respond. I would hate to think they knew
so little about the OS to be able to solve this problem.

RJS
 
problem solved

if i gather what you are stating correctly... leave your "close writing wizzard" UNchecked before you write to disk... after writing your info to disk, click the RED-X to close the "writing wizzard"... click "select all" THEN click "Move slected items"... (of course your moving them to a PRE-made folder in "your documents" you named "erase this")... then erase that... hope this helped what seemed to be your problem. it leaves the origional folder you copied to write alone...
 
I just burned a lot of data to CD in Windows XP. Later, every file in the original hard drive location that was burned to CD became zero length and unusable!

What a disaster! I have lost thousands of files!

I don't recall erasing anything in the CD burning folder, either. As best as I can figure out, the CD Writing Wizard just threw the sym-links in the recycle bin. Then later, when I erased the recycle bin, all the files in their original location were wiped out.

If this is indeed what happened, I can't think of any workaround short of not using Eraser.
 
Why on earth are you erasing SymLinks? SymLinks are hard links to the file it points to - meaning it is DELIBERATELY meant to ACT like the file it is pointing to (masquerade is the word here).

That is by design of what symlinks and junctions are (I believe it really isn't symbolic links - Only Vista has symbolic links, you're talking about reparse points). I am not sure offhand if we can even tell whether the file we are erasing is a symbolic link or otherwise. BUT I did check in a change in v5.85 which should ignore symlinks.

You are free to try it.

Joel
 
Joel said:
Why on earth are you erasing SymLinks? SymLinks are hard links to the file it points to - meaning it is DELIBERATELY meant to ACT like the file it is pointing to (masquerade is the word here)...
Joel
I wasn't deliberately erasing the links. One of two things happened:

1. Somehow I did actually erase the contents of the burn folder. (This is easy to avoid doing in the future.)

-or-

2. When the CD writing wizard threw away the list of files in the CD burn folder, and the recycling bin was subsequently erased, it then erased all of the original files the links pointed to.

I can't think of a way to avoid a repeat of this if #2 is what happened, other than not to ever use Eraser again after burning CDs.
 
You can try to delete a symlink to simulate burning a CD. and then erasing using the latest beta like I said. I believe the new beta should not exhibit the same behaviour.
 
I also came across this problem two years ago (I lost a lot of music files, learning the hard way!) and actually made a post about it in response to a similar observation made by a poster about a year and a half ago:

http://www.snugserver.com/phpbb2/viewto ... f1197c2057

Unless the CD writing wizard itself actually deletes the files without sending them to the Recycle Bin then it is best not to use eraser to erase anything that gets sent to the recycle bin that was intended to be written to a CD. Doing so will leave the original files as 0kb files.

I've just been able to recreate this problem again. By creating a bunch of files to test, I did the following (Windows XP / Eraser v5.7):

1. using Send To - send the selected files to my CD/DVD drive

2. click on the balloon "you have files waiting to be written to the CD"

3. "changing my mind" about writing the files, on CD writing tasks in the CD drive choose the option "delete temporary files". The files are sent to the Recycle Bin - they shouldn't be (they aren't when the files are successfully written to CD, though see below) but this is what the operating system does.

4. Run Eraser on the Recycle Bin and

5. clicking on the original files I observe that original files are 0kb in size.

The only way to avoid this is to delete the above files from the Recycle Bin, not Erase them.

I once had the CD Writing Wizard actually remove the files to the recycle bin AFTER I had successfully burned the files to CD (it should have deleted them totally, not sent them to the RB) but as I knew what would happen if I erased them I just used the Delete option instead.

It seems to be a quirk of the Windows XP system, a bug that Microsoft
probably don't realise will cause problems if anyone erases those files rather than just deleting them.
 
Yeah, because Erasing files is not considered an "everyday" task people would do. Only the most paranoid and security-oriented would.

You are using 5.7. Does 5.86 RC1 have this problem of erasing these "files"?

Joel
 
Back
Top