Post a reply

Before posting, please read how to report bug or request support effectively.

Bug reports without an attached log file are usually useless.

Options
Add an Attachment

If you do not want to add an Attachment to your Post, please leave the Fields blank.

(maximum 10 MB; please compress large files; only common media, archive, text and programming file formats are allowed)

Options

Topic review

martin

Thanks for your feedback.
acem77

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

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.
Guest

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

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.
martin

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.
acem77

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}\}
martin

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

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.
martin

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?
acem77

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
martin

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.
acem77

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?
martin

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.
acem77

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.
martin

Re: “System Error. Code: 4390. The file or directory is not a reparse point” File/folder does not exist

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.
acem77

“System Error. Code: 4390. The file or directory is not a reparse point” File/folder does not exist

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