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

Advertisement

acem77
Joined:
Posts:
20
Location:
usa

“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

Reply with quote

Advertisement

martin
Site Admin
martin avatar
Joined:
Posts:
40,430
Location:
Prague, Czechia

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.

Reply with quote

acem77
Joined:
Posts:
20
Location:
usa

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.
  • WinSCP0DBCtrace.zip (1.83 MB, Private file)
Description: log of transfer, no errors . unable to reproduce with debug winscp

Reply with quote

acem77
Joined:
Posts:
20
Location:
usa

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?

Reply with quote

Advertisement

martin
Site Admin
martin avatar
Joined:
Posts:
40,430
Location:
Prague, Czechia

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.

Reply with quote

acem77
Joined:
Posts:
20
Location:
usa

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

Reply with quote

martin
Site Admin
martin avatar
Joined:
Posts:
40,430
Location:
Prague, Czechia

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?

Reply with quote

Advertisement

acem77
Joined:
Posts:
20
Location:
usa

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.

Reply with quote

martin
Site Admin
martin avatar

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

Reply with quote

acem77
Joined:
Posts:
20
Location:
usa

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

Reply with quote

martin
Site Admin
martin avatar

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.

Reply with quote

Advertisement

acem77
Joined:
Posts:
20
Location:
usa

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.

Reply with quote

Guest

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

Reply with quote

martin
Site Admin
martin avatar
Joined:
Posts:
40,430
Location:
Prague, Czechia

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.

Reply with quote

Advertisement

Advertisement

You can post new topics in this forum