IsWriteable incorrect

Which Xojo version? Which OS version? Which framework?

Sorry, tried to reply to the email message.

Xojo 2015 r4.1; Windows 7; not sure what you mean by frame work.

I was able to write a write test to keep the program from failing, but IsWriteable is not returning a value on a Read Only file that makes sense to me.

Both .IsWriteable and .IsReadable can fail when trying to access a file on a NAS device. This is with Xojo 2019R1.

Here are two native paths to the same file that fail on both of these functions:

\\10.5.4.150\Lighting\Control\Lightwright Issue\SD0049-LX-Anna Lighting Plan v2019.lw6

\\files.lx.nationaltheatre.org.uk\Lighting\Control\Lightwright Issue\SD0049-LX-Anna Lighting Plan v2019.lw6

There are Feedback reports on both of these, #998 (.IsWriteable) and #55731 (.IsReadable). If nothing else, Xojo should update the documentation to say that they are unreliable and should be deprecated.

What file system are those two NAS running ?
That could be relevant

We’re seeing oddities on NAS units based on FreeNAS using the ZFS file system that manifest in this manner. Xojo isn’t the only environment where files are being reported as writable when they’re not.

And it does seem to be ZFS related versus the way they are mounted (NFS, CIFS, AFP).

[quote=440215:@Norman Palardy]What file system are those two NAS running ?
That could be relevant[/quote]

This from my user at the National Theatre in London:

"We have noticed that this issue is also the case when you use Apple file sharing to create a share to a windows machine. It seems to be that if the file uses Unix permissions rather than Windows ACLs the file can be opened, but not if Windows ACLs are used – even if they have the same level of permission. We don’t use Active Directory – we use LDAP our directory services. We have tried using a path without any periods (by adding the DNS suffix to the adapter as a connection specific DNS Adapter) and have not had the same issue. "

And this: “We have tried from two servers- an IT managed windows based server (ness) and our Unix based Synology server (files.lx.nationaltheatre), both fail the .IsWriteable and .IsReadable tests.”

Discouragingly enough, the .IsWriteable report dates from 2008 and is marked as Verified. My report on .IsReadable dates from last month and hasn’t been reviewed yet…

I wish that there was a way for the Xojo docs to say clearly when there are functions like this that have been verified as unreliable, that way we could know to avoid using them in the first place.

is the first a mac accessing a windows machine that has a share the mac is accessing ? (or do I have that backwards ?)

the second is macs accessing a windows server and a synology ? still doesnt tell me what file system the Synology is though and that could be relevant

I dont think the protocol_ used to share it matters but it could
there have been some smb bugs that made things behave weird - but that was smb2 which I dont think macOS uses any more

[quote=440222:@Norman Palardy]is the first a mac accessing a windows machine that has a share the mac is accessing ? (or do I have that backwards ?)
the second is macs accessing a windows server and a synology ? still doesnt tell me what file system the Synology is though and that could be relevant
I dont think the protocol_ used to share it matters but it could
there have been some smb bugs that made things behave weird - but that was smb2 which I dont think macOS uses any more[/quote]

The files on the Synology NAS are accessed from both macOS and Windows computers. The notes I quoted say that both their Windows-based network server and their Unix-based Synology NAS fail the .isWriteable and .IsReadable tests. And in all cases, if you just go ahead and read or write the file, it succeeds.

OK - what file system is the Synology using ?
That may be entirely relevant (as Tim just noted)

I don’t know what file system, unfortunately. I sent an email asking, may hear back tomorrow.

I echo Norm’s advice.

Try to create a file of the right name, wrapped inside a try…catch
If you get an exception, handle that.
I started doing that because of trouble I was having with PDF files held ‘open’ by Adobe, and CSV files held ‘open’ by Excel.

Similarly, I wrap DELETES in a try catch, and then test for f.exists afterwards too.

#trustnoone

FWIW:

The Synology NAS is managed by the user and uses BTRFS as it’s local filesystem. However as it is a network share, when mounted on a windows computer, it mounts as NTFS and on a mac as SMBFS (Samba File System).

Yes, I’m modifying my code now to do this instead of looking at .IsReadable and .IsWriteable.

Thank you all!