Creating a Temporary Directory with NSFileManager - NSItemReplacementDirectory creates folder in user-facing location?

Question

Macho Man Randy Savage OP

Created 2w

Replies 3

Boosts 0

Participants 3

So I'm reworking couple things in my app. And I noticed I had this old code that does the following:

Creates a temporary directory.
Writes a file in the temporary directory.
After the file is written moves the file out of the temporary location and places it in its final destination.

Okay so I was not creating the temporary directory using the recommended API. I was simply doing something like this:

NSURL *tempDirectory = [NSURL fileURLWithPath:[NSTemporaryDirectory() stringByAppendingPathComponent:[NSProcessInfo processInfo].globallyUniqueString]];

// Create tempDirectory and write files inside it.

Now I just changed the code to use the recommended API which takes the the volume of the target destination into account: -URLForDirectory:inDomain:appropriateForURL:create:error:) and I pass in NSItemReplacementDirectory and a url to appropriateForURL so the destination volume is taken into account.

Now I have external storage mounted and I use the recommended approach. I discovered NSFileManager simply writes a directory right in a user facing location titled: **(A Document Being Saved By App Name) ** and the folder is not hidden.

Is this intended behavior for this API? Are temporary files supposed to be user facing? I know it is good practice to clean up temporary stuff when you are done but in crashes or just forgetting to clean up will leave these behind which isn't the behavior I expect for "temporary files." Also if the user is viewing the folder in Finder they'll see these A Document Being Saved By App Name folders appear and disappear in the window as my app does this work.

Answered by Etresoft in 876946022

That is the intended behaviour. But it wouldn't be the recommended API for every kind of "temporary directory". It seems designed for implementing a manual atomic write. The NSDocument architecture would do that for you.

But if you had a reason to avoid using the NSDocument architecture, you could use this API, and it might be a good idea for the end user to see the directory in case the save is going to take a long time. You wouldn't want the user interfering with your save.

However, if you're looking for a more traditional type of temporary directory, then this API wouldn't be appropriate.

Boost

Answer 1

Etresoft OP

2w

Accepted Answer

That is the intended behaviour. But it wouldn't be the recommended API for every kind of "temporary directory". It seems designed for implementing a manual atomic write. The NSDocument architecture would do that for you.

But if you had a reason to avoid using the NSDocument architecture, you could use this API, and it might be a good idea for the end user to see the directory in case the save is going to take a long time. You wouldn't want the user interfering with your save.

However, if you're looking for a more traditional type of temporary directory, then this API wouldn't be appropriate.

0

Answer 2

Macho Man Randy Savage OP

2w

The API I'm using to write the file (to the temp location) writes the file atomically and will overwrite an existing file but in the final destination I'm working in it is a user facing folder and I don't want to just assume a save location and potentially overwrite the user's data.

So what I do is simply write in the temporary location atomically, then attempt to move the file in the final destination with a preferred filename without looking before I leap and if I fail to move because the file already exists, I try again with a different name.

I could continue to write to the temporary location the old way but that definitely will be slower for external volumes because I do the "move" (copy/delete) across volumes. But I don't want to flash temporary folders in the Finder either.

In my very limited testing it seems if I clean up the temp directory right after I finish they don't appear in Finder but I assume they will if the operation takes a long time.

0

Answer 3

DTS Engineer OP

Apple

1w

Is this intended behavior for this API?

Yes.

Are temporary files supposed to be user-facing?

That problem here is that using an external volume means that the system can't assume it has ongoing control of that volume, which means it doesn't have any good way to "cleanup" after itself. So its choices are:

Use a hidden directory and risk the user never being able to delete the data, since they don't know it's there.
Write the data in a user-visible way.

...and number #2 is clearly the better of the two options.

Okay, so I was not creating the temporary directory using the recommended API. I was simply doing something like this:

Note that what you're doing there is creating the file on the local volume, which is not necessarily the same volume as the final target. That means that this:

I could continue to write to the temporary location the old way, but that definitely will be slower for external volumes because I do the "move" (copy/delete) across volumes.

Isn't just slower, but is FAR more dangerous. The whole point of the "appropriateForURL" API is to ensure the source and destination are on the same volume, allowing either an atomic exchange and/or a safer move sequence.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

1