WAD MKLINK CMD compatibility, MKLINK /X

[Stefano Piccardi]

I noticed two new issues:
1) TCC MKLINK targets absolute file paths vs CMD which targets relative file paths, when given
2) MKLINK /X (not in CMD) fails with "the directory name is invalid" when asked to delete a file symlink.
You will notice those issues by comparing the two console logs below - first one is CMD's.
OT: is there a way to post a code/quote blocks within a spoiler?

C:\test2>cmd
Microsoft Windows [Version 6.1.7601]
Copyright (c) 2010 Microsoft Corporation. All rights reserved.

C:\test2> echo.>file

C:\test2> mkdir folder

C:\test2> mklink flink file
symbolic link created for flink <<===>> file

C:\test2> mklink /D dlink folder
symbolic link created for dlink <<===>> folder

C:\test2> mklink notflink notfile
symbolic link created for notflink <<===>> notfile

C:\test2> mklink /D notdlink notfolder
symbolic link created for notdlink <<===>> notfolder

C:\test2> mklink flinkrel ..\test2\file
symbolic link created for flinkrel <<===>> ..\test2\file

C:\test2>dir
Volume in drive C has no label.
Volume Serial Number is 50A9-A297

Directory of C:\test2

12/30/2011 05:59 PM <DIR> .
12/30/2011 05:59 PM <DIR> ..
12/30/2011 05:59 PM <SYMLINKD> dlink [folder]
12/30/2011 05:58 PM 2 file
12/30/2011 05:58 PM <SYMLINK> flink [file]
12/30/2011 05:58 PM <SYMLINK> flinkrel [..\test2\file]
12/30/2011 05:58 PM <DIR> folder
12/30/2011 05:59 PM <SYMLINKD> notdlink [notfolder]
12/30/2011 05:59 PM <SYMLINK> notflink [notfile]
3 File(s) 2 bytes
5 Dir(s) 63,138,361,344 bytes free

C:\test2>del dlink
C:\test2\dlink\*, Are you sure (Y/N)? N

C:\test2>rmdir dlink

C:\test2>del flink

C:\test2>del flinkrel

C:\test2>rmdir notdlink

C:\test2>del notflink

C:\test2>dir
Volume in drive C has no label.
Volume Serial Number is 50A9-A297

Directory of C:\test2

12/30/2011 06:12 PM <DIR> .
12/30/2011 06:12 PM <DIR> ..
12/30/2011 05:58 PM 2 file
12/30/2011 05:58 PM <DIR> folder
1 File(s) 2 bytes
  3 Dir(s) 63,138,349,056 bytes free

C:\test>ver

TCC LE 13.03.36 Windows 7 [Version 6.1.7601]

C:\test> >file

C:\test> mkdir folder

C:\test> mklink flink file
Symbolic link created for flink <<===>> C:\test\file

C:\test> mklink /D dlink folder
Symbolic link created for dlink <<===>> folder

C:\test> mklink flinkrel ..\test\flink
Symbolic link created for flinkrel <<===>> C:\test\file

C:\test> mklink notflink notfile
Symbolic link created for notflink <<===>> C:\test\notfile

C:\test>mklink /D notdlink notfolder
Symbolic link created for notdlink <<===>> notfolder

C:\test>dir

Volume in drive C is unlabeled Serial number is 50a9:a297
Directory of C:\test\*

12/30/2011 17:55 <DIR> .
12/30/2011 17:55 <DIR> ..
12/30/2011 17:52 <SYMLINKD> dlink [folder]
12/30/2011 17:27 <DIR> folder
12/30/2011 17:55 <SYMLINKD> notdlink [notfolder]
12/30/2011 17:27 0 file
12/30/2011 17:55 <SYMLINK> flink [C:\test\file]
12/30/2011 17:55 <SYMLINK> flinkrel [C:\test\file]
12/30/2011 17:55 <SYMLINK> notflink [C:\test\notfile]
0 bytes in 3 files and 5 dirs
63,138,361,344 bytes free

C:\test>del dlink
C:\test\dlink\* : Are you sure (Y/N)? N
0 files deleted

C:\test>rmdir dlink

C:\test>del flink
Deleting C:\test\flink
1 file deleted

C:\test>del flinkrel
Deleting C:\test\flinkrel
1 file deleted

C:\test>rmdir notdlink

C:\test>del notflink
Deleting C:\test\notflink
1 file deleted

C:\test>dir

Volume in drive C is unlabeled Serial number is 50a9:a297
Directory of C:\test\*

12/30/2011 18:13 <DIR> .
12/30/2011 18:13 <DIR> ..
12/30/2011 17:27 <DIR> folder
12/30/2011 17:27 0 file
0 bytes in 1 file and 3 dirs
63,138,349,056 bytes free

C:\test>mklink flink file
Symbolic link created for flink <<===>> C:\test\file

C:\test>mklink /D dlink folder
Symbolic link created for dlink <<===>> folder

C:\test>mklink flinkrel ..\test\flink
Symbolic link created for flinkrel <<===>> C:\test\flink

C:\test>mklink notflink notfile
Symbolic link created for notflink <<===>> C:\test\notfile

C:\test>mklink /D notdlink notfolder
Symbolic link created for notdlink <<===>> notfolder

C:\test>mklink /X flink
TCC: (Sys) The directory name is invalid.
"flink"

C:\test>mklink /X dlink

C:\test>mklink /X flinkrel
TCC: (Sys) The directory name is invalid.
"flinkrel"

C:\test>mklink /X notflink
TCC: (Sys) The directory name is invalid.
"notflink"

C:\test>mklink /X notdlink

C:\test>dir

Volume in drive C is unlabeled Serial number is 50a9:a297
Directory of C:\test\*

12/30/2011 18:17 <DIR> .
12/30/2011 18:17 <DIR> ..
12/30/2011 17:27 <DIR> folder
12/30/2011 17:27 0 file
12/30/2011 18:15 <SYMLINK> flink [C:\test\file]
12/30/2011 18:15 <SYMLINK> flinkrel [C:\test\flink]
12/30/2011 18:15 <SYMLINK> notflink [C:\test\notfile]
0 bytes in 4 files and 3 dirs
63,138,349,056 bytes free

 

[rconn]

2) MKLINK /X (not in CMD) fails with "the directory name is invalid" when asked to delete a file symlink.

WAD -- as the help specifically says, /X only deletes directory links.

Why do you think this is a TCC bug?

 

[rconn]

I noticed two new issues:
1) TCC MKLINK targets absolute file paths vs CMD which targets relative file paths, when given

WAD -- this is a feature.

TCC will use relative paths for creating directory links, but nobody has ever come up with a reason why you would want relative file links. TCC expands the filename so you can see what you're really getting (frequently different from what you think you're doing!).

 

[Stefano Piccardi]

WAD -- as the help specifically says, /X only deletes directory links.

Why do you think this is a TCC bug?

My bad, I didn't read the help entry attentively enough.

 

[Stefano Piccardi]

WAD -- this is a feature.

TCC will use relative paths for creating directory links, but nobody has ever come up with a reason why you would want relative file links. TCC expands the filename so you can see what you're really getting (frequently different from what you think you're doing!).

Rex, if saving the user from himself is your reason for making this feature of MKLINK incompatible with CMD, then I think you could do better; go ahead and show feedback with the fully expanded filepath, but please create a relative file link as CMD does! That way you'll be helpful without breaking compatibility.
Relative file symlinks are supported in *nix and Microsoft Windows (including CMD). Those software engineers must have had good reasons to design this feature this way, I think. Why do you need a supporting case to follow in their steps?

 

[David Marcus]

I think Unix sometimes uses relative file links so the same executable can be run using different names and it will behave differently depending on which name was used. At least, I think these were relative links; it has been a while since I ran into this. I always thought it a bit confusing to have the behavior depend on the name.

 

[Stefano Piccardi]

Good example, thanks David. A similar practice taken from linux involves dlls; a "package" may install different versions of a command in a single folder, with different executables which dynamically link the same dll - under different symbolic names - from the executable folder.
Two advantages of relative file symlinks, in this case: 1) you don't need to change the dll links after the package gets installled; 2) unlike file hardlinks, file symlinks are self-documenting (ls tells you where they point to).