getting a temporary folderitem on a specific volume?

General
1

good morning folks!

Going through some of the things that are marked as “deprecated” just by way of cleanup before I have to do it in a panic someday when it gets removed.

What I’ve considered the appropriate way to rewrite important files is to write to a temporary file and then do a file system swap of the 2. Then you can validate the new file exists and didn’t get messed up due to disk space or other issues before you delete the original one.

In order to do a file swap, or even just a move to the new appropriate location, the temporary file has to be on the same physical volume as the one you’re working on. I used to be able to get a reference to the temporary folder on the same volume as the file I was working with via the folderItem.temporaryFolder method. This is deprecated now and I’m supposed to use the SpecialFolder object or the GetTemporaryFolderitem method? As far as I can see those will only provide me with a temporary file on the boot volume. What if I need a temporary file on some other volume in order to do that swap or move?

As a work around I’m just creating a properly named temporary file in the same parent folder as the file I am working with. Is this the new standard way of doing this? Or have I misunderstood the being on the same volume requirement for swapping files? Or should there be a feature request for this?

2

There isn’t a built in way to get a temporary item on a specific volume

They’re always in a direct specific to the logged in user so they dont leak across that boundary
And the system will clean them up periodically

Putting them on another volume would potentially mean they are leaked across user accounts and are not cleaned up

I’d just create the file on the non-boot volume

For swapping file atomically the files must be on the same volume
I believe thats an OS requirement

3

This is a good question, and there should be a feature request. Xojo provides no native method for securely creating temp files. For console programs running on a server (and web apps), this should be of particular concern.

For Mac OS and Linux, the best approach for now is to use mkstemp. You can take the file descriptor returned and create a BinaryStream object for writing and reading. On Mac OS, at least, there is still a small issue with mkstemp, namely that the close on exec flag is not set on the new file.

Adding such functionality to the Xojo API would take a little thinking, because you would want to return both a BinaryStream and a FolderItem.