I issued a strange behavior lately with High Sierra:
I wanted to store as a db file (sqlite) some data and the target folder was refused.
No problemo, I saved the data into the Downloadings folder and that was good. Then I moved my file into “Downloadings:Folder1:Folder2:Folder3:” and that was fine too.
It already happened yesterday, but I was too deep into what I was doing (modifyng that project) and let that to greek calendes…
Now, I get that too and I am starting to be curious / want to know why.
The project was built with Xojo 2015r1 (and I use it since… Mathusalem was a young boy 
); I forgot f I was running it in the IDE or not yesterday.
BTW: before doing that, I deleted the previous build, quit all applications but Firefox (it have a download running), then I fired Xojo, loaded the project and build it without change.
LBN: I saved the original as .csv without trouble minutes ago into its proper location (with the previous build.
Idea ?
I had to boot on El Capitan for other means, and when I used that application it crashed, but using a different function. So, after all this may be a bug at application build time.
In the IDE, the application works fine.
Remember that Xojo always opens SQLite in write mode, which can sometimes need the sidecar WAL and journal files. If you haven’t been given permission to the parent folder by the user, it could be a permissions problem.
With Xojo, SQLite, and macOS I tend to recommend connecting in ApplicationData and copy to the target FolderItem provided by a SaveFileDialog. I think that @Sam_Rowlands has mentioned that in newer macOS sometimes this file swap is not allowed, for which situations I have no ideas or workarounds.
I was using the temporary folder to write the data too as I would never expect in a million years that apps cannot write to the temporary folder, but since Catalina it is now possible that applications may no longer write to the temp folder.
Do I need a warlock or some gri-gri ?
Forgot to mention that I had created the atomicSaveLocation and atomicSaveReplace functions for the Ohanaware App Kit that will provide you with a “safe” location (using Apple’s API) to write the data too. Then replace the original file with the saved one.
Ironically Apple will use the very same Temporary folder that we’re unable to write to, but the resulting folder you can write too, unless there are already 512 items in the temporary folder, at which point no more files or folders can be created there.
1 Like