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 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.
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.
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?
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.