Windows Write Call Error when Writing to Network mapped Folder.

[helhadad]

Hi Folks,
I am trying to create file and write to it on a network mapped drive, which I can access, create, delete and edit files using windows explorer or CMD (Windows 10/Server 2016).  

You can find all details of the issue and response from other Go-Expert below:

https://stackoverflow.com/questions/63960049/writing-to-networked-mapped-drive-empty-files-or-failure

I would appreciate if you enlighten me about the issue and how to solve it.

Regards,
helhadad.

[Ian Lance Taylor]

According to Stack Overflow you are getting errors that say "the
parameter is incorrect." If I search for "Windows the parameter is
incorrect" all the top links are about reformatting the disk. So
perhaps you should give that a try.

Ian

[Hesham Elhadad]

Thanks Ian, 

The root cause of this issue is not the hard drive, it is something with overlapped offset and high offset values, need to be set to 0 to have a smooth APPEND to the file.

I need to use /x/sys/windows package to call this function WriteFile(handle Handle, buf []byte, done *uint32, overlapped *Overlapped) (err error).
However, there is neither examples nor clarification on how to use or call the function. Also, most of the function in this package using *int16/*int32 for file names which is not clear to me if I want to use a string file name.

Appreciate any support you can provide, or guidance on a material which could help.

Regards,

helhada

[jake...@gmail.com]

On Wednesday, September 23, 2020 at 1:26:10 PM UTC-4 helhadad wrote:

Thanks Ian, 

The root cause of this issue is not the hard drive, it is something with overlapped offset and high offset values, need to be set to 0 to have a smooth APPEND to the file.

I need to use /x/sys/windows package to call this function WriteFile(handle Handle, buf []byte, done *uint32, overlapped *Overlapped) (err error).
However, there is neither examples nor clarification on how to use or call the function.

Less than Ideal, but you could look at how others use it: https://github.com/search?l=Go&q=%22windows.WriteFile%22&type=Code

[Ian Lance Taylor]

On Wed, Sep 23, 2020 at 10:25 AM Hesham Elhadad <helh...@gmail.com> wrote:
>
> Thanks Ian,
> The root cause of this issue is not the hard drive, it is something with overlapped offset and high offset values, need to be set to 0 to have a smooth APPEND to the file.
> I need to use /x/sys/windows package to call this function WriteFile(handle Handle, buf []byte, done *uint32, overlapped *Overlapped) (err error).
> However, there is neither examples nor clarification on how to use or call the function. Also, most of the function in this package using *int16/*int32 for file names which is not clear to me if I want to use a string file name.
> Appreciate any support you can provide, or guidance on a material which could help.

Given a *os.File f that you can get using os.OpenFile, you can use
f.SyscallConn to get a syscall.RawConn rc, and you can call rc.Write
with a function literal that calls unix.WriteFile with the handle.

Ian

[Konstantin Khomoutov]

On Tue, Sep 22, 2020 at 10:56:43AM -0700, helhadad wrote:

> Hi Folks,

> I am trying to create file and write to it on a *network mapped drive*,

> which I can access, create, delete and edit files using windows explorer or
> CMD (Windows 10/Server 2016).
>
> You can find all details of the issue and response from other Go-Expert
> below:
>
> https://stackoverflow.com/questions/63960049/writing-to-networked-mapped-drive-empty-files-or-failure
>
> I would appreciate if you enlighten me about the issue and how to solve it.

I would in particular highlight one weirdness discovered in [1]:
when the OP did use forward slashes in their call to os.OpenFile,
the error message read

&os.PathError{Op:"write", Path:"H://00_SC//Dest01.txt", Err:0x57}

that is, every forward slash in the input has been doubled.

Another issue I can't fully grasp is why creating of the file goes well,
and the error is only returned on the first call to Write on the returned
file handle? Some folks suggested special dances are required in order to
properly open a file on such a network share but this does not explain why
plain commands like `copy` work in a cmd.exe session with that same resource
attached by the `net use` command.

(Kindly looking for soliciting any insight from Alex Brainman.)

Is there a way to trace what happens on the system call level?

1. https://stackoverflow.com/questions/63960049#comment113160125_63960049