Using IMAP, how can I figure out if a mailbox has been moved or deleted by another client?
The LIST command simply does not list a deleted mailbox any more.
Exactly. You have to remember what folders you know about. Next time you do a LIST, any that are missing have been deleted.
Additionally, you should be tracking every folder's UIDVALIDITY value. If it changes, that folder is not the same one you know about. It may have been renumbered, deleted and recreated, or deleted and replaced by a renamed folder.
In either case, you should dump any cached information you know about that folder.
There is not, in general, any way to track folders that have been renamed by another client. You can only detect that a folder is missing and there is a folder with a new name. IMAP simply does not provide enough information to correlate them. Tracking messages and folders across moves does not appear to have been a design goal of IMAP.
Related
Suddenly the files inside the folder App_Plugins/UmbracoForms have vanished and I cannot seem to recover them. The files include UmbracoForms.config, version, installed as well as the most important form data inside the Data folder.
Checking the file/folder history it seems that the files were last modified by the Application Pool user identity, meaning the website deleted it's own files.
Why would this happen and how is it possible to recover these files?
I've never come across Forms/Umbraco deleting anything out of the App_Plugins folder without a user uninstalling the plugin in the back office.
Is it possible that someone has done a publish via VS or similar that's cleared the folder and replaced it?
In terms of getting the files back, if they've been deleted, you should in theory be able to recover them from your hosting company's back-ups (assuming the site is being regularly backed up).
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.
Is it possible to hide the Inbox from the list displayed of the directories?
For example, in this screenshot from a tutorial, the inbox folder features. In my app I would prefer it not to.
Other apps (eg. Molecules) seem to manage this, so I assume it is possible.
(In case anyone is wondering I am a novice developer)
I very much appreciate any help.
So it turns out that although the Inbox directory is not writeable, it is deletable. Files opened through other apps will be automatically placed in this file, and if the inbox does not exist then it is created. So to get rid of it, simply delete it every time you handle an external file opening.
Very simple, just got thrown when I tried to edit a file in the inbox, which raised an exception, making me think the inbox was write-protected.
I have a simple app that downloads some data from a webservice and displays it in tableviews. In order to allow offline access, the app caches this data in the cache directory on the device itself. I keep a list of all of the cached files for reference, and save that to the cache directory as well. So after all of the downloads are complete I have the following files:
XMLFileList
XML1
XML2
...
I launched this app a couple weeks ago, and have since had to release a few minor updates as necessary to fix some minor bugs. It seems, however, that when a user updates the app on their device, they no longer see the downloaded resources. I have managed to get this to happen on a development device, by updating through the app store, then loading a debug build, and determined the following problem
It would seem that it is not displaying the data in the downloaded files because they no longer exist. It is also not re-downloading the files because they show up in the saved list. This provides a rather interesting question: why did the cached XML files get deleted, but not the master list?
What exactly is going on behind the scenes during an app update that I could account for, or reproduce to ensure this does not continue happening?
If you're putting files into /Library/Caches (or whatever it is), then there is no guarantee that those files will be there the next time you run your app. Anything you put into /Documents, however, will be there. And in fact, anything in /Documents will also be backed up to iCloud (unless you set the bit newly available in iOS 5.0.1 that lets you opt-out files in /Documents from being backed up.)
Anyway, the point is that you should read Apple's docs on what files you should put where. (I searched around for the correct reference unsuccessfully; I've seen it before though.) It boils down to this: Anything that is user generated should go in /Documents, anything that can be re-fetched from a server should go in /Library/Caches and may be purged by the OS.
Cache directory contents are not guaranteed to be preserved. But I don't see any documented guarantee that the entire directory will be cleared all at once. (Maybe only the biggest and/or oldest contents or some such?)
I would like to create a simple file repository in Ruby on Rails. Users have their accounts, and after one logs in they can upload a file or download files previously uploaded.
The issue here is the security. Files should be safe and not available to anyone but the owners.
Where, in which folder, should I store the files, to make them as safe as possible?
Does it make sense, to rename the uploaded files, store the names in a database and restore them when needed? This might help avoid name conflicts, though I'm not sure if it's a good idea.
Should the files be stored all in one folder, or should they be somewhat divided?
rename the files, for one reason, because you have no way to know if today's file "test" is supposed to replace last week's "test" or not (perhaps the user had them in different directories)
give each user their own directory, this prevents performance problems and makes it easy to migrate, archive, or delete a single user
put metadata in the database and files in the file system
look out for code injection via file name
This is an interesting question. Depending on the level of security you want to apply I would recommend the following:
Choose a folder that is only accessible by your app server (if you chose to store in the FS)
I would always recommend to rename the files to a random generated hash (or incremntally generated name like used in URL shorteners, see the open source implementation of rubyurl). However, I wouldn't store them in a database because filesystems are built for handling files, so let it do the job. You should store the meta data in the database to be able to set the right file name when the user downloads the file.
You should partition the files among multiple folders. This gives you multiple advantages. First, filesystems are not built to handle millions of files in a single folder. If you have operations that try to get all files from a folder this takes significantly more time. If you obfuscate the original file name you could create one directory for each letter in the filename and would get a fairly good distributed number of files per directory.
One last thing to consider is the possible collision of file names. A user should not be able to guess a filename from another user. So you might need some additional checks here.
Depending on the level of security you want to achieve you can apply more and more patterns.
Just don't save the files in the public folder and create a controller that will send the files.
How you want to organise from that point on is your choice. You could make a sub folder per user. There is no need to rename from a security point of view, but do try to cleanup the filename, spaces and non ascii characters make things harder.
For simple cases (where you don't want to distribute the file store):
Store the files in the tmp directory. DON'T store them in public. Then only expose these files via a route and controller where you do the authentication/authorisation checks.
I don't see any reason to rename the files; you can separate them out into sub directories based on the user ID. But if you want to allow the uploading of files with the same name then you may need to generate a unique hash or something for each file's name.
See above. You can partition them any way you see fit. But I would definitely recommend partitioning them and not lumping them in one directory.