Eraser *IS* following junctions/symlinks and wiping data

ben9892

New Member
I was alarmed to discover last night that contrary to the manual Erasure DOES follow junction points/symlinks and does erase the content at the followed location (but leaves the empty followed directory there). I read and re-read the manual and find no other interpretation but that Eraser should not have done what I observe it doing. Obviously this is alarming because this means you can wipe totally unintended files. I demonstrate this in the screen capture video I attach. Also shown is the alarming situation (which is as expected given the problem) that if you had copied the folders which included the junction then of course the Eraser deletion has wiped the copy's referenced material (since the copied junction pointed to the original which Eraser wiped). I tried the same thing with symlinks and got the same results.

This is not some Rick Roll, I just couldn't figure out an easier way to show what was happening than a screen captured video. I am using the latest Eraser downloaded yesterday.

http://youtu.be/mRsUJYyv6lc
 
Thanks for reporting this: I'm looking at the code again now. I don't remember changing the behaviour, but I'll let you know when I got more information on my hands.
 
Joel said:
Thanks for reporting this: I'm looking at the code again now. I don't remember changing the behaviour, but I'll let you know when I got more information on my hands.

Just to provide a bit more information... In the end I must have run like 20 tests, trying to see what it would follow, junctions or symlinks, and whether it mattered if there were other contents in the directory with the junction or symlink, and whether it mattered if the target of the reparse point was on a remote drive. And in my tests it wiped the content on local or remote (on other drives) folders pointed to by junctions or symlinks. But I may have observed an exception. My tests were generally of the sort I videoed:

c:\temp\a\a.txt
c:\temp\b\junction_to_a

I would erase b and it would erase b and its contents including everything inside of a (leaving directory a, but wiping its timestamp).

But I believe I did a test where the contents looked like:

c:\temp\a\a.txt
c:\temp\b\symlink_to_a
c:\temp\b\some_other_file.txt

And in that situation with a symlink I think it left directory a alone. I think I repeated the test with a junction and it wiped everything in directory a. I'm sorry I am not 100% sure of the details, I was focused on trying to understand what data of mine might have been wiped out inadvertently and not debugging your program.

A separate important note... The contents I had been erasing were an external drive backup of the files from "C:\Users" which includes quite a few junctions by way of Microsoft install, as well as quite a few symlinks (and possibly a junction or two) I created within my user's desktop, documents, etc. My erasing was interrupted repeatedly by access issues where I had to change ownership (the backup was of the current machine but made on another machine because my drive was failing and I wanted an emergency backup). I then observed that some of the junctions were not pointing relative but were pointing at the live, main drive. I got paranoid and tested Eraser's behavior with junctions/symlinks. I spent the entire day yesterday diffing and rediffing my current drive against a recent backup to see what was erroneously erased/wiped and the unexpected result I found (given the tests) was: nothing. Either the numerous access issues let me become paranoid before Eraser had a chance to traverse a folder with junctions/symlinks, or (far more likely, based on how much content was erased) Eraser did not follow a symlink or possibly a junction, at least not one leading to the main drive. The directories it did wipe were much more likely to contain symlinks, because that's what I create by default and the directories wiped were mostly not Windows-install created. The explanation could relate to the test I did with a directory which has a symlink and another piece of content which for some reason prevented Eraser from following the symlink.

Anyway, very long post, but figured some of the details might help shed light on the logic that might be going wrong.
 
I was examining it for a bit and found that Folder reparse points ARE followed but File reparse points are not. I also found that 6.2 has a different behaviour from 6.0 in that Folder reparse points are not followed there.

So in this scenario I think the documentation just needs updating. I'm however more curious when did this change slip in... I'll investigate further (but probably only at the end of this week, unfortunately)
 
Joel said:
I was examining it for a bit and found that Folder reparse points ARE followed but File reparse points are not. I also found that 6.2 has a different behaviour from 6.0 in that Folder reparse points are not followed there.

So in this scenario I think the documentation just needs updating. I'm however more curious when did this change slip in... I'll investigate further (but probably only at the end of this week, unfortunately)

Obviously it's your baby and you can do whatever you like, but as a user I would strongly encourage you to stick with what people expect and I believe what people expect of your wipe program is that it behave as Windows Explorer does when deleting, especially as you integrate with Explorer. Windows Explorer will NOT delete the contents of a referenced reparse point when you tell it to delete a folder, so how could a user expect choosing the Eraser option from a folder's context menu in Explorer do something completely different. Anyone who does could lose unintended files.
 
I agree with you. Hence I believe that's why Eraser 6.2 has its behaviour changed.

However, it is generally bad practice to change behaviours like this in the middle of a release cycle, which is also why I want to find out how this behaviour got in (and how there's a documentation discrepancy). If Eraser is following reparse points because of an unintended behaviour change caused by bug fixes, then it should be restored to not follow reparse points. However, if Eraser never followed reparse points to begin with, then it should remain that way as other people may be relying on that behaviour (unintuitive as it is)

I hope you understand. I'll post more when I have the info (last Sunday's investigation yielded quite little)
 
Back
Top