0

I created a junction with the Sysinteral's Junction tool, and in a moment of stupidity, didn't see how to remove the junction from the below output of junction.exe /? (Though hopefully some will agree that it doesn't follow most other cmd.exe programs' help output, and is not the clearest help output out there).

Junction v1.06 - Windows junction creator and reparse point viewer Copyright (C) 2000-2010 Mark Russinovich Sysinternals - www.sysinternals.com

The first usage is for displaying reparse point information, the second usage is for creating a junction point, and the last for deleting a junction point:
usage: junction.exe [-s] [-q] -q Don't print error messages (quiet) -s Recurse subdirectories

usage: junction.exe example: junction d:\link c:\windows

usage: junction.exe -d

... and instead decided to try coy'ishly:

  1. Deleting (moved to recycle bin) the junction directory ... Didn't remove junction target.
  2. Emptying the recycle bin... DID(!) remove the junction target.

I have tried using:

  1. Piriform's Recuva (Specifying both the parent directory of junction directory, and junction target to Deep scan in; and "Recycle Bin" (All drives) searches)
  2. Roadkil's Undelete

... which have been helpful, (1) most so, in past undelete tasks, with no matches to either the junction target directory contents, the junction target directory, or the junction directory.

Noting that I don't have shadow copies turned on - Do I need a undelete program that can "understand" (?parse?) junctions, or is there some other way to recover the target data?

Seth
  • 9,000
  • 1
  • 19
  • 34
user66001
  • 1,228
  • 3
  • 14
  • 26
  • First, stop using the disk, because by the time I write this, the disk will eventually replace some clusters where the data was, therefore rendering the deleted file unrecoverable. Second, and assuming you stopped using the disk by the time you deleted the file, then all of those tools should work, as the file would still be there. – Doktoro Reichard Oct 26 '13 at 19:43
  • Very confused by your comment. If I had stopped using the disk immediately, and didn't find the files, your reply is incorrect; If I hadn't stopped using the disk, but didn't find the files, it doesn't help. P.S I am aware of the way NTFS works. The above tools found no trace of the files/directory, which is unheard of given the timeframe that has passed (NTFS stores at least the filenames for yonks after file data is overwritten - Try Recuva and see), which leads me to believe they are having issues with the Junctions. – user66001 Oct 26 '13 at 20:09
  • Technically it is not unheard of... When you delete a file, what you are actually doing is telling the file-system to change a bit in every cluster that file occupied to signal it is open to be written (i.e. it's *free space*). As normal OS operations write and read into the disk, it is possible (depending on how full your disk is) that the clusters formerly occupied by your file are now full of other data, thereby rendering your previous data unrecoverable. – Doktoro Reichard Oct 26 '13 at 20:16
  • I thought that the File Allocation Table marks the space as unusued, and didn't go and overwrite the data itself (Hence the need for "secure" overwriting software). Further, I am not sure, but believed that the File Allocation Table stored the filename until it hit the maximum size for the File Allocation Table, before the filename got overwritten (Like many weeks/months down the line), but regardless I have never struck a file I have deleted within the last week, not showing in Recuva as (at least) "unrecoverable" (Filename found in File Allocation Table, but data overwritten - I understand). – user66001 Oct 26 '13 at 20:26

0 Answers0