0

Sorry for reformatting my question by focusing on the real issue as follows: 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).

The following code should do the task:

package main

import (
    "bufio"
    "fmt"
    "os"
)

func main() {
    //The following is the file name on a network mapped drive H:
    out, errc := os.OpenFile("H:/00_SC/Dest01.txt", os.O_CREATE|os.O_APPEND|os.O_RDWR, 0666)
    if errc != nil {
        fmt.Println("Error Creating/Wrting to Dest file :", errc)
    }
    defer out.Close()
    wr := bufio.NewWriter(out)
    mystring := "another line here"
    d, err := wr.WriteString(mystring)
    if err != nil {
        fmt.Println("Error writing by Writer: ", err)
    }

    errflush := wr.Flush()
    if errflush != nil {
        fmt.Println("Error Flushing the write to file", errflush)
    }

    wrtd, errw := out.Write([]byte("Write something in the file"))
    if errw != nil {
        fmt.Println("Error of Writte call", errw)
    }

    fmt.Println("Length of mystring = ", len(mystring))
    fmt.Println("Bytes written to buffer = ", d)
    fd, errf := fmt.Fprintf(out, "Another line to the file using Fprintf %d", d)
    if errf != nil {
        fmt.Println("Fprintf Error: ", errf)
    }
    fmt.Println("Bytes written to file by Fprintf = ", fd)
    fmt.Println("Bytes written to file using Write", wrtd)
}

The file was created successfully, however, neither of the methods used write to it. Bufio.WriteString neither write nor return an error !! Fprintf failed with unclear error message which I searched and could not find a meaning or reason.

Here the output I got when running the compiled file:

Error Flushing the write to file write H:/00_SC/Dest01.txt: The parameter is incorrect.
Error of Write call write H:/00_SC/Dest01.txt: The parameter is incorrect.
Length of mystring =  17
Bytes writen to buffer =  17
Fprintf Error:  write H:/00_SC/Dest01.txt: The parameter is incorrect.
Bytes written to file by Fprintf =  0
Bytes written to file using Write 0

I would appreciate your help and guidance finding the cause of this error. Thanks

helhadad
  • 21
  • 7
  • 2
    «Bufio.WriteString neither write nor return an error !!» that's because "buf" in "bufio" means "buffered", and any methods on `bufio.Writer` are free to buffer whatever is written through them and dump to the underlying writer however they see fit. If you were to check the error returned from `wr.Flush()`—as required by the `bufio.Writer` contract—you'd most probably get the error earlier. – kostix Sep 18 '20 at 17:22
  • 2
    So an [MCVE](https://stackoverflow.com/help/minimal-reproducible-example) should not attempt to use neither `bufio` nor `fmt` on the `*os.File` obtained by the call to `os.CreateFile` but rather should just call `Write` on it and see which error will be returned, if any. Could you please do just that so we could weed irrelevant stuff out? – kostix Sep 18 '20 at 17:24
  • 2
    [Previous question](https://stackoverflow.com/questions/63937566/) about the same matters. – kostix Sep 18 '20 at 17:26
  • @kostix thanks a lot for your detailed advice, I have added an error detection for flush and as you expected generates the same error message "The parameter is incorrect". I will reformat the code to use ```write``` – helhadad Sep 18 '20 at 17:39
  • 2
    You should also close the file. – icza Sep 18 '20 at 17:42
  • @kostix I have added this line of code ``` wrtd, errw := out.Write([]byte("Write something in the file")) if errw != nil { fmt.Println("Error of Writte call", errw) } ``` and I got the same error I got before ``` Error of Write call write H:/00_SC/Dest01.txt: The parameter is incorrect. ``` What else I can do to figure out the root cause of this incorrect parameter!! – helhadad Sep 18 '20 at 17:51
  • @icza thanks for the note, I added in the updated code. – helhadad Sep 18 '20 at 17:54
  • 1
    helhadad, that was completely expected. We'll now try to deal with the problem. @icza, do you have enough permissions to convert this wall of comments to a chat right away? – kostix Sep 18 '20 at 17:56
  • @kostix Unfortunately no. – icza Sep 18 '20 at 18:02
  • @kostix, thanks a lot, your support is much appreciated. – helhadad Sep 18 '20 at 18:03
  • @helhadad, now please try to log the error using something like `fmt.Printf("%T, %#v\n", err, err)` and post what it prints. And by the way, are you able to edit your own question (I mean, do you have enough SO permissions to do that)? – kostix Sep 18 '20 at 18:31
  • Does the folder (`H:/00SC`) exist? Do you have write permission there? Are you running the app with the same user you tried and succeeded writing files? Does the file already exists, maybe with insufficient permissions to change? Does this same app succeed if you change the path and file to your user home folder (where you do have every permission)? – icza Sep 18 '20 at 18:49
  • @icza, Yes, the folder exists and accessible by the same user name and also I examined it using simple dos copy command to copy from the same location of my program to the same destination path. Yes, the same app succeeded when I use on the local machine using any path on the same machine. The issue appeared only when using the networked mapped folder ```H:```. – helhadad Sep 19 '20 at 15:54
  • @kostix, I will do once I log on back to the RDP. Yes, I believe I can edit my question, let me know if you want me to rephrase any part. Thanks. – helhadad Sep 19 '20 at 15:55
  • @helhadad, honestly, the phrasing in your answer to the icza's comment is a bit strange. When you "used the dos compy command", do you mean you first mapped that same CIFS chare to the same drive letter H using the `net use` command (or Windows Explorer)? Or did you use the full network share path like \\COMPUTERNAME\SHARENAME\path\to\file`? – kostix Sep 19 '20 at 16:31
  • @kostix, I used net use with \\tsclient\, I cannot access the full path. The structure is a bit complicated, as the folder is shared in a server which is not directly connected to the server I am using to access this folder. It is different hops of RDPs but the shared folder can be reached by windows explorer and cmd.exe. Do you think, it may be some limitations on the network or firewalls. – helhadad Sep 20 '20 at 12:23
  • @kostix, I have rewrite the error print statement as you advised and the following was the detail of the error ```Error of Write call = *os.PathError &os.PathError{Op:"write", Path:"H:/00_SC/Dest01.txt", Err:0x57}```. I have tried to search for the error 0x57 but could not find a definition. If there is an Error with Path, how is the file was created from the beginning. – helhadad Sep 21 '20 at 07:15
  • @helhadad, that's «ERROR_INVALID_PARAMETER — 87 (0x57) — The parameter is incorrect.» — see [this](https://learn.microsoft.com/en-us/windows/win32/debug/system-error-codes--0-499-). Unfortunately, this brings us back to square one as I had hoped to have an error of the type other than `*os.PathError`. – kostix Sep 21 '20 at 09:14
  • The comment to [this answer](https://stackoverflow.com/a/3531839/720999) mentions forward slashed did not work for the asker. Does the invocation works if you use `os.OpenFile("H:\\00_SC\\Dest01.txt", …`? – kostix Sep 21 '20 at 09:17
  • As expected change in folder separator does not impact the writing issue, as the file was created successfully without errors. ```Error of Write call = *os.PathError &os.PathError{Op:"write", Path:"H:\\00_SC\\Dest01.txt", Err:0x57}``` ```Error of Write call = *os.PathError &os.PathError{Op:"write", Path:"H://00_SC//Dest01.txt", Err:0x57}``` – helhadad Sep 21 '20 at 13:38
  • What? Doubled forward slashes? Did you really see them in the error message? – kostix Sep 21 '20 at 14:14
  • @kostic, yes they appeared back as output. As I understand the issue now, it seems like I have to set overlap offset and offset high to "0". Unfortunately, this is not available by ```os``` functions and methods, and I need to figure out how to handle everything again using ```syscall```. – helhadad Sep 21 '20 at 16:41
  • To me, doubled forward slashes on output look like a hunch that something is awry. I have no idea whether this is with your code or in the Go's stdlib or somewhere else. But I'm afraid we've already pushed the abilities of SO's comment walls to its limits. I highly recommend you to post a message to [the mailing list](https://groups.google.com/forum/#!forum/golang-nuts), describe the problem, highlight this bit about `//` in the error message and provide link to this question. At least the ML is read by the Go core devs (they are not on SO). – kostix Sep 21 '20 at 20:13
  • I have no trouble using the code in the post and it seems to work on a local network drive. Out of curiosity, could you try and sleep for half a second after opening the file (but before writing anything to it)? I'd also recommend rewriting in in c (and using the equivalent Winapi functions CreateFile / WriteFile), just to ensure its an issue with the Network or with GO. – Make that 4 Sep 22 '20 at 09:18
  • Another option is to use some tool (from Sysinternals, IMSMR) which works like `strace` on *nix systems—by tracing the syscalls the code running in a process performs. This way, we could see which Win32 API call fails, and with which arguments it was called. – kostix Sep 22 '20 at 11:03
  • @kostix, @icza, Gents, I believe if I use the ```/x/sys/windows```, I can set the required offset to 0, but I could not find any example of how to use such lower level functions, specially ```WriteFile(handle Handle, buf []byte, done *uint32, overlapped *Overlapped) (err error)```, I would appreciate if you have any material I could use to call the function properly. Thanks – helhadad Sep 23 '20 at 17:18
  • I'd reaffirm my suggestion to move the discussion to the mailing list: I'd say we need help from folks like Alex Brainman (who almost single-handedly did the Windows port of Go back then, and maintains it do this day AFAIK). The Go devs do not monitor the `go` tag on SO, and I'm afraid I, for one, have sort of exhausted my psychic debugging capabilities on this case, and the format of SO comments is one of the worst things possible to solve such cases, really. – kostix Sep 24 '20 at 09:49
  • 1
    @kostix, Thanks for your help and guidance. I already opened the same case on go-nuts google group. If you would like to add more comments there, I would appreciate it. – helhadad Sep 24 '20 at 12:38
  • Have just chimed in there, Cc-ing Alex Brainman. – kostix Sep 24 '20 at 14:33

0 Answers0