Continuing ARM32 file writing issues

I’ve asked this question before, but I’m putting up a new Thread because I’m going to word it differently, as the problem still hasn’t resolved.

I am writing a ARM32 app for a client. He is running it on a Raspberry Pi, which is networked to a Odroid. (has to because Odroid is 64-bit, and I can’t do ARM64 in Xojo yet.) The app needs to write to the Odroid, to a folder called “wav”; the path is (as setup by the client) “.mnt/wav”.

I create a FolderItem for it, which is not Nil, IsWritable, and Exists. Then I try to write a file into that folder, and upon BinaryStream.Create I get a IOException, with error code 2. A zero-length file is created though. The BinaryStream object is still NIl so I can’t work with it. I don’t understand why this is happening.

Here’s more info. The client can easily access the Odroid folder via the Pi with all file operation commands (mv, etc.) No problems at all. When he looks at the folders permissions via ls -la, it shows 777. However, when I look at FolderItem.Permissions for that folder within Xojo, it returns 511 (Read and Executable). Why are they different?

This happens regardless if the app is run as sudo or not. In contrast the client can operate on that folder via the Pi regardless if he uses sudo or not. He has also chmod my app as 777 just to try, same problems.

My client has done everything he can and he’s really putting it over to me to solve the issue.

I want a solution where I can write this folder and not get these IOExceptions. Why am I getting these exceptions, and does the different Permissions values (Xojo vs. ‘ls -la’) shed any light?

Sounds like the app is running as different user … perhaps one which has from Odroid perspective less permission. The customer though might access the Odroid as root (or with root rights).

Sounds like a framework bug, if you can create an empty file on the remote drive then you have permission to access it but something internally is failing when trying to write data as if you have 511 then you shouldn’t even be able to create a zero length file. Maybe @Tim_Jones can shed a little light on linux nfs permissions (if you are using nfs) but it might need some pi/arm32 knowledge and I don’t know if Tim has used them very much.

I ran into this on one of my projects. I forget how I fixed it. Give me a few to find that project and code.

1 Like

Make sure to set the binarystream to ReadWrite.
The call .bytePosition = 0
After that write to the stream.

There was a bug requiring the setting of the byteposition to 0 before you could write.

Maybe it’s bot fixed? Or you are running an older version of xojo?

If you use .Create you should set the overwrite flag in the constructor

Please re-read my post; thanks for trying to help, but your response makes no sense (“overwrite flag in the constructor”? What is that?). The Create() call (which is not a Constructor) is the thing that throws the exception, so BytePosition means nothing.

Looking forward to TIm’s findings.

Just out of curiosity,

Is the ls being done on the pi through the mount point or directly on the other machine?

Are you sure that the mount point is mounted as writable?

Have you looked at the system logs on the two machines to see if any info is being written?

I am 99% sure he’s ls’ing it through the pi. We are sure the mount point is writable, he has full access when he does regular file commands from the terminal, like mv or cp. And he knows it’s writable from how he set it up, and even Xojo says TRUE in the IsWritable property of the FolderItem. What would we be looking for in the system logs?

My suggestion would be to use tail -f on the log from a terminal and then have the app try to access the Mount.

1 Like

The create call creates your instance… behaves like a constructor

I was waiting for Tim Jones response, but in the meantime I swapped the BinaryStream call to the LargeBinaryStreamMBS object in MBS, which… worked. Christian mentioned this to me, but even he doubted it, and I was on a lean-and-mean roll and I didn’t want too many files in the Resources folder. (Why? I dunno. The framework is huge as it is, why should I care if there are a couple other smaller .so’s in there?)

But yes, for some reason MBS overcomes whatever is the problem and the built-in BinaryStream coughs. As all programmers say, go with what works! It would be nice to know what the problem was though.