Calc BASIC can’t append to network text file from Linux

Thanks to the discussion at Unable to load file on network from Linux I can now open CSV files on our Windows server as Calc documents, even from Linux. The key was using the ConvertToURL function, which changes the initial “file://” of a file path to “smb://”, so that Linux knows to use Samba to access the file.

But now I’m trying to do some simple file access to just append a few lines of text to a log file on the Windows server, and I am again having problems. You can see from that other page that I gave a basic example of reading from a text file. That still seems to work fine, whether you use “file://” or “smb://” at the beginning of the path. But if I try to open the file for Output or Append, I always get an error 57 Device I/O error on the open command. But that doesn’t happen if I am writing to a local file on the computer, just over the network. And it doesn’t happen if I open the file for Input to read from a file on the server.

Just to make it clear, here’s what works:

fileURL = "smb://"
Open fileURL For Input As #1
Line Input #1, sStr

This works if I put “file://” at the start as well, but I imagine smb is probably better, since it is required for the loadComponent call. This also works:

fileURL = "file:///home/user/Bureau/Reconcile.log"
Open fileURL For Append As #1
Print #1, "This is a test"

which is on the local machine, for Output or Append. But this fails with an error 57 on the Open call:

fileURL = "smb://"
Open fileURL For Append As #1
Print #1, "This is a test"

So the problem is just writing to the text file on the server. But I use the storeAsURL method to save .ods files to the server from Linux quite a lot, so there isn’t a networking or permissions problem. In fact when I run that Open/Append command with a fileURL of a file that does not exist, it actually creates the file on the server before giving the error.

Any suggestions?
(Linux Mint 16 French, LO Calc French)

I forgot to mention that all of these server accesses work fine from a Windows machine.

I upgraded LO to (latest stable for Linux Mint, I believe), and still have the problem.

I also tried shifting to using the SimpleFileAccess methods:

oFileAccess = CreateUnoService("")
oOutStream = oFileAccess.openFileWrite(sUrl)

But using those methods, when I try to openFileWrite it gives me an UnsupportedDataSinkException.

This appears to be a bug in LibreOffice which I am in the process of reporting here:

I found a work-around, but it’s pretty ugly, and probably quite dependent on the version of Linux that you are using. We use Linux Mint 16 for all of our office computers, so the key thing that I found was that when I connect to our server at “smb://”, and then perform a logical network access in LibreOffice with Samba like this: “smb://”, that the operating system at some point converts that to a “normal” Linux file access that’s not via Samba, and in the case of Linux Mint 16, that “normal” access will be through this path:


where 1000 happens to be my Linux user ID (which you can see with the “id” command). I found, however, that there was a convenient environment variable named XDG_RUNTIME_DIR which has the first part of this path, including the user ID. From what I’ve heard from other people, my guess would be that in Ubuntu this “normal” Linux file access would be through “~/.gvfs/…”, but I don’t know if the environment variable would help you in that case or not.

So for my work-around, I create a server path which is different depending on whether I am on a Windows or Linux machine (the “OS” environment variable will start with “Windows” on a Windows machine). On a Windows machine, we continue to use the logical server file access. On a Linux machine I create the ugly “normal” file path for server file access. So here’s the code:

If Environ("OS") Like "Windows*" Then
	sServerPath = "file://"
	sServerPath = Environ("XDG_RUNTIME_DIR") & "/gvfs/,share=server/"
End If
Open sServerPath & "Data/Finance/Reconcile.log" For Append As #1
Print #1, "Reconciling at: "; Format(Date, "d-mmm-yyyy"); " "; Time
Close #1

Yes, it’s ugly, but it is the only work-around that I could find. Hopefully my bug report will inspire a fix, so we won’t have to do these kinds of gymnastics in the future.