Justalearner wrote:

I observe few strange issues with WinSCP(version 5.1.6.0). As a background we are using WinSCP for around 3 years now and never faced these issues before. Kindly provide your valuable suggestion.

Why did you put your problem in this thread? I do not see any relation. Please start a new thread.
Can you reproduce the problem with the latest version of WinSCP?

Hi,
Again one more observation. Strange though.

Server X has mapped network path Z (\\serverY\XXXX TempFiles\)
Now using command prompt from ServerX if I navigate to Z drive and type WinSCP.com in the prompt "Error retrieving product version" error message is coming.Please check the file named cmderror.jpg.

Please provide your feedback.

Hi,
I observe few strange issues with WinSCP(version 5.1.6.0). As a background we are using WinSCP for around 3 years now and never faced these issues before. Kindly provide your valuable suggestion.

Issue 1
---------
We have a SSIS package which is installed in a server say serverX. The package contains a Execute Process component which calls the WinSCP.com file stored in ServerY. Please check attached winscp.jpg
This setup was working perfectly for past 3 years and few days back it broke. I am breaking my head but no solution found yet.
As per the integration services catalog below is the error message
------------------------------
Execute Process Task:Error: In Executing "\\ServerY\XXXX TempFiles\WinSCP.com" "/script="Invoices.txt" /log="WinSCP.log"" at "\\ServerY\XXXX TempFiles", The process exit code was "2" while the expected was "0".
------------------------------

Issue 2
-------------

I have a mapped network drive Z which is mapped to \\ServerY\XXXX TempFiles.
Now from serverX if I just go to the network UNC path \\ServerY\XXXX TempFiles and double click the WinSCP.exe file I get a error message. Please look into attachment UNC_ERROR.jpg attached.

On the other hand if I just open the mapped drive and then double click the WinSCP.exe, the UI opens up nicely.
Is not this a strangest behavior? We are actually accessing same path from same ServerX.


Kindly provide your valuable feedback. Trust me this is how winSCP is behaving.

Yesss please help!

bump for support

I needed to move files from a UNC path to a nfs path mounted on a linux server. I used the symlink solution, but that made this a pretty clumsy process. I ended up switching to FileZilla which supports UNC paths out of the box. I didn't know about dragging from an explorer window into winscp, but that is still a bit of a kludge.

Both apps support sftp, which is what we have enabled on linux, so ease of use wins it for filezila in my case.

This product is a great product.

However, by issuing the dialog box "UNC paths are not supported" in the browse window, you have communicated to the users the message that the entire product does not support UNC paths, which is untrue.

Clearly, since folks have been asking you for this feature for 10 years, it must not be a trivial feature to add.

How about this: Modify the message from "UNC paths are not supported" to "UNC paths are not supported in the browser. Consider drag-and-drop to Windows Explorer window.". This will communicate the scope of the issue, and a useful workaround.

It will also decrease the number of people asking for a feature that you have had on the "back burner" for a decade.

This workaround is great! Thanks Martin.

It would be a nice tip in documentation about UNC use.

I'd like to point out that there may be a nice workaround for this that most people don't know about. Instead of mounting a UNC path to a drive letter, you could just create a symbolic link (works in Vista and newer, NTFS required).



This way, you don't waste drive letters and needn't worry about mounting/dismounting. The link just works if the share is available. Of course, you still need to know all required UNC paths beforehand in order to create the links...

Note: You might have to adjust GPO settings to allow linking to/from remote drives.

Cheers
Martin

pklausner wrote:

Just got forced from XP to Windows 7. Now the beloved WinSCP does not work with the standard locations any more: Desktop, Documents, you name it. UNC path not supported...

How is this related to Windows 7? In Windows 7, these standard locations are by default still on the system drive.

Just got forced from XP to Windows 7. Now the beloved WinSCP does not work with the standard locations any more: Desktop, Documents, you name it. UNC path not supported...

I see above that it already can do individual files. Is browsing so much more difficult? What is the point w/o browsing?

Hi there Martin,

I have used your wonderful product for ten years now, and the only thing I still struggle with is not having UNC paths.

I had hoped that version 5 may have added this much anticipated feature, or that it would at least simplify the process for you to add UNC path support.

Please accept my vote for this much requested feature, and my small donation given in appreciation of your efforts on this worthwhile product.

I agree browse for UNC would be good. In my environment "my documents" on some PCs is UNC share. So if I create a saved sessions with synchronised browsing it doesn't work on such machines.

The option, to assign drive letters to unc resources is not a simple solution. While unc notations are always useable in a windows environment, network drive letter assignments are only possible if the smb/cifs (workstation & server service) are active and running. There are a plenty of reasons to deactivate smb, and also in that case, unc references are possible, but network drive letters no more.

Thus, one more big vote for unc support.

Thanks for winscp anycase.

simple solution - You can mount unc paths as network discs. They will work with winscp.

vote for......

Another vote for full UNC support in the app and not have to use Win Explorer.

Just wanted to add my vote for this feature! It is the single biggest (and only!) problem with WinSCP...

Hi All,

To day i too faced this issue where i need to access a remote share directory often.

But when i tried to issue command like \\10.0.15.77 it return UNC path's are not supported.

Then i got a thought why not we map this remote path to a Network Drive and use this to transfer files from WinScp.

And i got succeeded in this and successfully able to transfer files from remote machines to other remote machine which is opened in winscp.

We want this to very much

I would like to add a bump for this bug. It is important for my users to be able to browse UNC paths.

I would love to recommend this application to our operations group. However, without the ability to browse UNC paths, they will continue to use BlueZone.

I am waiting impatiently for this, too...

I hope this feature comes soon..

Chiming in as another who would like UNC.

We recently upgraded our domain controller and added in UNC folder redirection for our My Documents and Desktop items. It's good that I can drag and drop, but browsing would be nice too. ;)

I also would like to be able to browse UNC paths.

I just moved my development server from Windows to a Linux VPC with Samba and now I can't browse the folders anymore.

I hope this is not a big deal to add, since some basic UNC functionality is already implemented...

Hello prikryl,

thank you for your answer!

This issue has been added to tracker.

Hello prikryl,

can you tell me how to transfer files using UNC paths?

Thanks.

martin wrote:

What do you mean exactly by support? WinSCP supports transferring files to/from UNC folders. It just cannot browse them.

Up to now I just want to browse the directory (shortcut CTRL-O), getting the alert popup "UNC paths are not supported". Obviously, this is what you meant with browsing which I am primarily interested in. Nevertheless, I'd be glad to know how to transfer files using UNC paths.

sj-ts wrote:

Just wanted to ask whether there are further plans to add support for UNC within WinSCP. Sadly this feature isn't implemented yet.

What do you mean exactly by support? WinSCP supports transferring files to/from UNC folders. It just cannot browse them.

Just wanted to ask whether there are further plans to add support for UNC within WinSCP. Sadly this feature isn't implemented yet.

Thanks for your answers.

martin wrote:

I'll try to add UNC support soon.

Many thanks!

If you need beta testing or bug reproduction or any other sorts of help implementing that feature I'm happy to help -- pspencer AT fields.utoronto.ca. (If this were a linux/unix program I'd be willing to help write/suggest patches but, alas, I don't normally do Windows software development so I don't have Borland or any of the other resources I'd need to help in that way.)

Thanks again.

I'll try to add UNC support soon.

Thanks for a great product; such an open-source graphical front-end to ssh is very much needed and very much appreciated.

I just wanted to add my voice to those requesting UNC support. The reason is that in our environment every user-accessible directory is stored on a remote server (so people can seamlessly migrate from machine to machine). In particular, the desktop and "My Documents" folders are redirected to the server.

This means people cannot even drag and drop from the WinSCP Explorer-style window to their desktop (though they can drag and drop in the other direction from their desktop to the WinSCP window), since the desktop's path appears as \\PCSERVER\Home$\username\Desktop when they drag and drop.

If UNC support is too difficult to implement right now, might it be possible to implement a table of file path substitutions? E.g., where you could tell WinSCP "any time you see a path beginning \\PCSERVER\Home$\username, silently replace that part with Z:"?

Then our users would be able to drag and drop to the desktop even without UNC support in WinSCP, just by having the drive letter mapped and the appropriate translation entered into WinSCP. Right now they have to do that substitution manually, by editing the path in the "Copy to..." window each time they drag and drop.

Thanks for considering it!

P.S. I unfortunately don't have a Windows compilation environment :(, or I'd suggest and test some patches.