When I save (either create or update) a small file in the iCloud container of my iOS app, the iCloud daemon first uploads the file to iCloud and then evicts it when the upload is done. If I monitor the file's state using a NSMetadataQuery I can see that after the save, the file's downloading status changes fromNSMetadataUbiquitousItemDownloadingStatusCurrent to NSMetadataUbiquitousItemDownloadingStatusNotDownloaded, and instead of my little test file named test I only see the file .test.icloud instead.
This is bad because if the user goes offline after the file creation, the file cannot be read again. The file should always be available locally after the creation (an outdated file is better than no file).
I know that I can immediately re-download the file using FileManager's method startDownloadingUbiquitousItem after iCloud removes it, but this feels like a silly hack. Is there a way to simply prevent iCloud from evicting the file in the first place?
Related
I have a rails app where the user can upload files. The files get uploaded to an external cloud service by a backgroud jobs. It's vital for my app that the files won't get stored in the file system after they've been uploaded. Not right away, in general -- they must not remain in the file system.
Should I delete them on my own? Or will get deleted automatically?
Also, debugging my app, I noticied this for an attachment params:
[2] pry(#<MyController>)> my_params.tempfile.path
"/var/folders/qr/0v5z71xn7x503ykyv1j6lkp00000gn/T/RackMultipart20181007-10937-3ntmgg.png"
That file gets stored not in "/tmp" but in "/var" and that means that it won't get deleted automatically, right?
Note that I'm not using paperclip for this task.
You are right the files won't get deleted automatically.
You have to delete the file explicitly at some point in time.
It depends how you set it up. If you used Tempfile to save it then yes the files will be deleted when the object is garbage collected. If not then it probably won't be deleted.
If the files get stored on an external service it might be worth setting up ActiveStorage which allows you to directly upload to external storage providers without the file ever touching your server.
I am implementing a resumable upload protocol that uploads in the background on iOS, which means I have to use an NSURLSessionUploadTask with a file. Since it's a resumable upload protocol, the file needs to be truncated based on the data that has already been received by the server, so I need to save a new temporary file to disk that has only the bytes to be uploaded within it.
If I can create that temporary upload file in the tmp/ or /Library/Caches/, can I trust that it will be kept as long as the NSURLSession is running?
EDIT: When an upload fails, the server will be saving the bytes it has already received and communicating that to the client. The client then should only send part of the file, which is why I need to create a smaller temporary file that must not be deleted mid-upload.
Huh? You provide the entire file, and the system takes care of managing the partial upload/download, and notifies you once the transfer is complete. In the case of a download, t hands you a temporary file once the download is complete and you have to save it to a permanent location.
You should not be mucking around with partial files at all.
EDIT:
You don't have access to tmp or /Library/Caches/, except through the sandbox. You can get access to the caches directory with the call
[NSSearchPathForDirectoriesInDomains(
NSCachesDirectory,
NSUserDomainMask, YES) lastObject];
It's my understanding that the caches directory only gets purged on restart, or if the device gets critically low on space, but I seem to remember that the docs are vague on when, exactly, the caches directory gets cleared.
You would probably be better off saving your file to the documents directory, then deleting it once you're done with it.
The answer to your question is no. NSURLSessionUploadTask's description appears to support keeping the source file around but it's misleading:
"In iOS, when you create an upload task for a file in a background session, the system copies that file to a temporary location and streams data from there"
But it says nothing about whether it will keep the original source file in the tmp directory. Specifically for your case where your server supports uploading partial files and you need to restart them after failures. Or in the more common situation where you need to manually restart an entire failed upload, for example from a retry-able server error, or if user killed your app and then restarted it (iOS doesn't continue uploads for user killed apps).
In these cases you can't count on the file still being around if you create it in the apps tmp directory. The file system programming guide tells us this.
https://developer.apple.com/library/archive/documentation/FileManagement/Conceptual/FileSystemProgrammingGuide/FileSystemOverview/FileSystemOverview.html
"Use this directory to write temporary files that do not need to persist between launches of your app. Your app should remove files from this directory when they are no longer needed; however, the system may purge this directory when your app is not running. The contents of this directory are not backed up by iTunes or iCloud."
So any tmp directory files can be deleted by iOS when your app stops running, and I can confirm I've seen this in production releases of our app. If you think you may need the source file for the upload again, you must store it in your own app directory, and manage deleting it yourself when done with it. Sorry, extra work, but I don't know of any way around it.
Let's say an app downloads images from web while the user is browsing the app. Let's assume there are virtually unlimited images and a new image is downloaded whenever the user demands one. These images are saved to tmp directory for caching purpose. Once the user closes the app, all the images downloaded are deleted by the app.
Now, as there are unlimited images, what will happen if the user requests next image, the storage is full and the app attempts to save the image to the tmp directory?
Will the previous images be deleted by the iOS automatically to provide the space required for the new images?
OR
Will the iOS start cleaning tmp directory associated with other apps?(If yes, what happens when the storage is full again and such cleaning has already taken place for all the other apps?)
OR
Will the app crash?
If you try and save a image to disk and the disk is full then NSData's
- (BOOL)writeToURL:(NSURL *)aURL
options:(NSDataWritingOptions)mask
error:(NSError **)errorPtr
Will return NO and an error object will be assigned to the errorPtr passed into the method. This error will have a NSFileWriteOutOfSpaceError. This error is very exceptional, and by the time you get it it's safe to say the system will have already notified the user that he is running out of disk space.
Having said that, a lot can be said about cleaning after yourself. If you're not going to use a saved image resource anymore then delete it from the file-system.
Cheers!
tmp/
Use this directory to write temporary files that do not need to persist between launches of your app. Your app should remove files from this directory when they are no longer needed; however, the system may purge this directory when your app is not running.
The contents of this directory are not backed up by iTunes.
That's the only thing documented. From this I can infer that it won't purge you tmp if your app is running,but it can purge the tmp of other apps which are not running
As #InderKumarRathore says, the docs imply that the system will not delete files from your temp directory when your app is running. The docs also don't promise that the system will delete contents from other apps' temp directories to make space for you.
I would suggest coding defensively: Keep track of the oldest/least recently used files in your temp directory and delete them yourself. Preflight file saves to make sure there is enough space, and display a message to the user if there isn't enough space to save the file(s).
In my iPhone app, I am downloading files from server and storing them locally (user's document directory). The path of each file downloaded is subsequently updated in database.
If user tries to delete a file, first the file is deleted from local path using removeItemAtPath: (NSFileManager), then corresponding record is deleted from database.
Now I have one of the requirements according to which user can turn on a UISwitch to delete all data on app exit.
Now my question is -
suppose user downloaded 20000 files, say small images, and user turned
on the switch to delete all data on app exit. Is it good to handle
this task in applicationWillTerminate? What is the best way to
accomplish this scenario?
Please suggest.
Don't delete the files individually, delete and recreate the folder.
Your database could be handled differently by version tagging so that you can batch delete the items on the next run.
applicationWillTerminate will only be called if your app goes background (the only option by pressing Home button of the device) and "Application does not run in background" key is set in your app's info.plist file to "YES". Otherwise it won't ever be called.
If you are planning deploy app with similar functionality, you can use applicationWillTerminate for removing so many files. However, I would never recommend you that. Instead, my recommendation is to remove the files as soon as they are processed, if possible at all.
Another thing you must consider is not to save so many files in Document directory, however small those are. Document directory is backed up by iTunes and iCloud and if you store so many files there, you are gonna possibly violate Apple's Data Storage Guideline that would reject your app from App Store. It is always a good idea to store transient files in application's "tmp" directory and delete them when not required anymore.
I am attempting to add iCloud synching to my iOS/Mac app by using the iCloud methods on NSFileManager (no documents or file coordinators). The app needs to synch audio files across the various instances; create, delete and metadata changes. It isn't a collaboration style app, so I am not very worried about conflicts, etc. I have something basic working, but have run into some basic questions that I can't seem to find definitive answers to.
When using iCloud, there are two local directories involved, the sandbox directory where the file originates and the ubiquity container directory. Once I enable a file for ubiquity, should I start interacting with the file in the ubiquity container directly or should I continue interacting with the sandbox file and pushing/pulling changes from the ubiquity counterpart? It feels like the latter is best so that I don't lose all the users files if they turn iCloud off (not sure what happens to files in ubiquity container in that case).
If I maintain two files, is there a preferred way to push/pull incremental changes to/from the ubiquity container? As I understand it, if a user changes a file on a given device, all other devices get the incremental changes in their local ubiquity copy (if downloaded). Should I just be copying the file in it's entirety over to my local sandbox directory every time the ubiquity file changes and vice versa?
Constantly copying files to the ubiquity container as they are modified doesn't seem like a good strategy to me and might even result in iCloud thinking more of the file has changed than really has. You can interact with files in the ubiquity container directly, working with them just as you would a file in your 'normal' document sandbox. This is the model prescribed in all of the iCloud documentation, sparse as it may be.
You're right that you need to be able to handle the situation where a user migrates away from iCloud. There are methods to move a file out of the ubiquity container and some of the newer iOS 6 API makes it easier to detect if the user has iCloud enabled, though this is still an area where we could use more API.