BUG REPORT: Eraser doesnt follow NTFS junctions
- Thread starter bb123
- Start date
Subsequently, I was testing 2551 in relation to the context menu bug (now, I believe, fixed) discussed on the Beta forum. The System.IO exception I was getting now seems to relate to this discussion, so what follows is a repeat of the post I made in the other thread.
Could your fix in 2555 have dealt with this as well? If so, I'll test.
David
No, it doesn't. And it's not a function of the context menu, either, because I've just had it on a drag and drop erase. It seems to be related to the fact that the target folder contains a junction. I get a 'Task completed' System Tray message, and the task is deleted from the Schedule. The target folder and the junction it contains are not erased, but the no-junction folder within the target folder is erased.Joel said:
Could your fix in 2555 have dealt with this as well? If so, I'll test.
David
Got it, I think. Became increasingly sure that the fix did not address the problem, so tested anyway.
Build 2557. Used OP's setup (actually in the root of Drive E:, but I don't think that matters), and tried each element of the setup in turn. Results:
But the really nice thing is that if you erase the junction before the intermediate folder, that works perfectly. It seems that the exception is only generated when the junction is 'widowed'. For that reason, you cannot erase the whole setup from and including the top level folder, beause the intermediate level folder will be erased before the junction (I assume because it was created first in the setup process).
What a very clever bug! I have spared you a lot of crash reports, all saying the same thing
David
Build 2557. Used OP's setup (actually in the root of Drive E:, but I don't think that matters), and tried each element of the setup in turn. Results:
- the lowest level folder (under the original folder and the junction) is erased;
- the intermediate level folder is also erased;
- the junction is not erased, and (invariably) generates the crash as previously described;
- as you would expect, the top level folder containing the junction is not erased and generates the crash.
But the really nice thing is that if you erase the junction before the intermediate folder, that works perfectly. It seems that the exception is only generated when the junction is 'widowed'. For that reason, you cannot erase the whole setup from and including the top level folder, beause the intermediate level folder will be erased before the junction (I assume because it was created first in the setup process).
What a very clever bug! I have spared you a lot of crash reports, all saying the same thing
David
Joel
Active Member
I've reproduced the crash, yes, it is because of hard links. But not because of what we all thought.
Hard/symbolic links can point to anything, but there is no guarantee that what they point to exist. We are tripping here because the hard/symbolic link exists, the .NET framework reports that they exist (the DirectoryInfo/FileInfo class' Exists property is true) but because what they point to is non-existent... other APIs complain that the file does not exist. Paradox?
Just more implementation details to grapple...
Hard/symbolic links can point to anything, but there is no guarantee that what they point to exist. We are tripping here because the hard/symbolic link exists, the .NET framework reports that they exist (the DirectoryInfo/FileInfo class' Exists property is true) but because what they point to is non-existent... other APIs complain that the file does not exist. Paradox?
Just more implementation details to grapple...
Joel
Active Member
Oh, and I'm not sure if we should include this in our document for Eraser testing. Links would only become more complicated as people become aware of its capabilities.
Perhaps we should develop a regime or set of steps? Shall we discuss this offline David? Or we can start drafting a document on Trac.
Perhaps we should develop a regime or set of steps? Shall we discuss this offline David? Or we can start drafting a document on Trac.
Joel
Active Member
Fixed in r2561 for Eraser 6.2 and r2562 for Eraser 6.0. r2562 brings about reparse point support for Eraser 6.0 roughly equal to 6.2. However, when 6.2 is released there will be near-perfect reparse point support (because of #277.)
I somehow think that 6.2 would be a under-the-hood upgrade for 6.0... =shrug= which would make it difficult to justify for users to make the change.
I don't think there are too many user-visible changes to 6.2 at this point.
I somehow think that 6.2 would be a under-the-hood upgrade for 6.0... =shrug= which would make it difficult to justify for users to make the change.
I don't think there are too many user-visible changes to 6.2 at this point.
Thanks, Joel. I'll test 2561 when I can, probably later today.
As I think you were implying, one needs to take a balanced view of the amount of effort to be put into reparse point support. I don't think that they are that much used in the real world, and certainly not by most Eraser users.
As regards the testing schedule, perhaps I should start a new thread in the Programming forum. I believe that, given the open source character of Eraser, discussion of how we test should be in the public domain, and we may get helpful participation from other users.
David
As I think you were implying, one needs to take a balanced view of the amount of effort to be put into reparse point support. I don't think that they are that much used in the real world, and certainly not by most Eraser users.
As regards the testing schedule, perhaps I should start a new thread in the Programming forum. I believe that, given the open source character of Eraser, discussion of how we test should be in the public domain, and we may get helpful participation from other users.
David