Where does the PERMANENTLY DELETED DATA go from memory? And where will the data go after clicking shift+delete keys.
You have to understand the concept of File System first. When you press shift+delete, OS calls File System routine to delete file from entry table. File System could either chose to just remove the entry (mark file as deleted) or zero out data of the file and then remove permanently from entry table.
In case of shift+delete, File System assure you to delete file permanently i.e. zero out data and remove entry from the directory table. In that case it is not recoverable. Although some hardware hacks are possible to recover data, by analyzing magnetic fingerprints of hard disk.
If you delete file simply by pressing delete key; It actually just mark file as deleted in file system entry, thus file system could use It's data sector and overwrite with other content. In this case file is recoverable but not guaranteed to be 100%, File System could have corrupted it by overwriting It's data sector.
Related
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?
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.
My iOS app uses CoreData and some tables need to be filled with default values every first time the app is opened since CoreData device-dependent.
So I am using NSUserDefaults to check whether it is first time open. If it is first time, I fill tables (on CoreData) with the values which I have already created and formatted lines from the txt file by reading line by line and separating in a way.
And my question is, is it safe and fastest way to use txt file for such operation?
A better option would be to keep a "canned" sqlite file in your app bundle and check for the existence of the SQLite file in your documents directory. If the file does not exist, copy the canned data from the app bundle to your documents directory.
That will skip the entire parsing logic and will allow your application to launch faster.
Marcus' approach is also what I would recommend. But you can still keep using your parsing code during development in order to have a convenient way to create the seed SQLite file. When you ship your app, package the newest seed store as a bundle resource and disable / delete your parsing code.
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.
How can I display an image from file object? The file object holds the location of the image in temp uploaded directory.
I dont want to use any models.
Its for previewing a form having filefield
The problem with most temporary files is that they don't exist. They're in a deleted state and will disappear entirely once the file handle is closed. It's your responsibility to move copy the data out of them and into another file, database, or cache, whatever works best, in order to preserve it.
You don't need to use any models to make this work, but you will need to be able to write to a directory your web server will be able to access. Typically you can make a /uploads directory and copy the file there, removing it later on when it is no longer required.
That clean-up step is easily done by a cron job that deletes all files with an mtime of a day or so, depending on your preference.