WinSCP's installer optionally creates a helpful shortcut to
"C:\Program Files\WinSCP3\WinSCP3.exe" /upload

That's normally fine, but under non-NT-based MSWins (namely, MSWin98 and MSWinME, but not XP), the semantics of shortcuts are very strange. Basically, when you a SendTo shortcut is executed via a normal explorer "Send To:" submenu, the options are ignored. So on my Win98 machine, when I try "SendTo"ing a file to winscp (via the normally created shortcut), what gets executed is this:

"C:\Program Files\WinSCP3\WinSCP3.exe" path-to-that-file

instead of what you'd expect (and what actually happens on my XP machine), namely:

"C:\Program Files\WinSCP3\WinSCP3.exe" /upload path-to-that-file

But that's not all! What non-NT MSWins pass as the pathname is not the normal long name, but the 8.3 pathname. So when I try sending the file "C:\WINDOWS\Desktop\InsertSymbol.gif", the command line is:

"C:\Program Files\WinSCP3\WinSCP3.exe" C:\WINDOWS\DESKTOP\INSERT~1.GIF

So, in the end, selecting right-click Send-To SCP on that file simply makes WinSCP complain "Session named 'C:\WINDOWS\DESKTOP\INSERT~1.GIF' does not exists."



My workaround for this is to change the shortcut to be to a c:\utils\winscpul.bat, and to have that file consist of:
@echo off
perl -e "exec q{C:\Program Files\WinSCP3\WinSCP3.exe}, q{/upload}, chr(34).Win32::GetLongPathName($ARGV[0]).chr(34)" %1

That call to Perl is basically there just to turn the shortname into the longname. If not for that, I would haved done:
@echo off
"C:\Program Files\WinSCP3\WinSCP3.exe" /upload %1

I think the simplest workaround for implementations' sake is for future versions of winscp to have a little executable called, say, winscpul.exe, that simply converts its parameter from a shortname to a longname, and then calls winscp3.exe /option on it.


By the way, WinSCP is not the first program to run into this problem:
https://lists.gnu.org/archive/html/help-emacs-windows/2002-04/msg00084.html