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

Question

Macho Man Randy Savage OP

Created 2h

Replies 2

Boosts 0

Participants 2

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.

Boost

Answer 1

Etresoft OP

1h

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

48m

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