Junctions not recognized on Move, source contents deleted

[StatusQuo]

When deleting a junction, TC acts safe and does not recursively delete the contents behind it.
When moving a junction however, TC does recursively delete its contents.

This only applies when moving to another drive, because moving on the same drive will be done similar to a rename.

To reproduce (at least two NTFS drive letters needed to store the junction, e.g. C: and D: ):

• - create a directory C:\TEMP1\TEMP2\TEMP3
  - create a junction to C:\TEMP1\TEMP2, stored as C:\TEMP2 (or on another drive)
  - move the junction C:\TEMP2 to D:\ (resulting in D:\TEMP2)

Result: Not only the junction is moved, but all contents are moved (C:\TEMP1\TEMP2 is empty after this)

Expected result: moving the junction C:\TEMP2 should not alter the dir C:\TEMP1\TEMP2, but instead only move the junction itself
(that would mean creating the junction at the target and deleting it from the source).

If that's not possible, to prevent data loss: TC should refuse to move, at least warn the user,
that data gets moved from a position other than the one selected.

Implementation should not be that hard, because TC is already able to recognize junctions:
on deleting they are treated correctly (not parsed recursively), while not using Explorer method.

[icfu]

Result: Not only the junction is moved, but all contents are moved (C:\TEMP1\TEMP2 is empty after this)

Confirmed!

Expected result: moving the junction C:\TEMP2 should not alter the dir C:\TEMP1\TEMP2, but instead only move the junction itself
(that would mean creating the junction at the target and deleting it from the source).

Yep!

If that's not possible, to prevent data loss: TC should refuse to move, at least warn the user, that data gets moved from a position other than the one selected.

If anything else fails, ok...

By the way:
The shell extension NTFS Link works correctly. You can use Ctrl+X and Ctrl+V to move only the junction. Also when this shell extension is installed, you can even safely use the Explorer deletion method.

Icfu

[StatusQuo]

2icfu

By the way:
The shell extension NTFS Link works correctly.

Thanks for the hint, testing this is on my ToDo-list...

[ghisler(Author)]

The Copy and Move functions ignore junctions and copy/move the data itself. Reason: If for example you want to make a backup to an external harddisk, copying just a junction would not backup anything at all. The same is true when moving data to a new harddisk.

[icfu]

I don't want to have any application destroy my junctions and data structures behind them, besides when I explicitly choose to delete them.

If you are not willing to change this dangerous MOVE feature by default, at least add an option to switch the behaviour. Thanks.

Icfu

[Flint]

In e.g. Midnight Commander there is just an option in the Copy dialog - "Follow symlinks" (or something similar, don't remember exact name). Why not add it into TC's dialog as well? Turned on by default, of course.

[Lefteous]

This would be no problem if there would be a way to exclude directories by using a plug-in.

[Flint]

This would be no problem if there would be a way to exclude directories by using a plug-in.

Hm... I'm not sure. You'll be able to exclude symlinks, but this won't allow you to create copies of them on another side, you'll have to recreate all the symlinks by hand.

[StatusQuo]

2ghisler(Author)

Reason: If for example you want to make a backup to an external harddisk, copying just a junction would not backup anything at all. The same is true when moving data to a new harddisk.

This could be OK on copying - but never on moving, IMO.
Moving a junction/symlink including its contents, removes those contents from the original place - destroying the directory structure there.

Example: if you make a junction to C:\Program Files and move it somewhere else:
you'll end up with an empty programs folder, all (or most) programs from there may stop working, the entries in start menu get invalid.

Another example: if you try the same with a junction to your windows directory:
this will probably kill your windows installation (at least if you have admin rights).

An option to follow symlinks would be OK for me, too (maybe on by default - configurable off by default would be better).

[StatusQuo]

Not changed in TC 7.03.

[JudgeAxl]

There's also an issue with junctions if you copy files between subdirs in junctioned directories on the same drive, but mapped to different drives.

Example:
Create a folder D:\target
Create a junction C:\target -> D:\target
Copy a large file into the target folder.
Show C:\target in the left pane and D:\target in the right.
Move the file with a new name (F6) from one side to the other.
Result: The file is copied to the new name and the old file is deleted.
Expected: The file should just be renamed since both panes actually show a folder on the same drive.

I don't know if it's TC or Windows that determines the appropriate action, but it'd be very nice if it could be handled, since I tend to use a lot of junctions between my two drives. I do this in order to trick Windows to put my data on an extra drive without having to hack the original paths in the registry.

Cheers
/axl

[ghisler(Author)]

As I have explained already, this is NOT a bug. What should TC do in your opinion when you copy a directory with junctions to e.g. an external USB harddisk? Just copy the junctions pointing to your main harddisk? That doesn't make any sense! Why would you want to copy these junctions to the external disk then?

[JudgeAxl]

Sorry, I obviously meant to write move/rename in the introductory paragraph (as I did in the example steps). I would absolutely expect a copy to be a copy and nothing else.

/axl

[JudgeAxl]

I see now that I should probably have started a separate thread as it seems the other posters were primarily referring to the junctions themselves. I'm only concerned about real files/folders contained within junctioned directories.

Cheers
/axl

[StatusQuo]

2ghisler(Author)

What should TC do in your opinion when you copy a directory with junctions to e.g. an external USB harddisk?

This could be OK on copying - but never on moving, IMO.

Using your example it is perfectly OK (only) for copying.
I strongly think TC should behave differently on moving.

When moving a dir structure like D:\archive_example (containing a link to %SystemRoot%) to an external harddisk,
I would NOT expect that my local windows system files get deleted (like it is now).

Unexpected deleting of (maybe important) files I'd call a serious bug.