Thanks for your feedback.

So far the transfer looks to be good using powershell and WinSCPnet.dll 5.14.0.8780

acem77 wrote:

The odd thing is once I upload the dir and files with the L attribute using the dev version the standard version will work with no issues if I re-upload the same files after deleting everything from the original transfer. Seems something is cached between versions?

As I wrote before, the first call to GetFileAttributes fails and latter calls succeed. It's probably cached on system/session level, hence it's not the first call in a process, that fails, but the first call system-wide or session-wide.

Can you provided a new install version or the WinSCPnet.dll? I have been running this with a script to schedule the transfer.

Just replace Portable with Automation in the download URL.

Can you provided a new install version or the WinSCPnet.dll? I have been running this with a script to schedule the transfer.

Thanks for dev ver.
So far all my test with the development version of WinSCP are good.

The odd thing is once I upload the dir and files with the L attribute using the dev version the standard version will work with no issues if I re-upload the same files after deleting everything from the original transfer. Seems something is cached between versions?

After further research on my side it seems the reparse point files may have been create from commvault file archive / stubs.

Thanks. Though even with sch setup (symlink to a volume), I cannot reproduce the problem.

Anyway, I'm sending you an email with a development version of WinSCP to the address you have used to register on this forum. In that version, I've tried to workaround the problem.

symlink is involved,we have some drives mounted that may be on some other storage space,
no sure how it could be reproduced.

PS C:\Users\user1> Get-ChildItem "O:\" |select mode,target

Mode Target
---- ------
d-----
d----l {Volume{3a34cc2d-bde1-47c1-8887-fb1f1638b05a}\}
d----l {Volume{178e704a-8e7b-4eca-8acc-86a6c56c564a}\}
d----l {Volume{718d54a7-15cb-4f89-8e68-768cbde52adc}\}

Can you actually confirm, that there's a symlink involved? Can you show us how to recreate a directory structure that reproduce the problem?

martin wrote:

acem77 wrote:

test with and fails, tested with unc and a mapped drive
server 2008
server 2012 r2
server 2016
windows 10

I'm not sure I understand, what have you tested. Do you mean that you get the same problem for all these systems, both when using an UNC path and when using a mapped drive?

Correct, each OS listed generates the same error, while trying to transfer from a unc path or a mapped path.

acem77 wrote:

test with and fails, tested with unc and a mapped drive
server 2008
server 2012 r2
server 2016
windows 10

I'm not sure I understand, what have you tested. Do you mean that you get the same problem for all these systems, both when using an UNC path and when using a mapped drive?

test with and fails, tested with unc and a mapped drive
server 2008
server 2012 r2
server 2016
windows 10

this is what is being checked (last write time / last modified) https://stackoverflow.com/questions/19774097/finding-modified-date-of-a-file-folder

other link I was looking at to try to understand how this all works.
https://devblogs.microsoft.com/oldnewthing/?p=24713

I was able to transfer with another ftp client with no errors, Any guess on what my be done different?

That other client probably does not use GetFileAttributes.

Do you know if I can validate the issue with something like powershell to test what MS OS may have the same issue, my next step was to use another OS.

Thanks

acem77 wrote:

I was able to send with no errors using debug client you sent.
what is difference between the debug and the install client and standalone version?

To collect debugging information, the debug build calls GetFileAttributes before an actual transfer code starts. That call fails (silently). And the next call (very same one) from the transfer code succeeds. While in the normal build, the call in the transfer code is the first one, so it fails.

I was able to transfer with another ftp client with no errors, Any guess on what my be done different?

That other client probably does not use GetFileAttributes.

I was able to send with no errors using debug client you sent.
what is difference between the debug and the install client and standalone version?
I am running from server 2012 r2
I was able to transfer with another ftp client with no errors, Any guess on what my be done different?

OK, this is a known issue in Windows, that we've seen before already:
https://winscp.net/tracker/1355
I do not think it's a problem of WinSCP.

I am not able to produce the same error with the debug client you sent, it seems the bug is not in that build?
I still have the issue with both the install and standalone ver. 5.13.3 (8565)

I have attached the log.

Thanks for your report.
I have sent you an email with a debug version of WinSCP to the address you have used to register on this forum.

Hello,
I am trying to user winscp with PowerShell to automate the process.

It seems to be related to how some file types are nested, if they are part of a sub dir I’ll get the error. If I upload the files from the root they will send,
this happens with running the script or manually uploading the files. When in the gui I can click retry once and it sends.

Upload of \\dirxyz\vslistener.v2.log failed: WinSCP.SessionRemoteException: File or folder '\\dirxyz\vslistener.v2.log' does not exist.
System Error. Code: 4390. The file or directory is not a reparse point

side note, if I transfer the same dir a 2nd or more times with out disconnecting
the transfer will start and finish with no errors.


As a test to see if it was OS related or the receiving ftp server I tried another ftp client with no issues.

thanks