Their hardware. Not necessarily their developer tools 
Xcode has its way of doing things as does VS
If your familiar with one or the other you’ll feel one way or the other
I’m sure Joe R could list things he prefers in each 
So do Macs. I had a situation last year where the Remote Debugger could not write the tar file into the folder I wanted. All the permissions were any group could read , write or execute in the folder. Even with help from a couple of Xojo engineers we could not get to the bottom of the problem. Another folder worked fine, so I moved on.
With UAC disabled, it is still showing writable as False.
I’m going to try writing a file to the directory and see if that fails like Norman suggested. It’s a bummer this isn’t working consistently.
I agree there… I like their H/W and their O/S… and for open source development it rocks. also for Xojo development.
I am having the opposite problem. IsWriteable returns true for a text file with the Read Only attribute, which plainly should make it false.
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 dont 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 its 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!