… at least not in my app under windows if they’re on a network-mounted volume. This is 2024r4.1 under macOS Sonoma, building for Windows-10 running in a VirtualBox VM.
I have this code:
dlg = New OpenFileDialog
dlg.Title = "Select files"
dlg.PromptText = "Select one or more files"
dlg.ActionButtonCaption = "Select"
dlg.AllowMultipleSelections = True
f = dlg.ShowModal
if (f=Nil) then Return
Discovering later that I couldn’t read the selected files, I put a breakpoint on the if at the end of the code above, and examined the folderitem. It showed isReadable and isWriteable as both False.
And yet the file in question, a Xojo binary project, could be opened, altered, and saved in the IDE running under Windows 10 in the same VM. Can anyone explain this?
I ran into this or something similar in the past regarding files located in a folder shared by another system on my network. My workaround was to copy the file to the local disk. Not the best solution.
Have other properties also a default value or they are valid?
(e.g. if the file can’t be found, “.exists” would also be false, like IsReadable, IsWriteable and all others with a “null” value)
I’ve seen strange (hard to explain) things in Xojo over the years. It could have been that just because your app has no permission to access the file or one of its subfolders (unlike from the IDE), the resulting folderitem would point to a “non-existent” file, hence the check.
In writing a small test program I discover that the problem is not that a file on a network share is not readable – it is perfectly readable. The problem is that an incorrect value is returned for .iSreadable. Here’s my test app running remotely in a WIn-10 VM:
My main app, which reported that the file could not be read, was carefully checking for .isReadable being True before proceeding to open/read the file. When I commented out that test, my main app was able to read the file with no difficulties. Which probably explains why the IDE didn’t have a problem opening/reading the file.
So I’ll make an Issue out of this for Windows (tested as not a problem macOS/Lin).
I looked at the doc for those two (.isReadable and .isWriteable). I think it should explicitly state that they are unreliable except for locally mounted devices.
It has been ported to my attention that IsReadable can fail on Windows (there are open bug reports) and shouldn’t be a definitive thing to rely upon.
Also, you’d better try first to open the file without checking anything (beyond the variable being nil, of course, and possibly “exists“ being true) and only if you get an exception you have valid reasons to check the various properties. You can’t even guarantee that, starting with valid properties, just calling methods to open a file will work and won’t modify properties afterward, so don’t waste your energy trying to avoid all the possible troubles before they may happen.
Thanks to Norman for reminding about some of this in a discussion.
Yeah. What I’ve done so far, and since these properties appear to be OK on macOS/Lin, is to #if the tests so they only act on those OSes. I don’t want to go to the trouble at this point of trying to open them instead (although that would clearly avoid the issue altogether). The point being that at the moment in question, the user is gathering together one or more files for transmission later. It’s more user friendly for them to be notified as they collect each file, rather then be told later that the transmission only sent some of the files. That way they have a chance to do something about it.
I suppose then that the macOS/Linus implementations of SMB are better than Microsoft’s.
