TC creates corrupted .lnk files when the path is too long

[umbra]

When you use "cm_CreateShortcut" to create some shortcut to a file with very long target path (over 259), TC creates the shortcut with no error dialog. BUT - the shortcut is corrupted and not useful at all.

[ghisler(Author)]

I think that it's a bug in the link API. I will probably have to refuse the creation of such links...

[Lefteous]

As the IShellLink::GetPath is limited to MAX_PATH it might not be a good idea to try to create LNK files which point to longer paths names.

[umbra]

That's fine by me. Such long paths are not very common anyway.

However, Windows in such cases tries to use short names of files and folders in the path, which often helps. Maybe it wouldn't be too hard to implement it in TC as well.

[leopoldus]

2ghisler(Author)
Just to avoid any misunderstanding (and regarding, that you have not yet commented any way my bug report in the previous topic http://ghisler.ch/board/viewtopic.php?t=36503 ) I'd like to stress, that I considered another issue there. The difference is, that my bug report regarded the situation, when the target file's full name is UNDER 259 symbols, but the shortcut LNK-file itself is over 259 symbols (in its current folder, but when it is moved to another location. the length of its full name may reduce under 259 symbols).

[ghisler(Author)]

The problem is that most of these Windows functions are limited to 259 characters. I will problably not be able to do much more than show an error message.

[leopoldus]

2ghisler(Author)

that most of these Windows functions are limited to 259 characters

Yes, Windows can not properly handle shortcuts, which has the full name (path + name) longer than 259 symbols.

However there are at least two cases (may be some other too), when shortcuts with length over 259 symbols may be useful.

1) Total Commander could handle them regardless of OS API limitations. That is, pressing Ctrl+Left/Right/Up/Down or Ctrl+Shift+Left/Right/Up/Down could open the target folder of the parent folder of the target file at the next tab or pane. AFAIK, TC does it internally and it does not need to involve any API function to do it.

2) Say, a shortcut's own name length is 150 symbols and it is currently located in the folder with full path, say 150 symbols. Thus the full name of the shortcuts full name is 150 + 150 = 300 > over 259 symbols and OS can can handle it any way.
However it regards only in its current location of the shortcut. Later a user may move it to another folder, with the length, say, 100 symbols only - and in such event the full name of the shortcut will become only 150 + 100 = 250 < 259 symbols.

So instead of absolutely blocking creating shortcuts with current full name over 259 symbols TC could actually handle them the same was as any other file. That is, when the full name of the target file being created is over 259 symbols, TC should bring a standard warning message and give a user the option to decide himself, whether to keep the process or cancel the operation.

[leopoldus]

2ghisler(Author)
In addition to my previous post. You could at least consider adding some option to create a link-file in the source pane, that is in the same pane where the linked target files resides. This way you exclude at list that senseless situation, that a user is not able to create a short due to the fact, that the path to the folder in the target pane is currently too long.

BTW Windows does allow to create a shortcut in the current folder.