Long UNC path not working in CMD.EXE on remote machine

[Technext]

Hi,


I am trying to connect to a remote server using Plink tool. Both my local and remote machines are Windows. On remote server, I have OpenSSH server installed. I am able to run commands on remote machine but there is some problem with long UNC path, which I noticed today.

For example,
Working:

Plink -ssh -pw xxx user@server cmd.exe /c copy //test//somedir//inside//some.exe //test//another//

Not Working:

Plink -ssh -pw xxx user@server cmd.exe /c copy //test//somedir//inside//more//prog.exe //test//another//

When I did echo to see how it's interpreting the command, I saw the following output:
.....//test//somedir//inside//mo //test//another//

As you can see above, it's not working if the sub-directory level increases above 2. It just prints the first two characters of the third directory (here 'mo' for directory name 'more').


This doesn't look like the 8-character DOS issue because the real path that I am using has the first directory containing 11 characters. I am not sure whether it's a limitation of Plink tool or command shell or something else.

By the way, my script takes the UNC path as input from the user. It can contain any no. of sub-directory levels. I think it should not exceed more than 8-9 levels in any normal case but it'll be better if the solution works for any arbitrary levels.

I have thought of mapping the UNC path to some drive letter but I want to explore some other alternative (short & sweet). I think, implementing mapping might involve a good deal of work.

Can anyone suggest a way to overcome this problem?


Thanks,
GC

[Deenanath]

Well if you are asking me then I guess CMD.exe doesn't support UNC paths and the simplest way to get around it would be mountVol. I haven’t tried the same thing for any network drive so I am not sure that it will really work for of those but still want you to give it a try.