Junctions not recognized on Move, source contents deleted

[StatusQuo]

Fixed in TC 7.04 - thanks.

It seems that icfu's INI option or Flint's dialog option didn't make it into this release,
but the data behind junctions is safe(r) now.

[ghisler(Author)]

Indeed I have implemented the most logical solution to the problem now, so this should cause the least troubles.

[MVV]

Eh, junctions are so god stuff but we have so many troubles with it

I had a junction "%USERPROFILE%\Saved Games\Sample Name" pointing to folder "My Documents\Sample Name" (on Windows XP and Vista this game requires different folders for saved games so I use junction ).
Today I moved "%USERPROFILE%\Saved Games" folder to another drive in order to move backup data from system drive to data drive and to replace this folder with a junction to it.
But unfortunately when I moved "%USERPROFILE%\Saved Games" into a new location, TC replaced junction with regular folder and moved all junctioned folder's contents so my original "My Documents\Sample Name" folder became empty It is good that I observed this fact...

I think it would be great to have some option like "Preserve junctions" into "Options >>" menu in copy dialog.

I tried to cut-paste such folder with junction in order to see result. Windows leaved untoched original folder but replaced a junction with just empty folder.

[StatusQuo]

Confirmed.
When moving a parent folder containing junctions, the files are still deleted from the original place.
Data behind junctions is only safe when moving the junction itself.

Treating junctions in subfolders the same way like when moving a junction directly would be fine for me.

[Balderstrom]

I don't see why TC can't be more intelligent in this regard. I believe almost all file copy and move commands in linux have a flag in regards to how to handle hard/soft links, and whether they should be reparsed or not.

Options in .ini:
FollowJunction=0|1|2
FollowHardlink=0|1|2

0: Do Not reparse, create a new Valid Junction|Hardlink if possible.

# If a Junction points to a Folder that is within the path being copied,
then the new Junction would point to the new path.
# If a Hardlink cannot be created, due to different Volume, then a copy is created.
In win7/Vista, Symlinks are supported, that can traverse different volumes.

1: Reparse and always Copy contents to new Location.

If action is a Move operation, contents are copied instead.

2: Reparse and allow Move to new Location.

#If action is a Move operation, contents are moved.
#If file has hardlink clones, moving it to another Volume will break the clones,
this should be disallowed. A copy is done instead.

[StatusQuo]

This is still in "Fixed bugs", although unwanted data deletion still happens in TC 7.50 RC1 (XP SP3),
when junctions are contained in a subfolder while moving the parent folder to another drive.

This applies to all copy modes (Standard, Default, Big file copy mode), no matter if "Compatibility mode" is active or not.
At least a single working mode would be better than none at all, IMO...

Should this thread be moved, or a new report created?

[ghisler(Author)]

I don't understand your problem, what do you refer to?

[MVV]

I don't understand your problem, what do you refer to?

If you move a junction, TC just moves junction.
But if you move a folder with a junction inside, TC creates usual folder instead of junction and moves all contents of junction target folder so target folder becomes empty. This happens only when move onto another logical disk.

Oops... I noticed that TC moves junction in such way always between different drives. This creates a great mess! Because target junction folder becomes empty!


I don't understand... TC deletes not all contents...

I have following inside folder "1":
files 1.txt, 2.txt, 3.txt
subfolder 1F with file 4.txt and subfolder 11F

I make junction near folder with name "1J" and move it onto another logical drive. TC shows error message "Can't delete folder 1F". I press OK. Result: junction copied as usual folder and TC deleted subfolder 2F. Seems not to be right and similar behaviour!


Another test. I have folder "1" as described above. And near a folder "2" with junction 1J inside.

I move folder "2" onto another logical drive. Result: my folder "1" became empty and all files are moved into new location. So, I lost my files through junction!

[Balderstrom]

Which is one of the reasons, that something akin to my suggestion above makes sense.

I'd prefer option 0 as the default:

0: Do Not reparse, create a new Valid Junction|Hardlink if possible.

# If a Junction points to a Folder that is within the path being copied,
then the new Junction would point to the new path.

Means, If you have a junction like: C:\Folder\Temp3 -> C:\Folder\Files1\Files2\Files3

If you Copy or Move, C:\Folder (and contents elsewhere) say to D:\FolderBAK
Since there is a junction within the contents, AND points within the path being copied|moved, the New junction:
D:\FolderBAK\Temp3 -> D:\FolderBAK\Files1\Files2\Files3

And it would be icing on the cake if the SyncTool had override checkBoxes for alternate behaviour when you actually want to backup.

[StatusQuo]

Another example:

C:\Tools
C:\TC704\Tools (being a junction to C:\Tools)
C:\TC750\Tools (being a junction to C:\Tools)

Having the above folder structure:

• copy a file into C:\Tools
• move folder C:\TC704 to another drive like D:\

=> both C:\Tools and C:\TC750\Tools are empty, the file in there was deleted

[StatusQuo]

Fixed in TC 7.50, moving a tree with junctions in sub-folders is now safe, too.
(tested standard and internal copy method, 9 levels deep)
Thanks a lot.

[MVV]

Fixed in TC 7.50, moving a tree with junctions in sub-folders is now safe, too.

Confirm. Junction target dir contents are kept untouched now by TC.
(funny that Windows Ctrl+X/V delete its contents on XP! )

I wish to be informed when TC copies folder instead of junction - http://www.ghisler.ch/board/viewtopic.php?t=23908

[ghisler(Author)]

Thanks!

[MVV]

Strange, I move junction within same volume but TC moves it as folder (copies contents and removes source junction)...

Strange because within one pair of folders TC moves same junction well, but within another pair... Trying to find any reason... Understood, one of that folders was inside of junction pointing to another volume.

But Windows 7 on cut-paste deletes files in junction target.
So, people, use TC, don't use Windows 7 Explorer.

[vnicolici]

I'm sorry, the current implementation is better, preventing data loss most of the time, but is still wrong.

Example environment:

HDD C:\ containing a Windows 7 installation, system booted from C:\
HDD E:\ containing another Windows 7 installation (for example my old HDD)
HDD G:\ - an empty backup drive

Use case: I want to backup HDD E:\ to HDD G:\

Expected result:
No data from drive C:\ is copied to drive G:\

Actual result:
Data from drive C:\ is copied to drive G:\ if a link/junction from drive E:\ points to it.

Since in Windows 7 installations C:\Users\All Users points to the C:\ProgramData directory, the E:\Users\All Users directory will also point to the C:\ProgramData directory, because it contains the absolute path, including the drive letter.

So, after the backup on the G:\ backup drive, I will have two directories: G:\ProgramData, containing files from E:\ProgramData as expected, and G:\Users\All Users, containing files from C:\ProgramData as in WTF.

This is a huge security issue (in my opinion). Let's say a friend comes with two drives - E:\ and G:\ as described above, and ask me to backup drive E:\ to drive G:\, because his system doesn't boot anymore and he cannot do it himself. The friend will end up with both a copy of his E:\ProgramData folder and MY C:\ProgramData folder on his backup drive.

This is not hypothetical. I was that friend, and now I have a copy of some of the files of my boss, that offered his system to perform my backup, because of this bug. And I did NOT want those files on my backup drive. And I don't even know where ALL those files might be on my backup drive so that I can delete them.

Furthermore, since I used move instead of copy to perform the backup, I was scared shitless that I moved files from the computer of my boss to my backup drive, when I saw it moving pictures and documents I didn't recognize (I didn't know it was just copying them at the time. I'm still not 100% sure it didn't move some files.)

As to the expected behavior, I realize that different people have different and conflicting use cases, and the behavior I require may cause issues for other users. But, as a software developer, I always believed in giving the user as many options as possible (that's why I don't use Apple products, if at all possible).

As such, I think that giving the user the option to specify how to handle links/junctions in the copy / move / delete dialogs is the best way to fix this issue. In particular, I'm very interested in having at least a "do not copy link/junction target content" option, and/or, even better, a "create junctions and links on copy instead of copying target content" option for the copy and move operations.

If you are afraid this will cause support issues, from users that don't understand links/junctions, you could enable the options only after IUnderstandSymbolicLinksAndJunctions=true is added to the ini file.

Furthermore, the behaviour is inconsistent. If I try to copy for example C:\Documents and Settings (a junction pointing to C:\Users) to G:\, an empty G:\Documents and Settings folder is created. This doesn't seem to make any sense, because I understand that the target content should be always copied. Is the behaviour different if the links/junctions are on the boot drive? Or, are some paths on the boot drive hardcoded to have this inconsistent behaviour? Because links I create manually on the C:\ drive do not behave like this.

I used the Midnight Commander on Unix/Linux systems for a long time. And the options for symlinks make a lot of sense, in particular the "Follow Links" option:

Follow links
tells whether make the symlinks and hardlinks in the source directory (recursively in subdirectories) new links in the target directory or whether would you like to copy their content.

Stable symlinks
commands Midnight Commander, that it should change symlinks in the target, so that they'll point to the same location as it did before. With absolute symbolic links this does nothing, but if you have a relative one, it will recompute its value, adding necessary ../ and other directory parts and making the value as short as possible (most modern filesystems keep short symlinks inside inodes and thus don't waste much disk space).

An additional bug I discovered while composing this post: I'm on drive E:\ , and I go to the E:\Users\All Users directory by navigating from the E:\Users directory using TC. The URL reads E:\Users\All Users, but the content is actually from C:\ProgramData . So, If I make changes to the files in E:\Users\All Users I actually modify files in C:\ProgramData. This is wrong.

There are some ways to fix this.
- The most simple: display the link/junction target in the folder list, just like dir /a, for example "All Users [C:\ProgramData]". This way I will be aware that by following that link I will end up on a different drive.
and/or
- Display C:\ProgramData in the address bar and change the the drive letter to C:\ after following the link (the address bar change seems to work if the link and the target are on the boot drive and created by windows on install, not by me, the same inconsistent behaviour as above, suggesting hardcoding of some kind)
and/or
- Display a warning when attempting navigation to the target folder.

And since I'm here, I really want a 64 bit version. Not because it's cool, but because 32 bit applications do not see the real filesystem, causing further problems. I see you fixed the system32/drivers/etc/hosts issue, but this is just trying to avoid the inevitable in my opinion.

Thanks.