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.
Related
I got an app I'm working on that uses static data from a sqlite database to do various things, While I only need read only access to the database, depending on the episode they pick from the first screen I want it to use a different database file and I want the list of available episodes to be updateable on the fly. and I got help to get the list of available episodes updated, and the proper content downloaded and stored in separate folders, So I know I could when the episode is selected delete the sql file in the documents folder and copy in the new one each time and that would work well enough for what I'm trying to do. but it seems like a bit much extra work to have to check for file, delete file, copy in new one. then open it from there each time the user wants to pick a different episode. and I don't want to put all the sql files together as that will be a bigger hassle then the first route especially if this app stays around long enough to have a long list of episodes.
so my question here is: can I get at least read-only access to an sql file that I've downloaded (or one in the bundle for testing) with out having to first copy it to the documents? and if so how would i open the file?
Can I get at least read-only access to an SQL file that I've downloaded (or one in the bundle for testing) without having to first copy it to the documents directory?
Yes. Files in the app bundle are readable (if they weren't, there would be no point in storing files in the bundle).
And if so, how would I open the file?
It's not clear what you're asking here - if you want to perform SQL queries on the file, you should use the sqlite3 library which is available on iOS.
I am working on a Vegetable gardening application. Apart from the vegetable name and description I also have vegetable image. Currently, I have all the images in the Supported Files folder in the Xcode project.
But later on I want to update the application dynamically without having the user download a new version. When the user updates the application or downloads new data from the server that data will include the images. Can I store those images in the supporting file folder or somewhere where they can be references by just the name.
RELATED QUESTION:
I will also allow the user to take pictures of their vegetables and then write notes about the vegetables like "just planted", "about to harvest" etc. What is the recommended approach for storing pictures/photos. I can always store them in the user's photo library and then store the reference in the local database and then fetch and display the picture using the reference. The problem with that approach might be that if the user accidentally deletes the picture from the library then it will no longer be displayed in my application.
The only way I see if to store the picture in the app local database as a BLOB.
No you can't put the downloaded images with the others inside the supporting file folder. Also I would suggest you put the images inside an Images or Resources folder instead... If you want to download any data after the app is compiled, then they will not be in the bundle. It is the bundle you are referring to when talking about the Supported Files folder in Xcode. This is read only for your application.
Just to be clear, once compiled, there are no folder structures for your application, these "folders" are just groups in the Xcode project to keep things tidy.
If you download say a zip file containing a set of images, it's up to you to write them to disk after you download them. You should put these images in either the tmp, the cache or the documents directory.
But then you'll have to build your path before loading the images. You won't be able to just provide the name of the file such as:
[UIImage imageNamed:#"something.jpg"];
Because this will look in your bundle. Instead you must do something like this to load your image from the Documents directory for example.
Your challenge is that you will end up in a state where you'll have some images in the Bundle (the ones from when you uploaded your app), and the newer ones in the documents directory. You must them check the bundle first and if there is no image there, check the documents directory.
For user generated data, I suggest also saving the images in the Documents directory, and maintaining an SQLite database of the users data, so you can map an image name to an entry in the database. You don't want to save the images as BLOB because this will inevitably slow down the performance of your queries and add extra unnecessary load on the CPU to convert to UIImage and back.
You don't want to save their images to the gallery for 2 reasons, first this means you'll be saving in 2 places because keeping a reference in your database to an external image is very fragile and you're just asking for trouble, and secondly, once the image isn't under your wing, you don't control it anymore, the user will delete it at some point, if they go back to your app they expect to see it there.
I have a SQlite database file with records which comes with my app.
I just used the file I added to my project to make my INSERT and UPDATE statements.
After uploading it to my test device I got the exception that the file is read only.
After a bit of research I found out, that I have to copy the db file to the users directory to make an insert. This works for now. But I have a view questions about it, which i didn't get answered through google:
Where should I put my copy process?
I implemented it in the AppDelegates FinishedLaunching, where I check if it already exists.
Where should I copy the file to?
I used the MyDocuments folder for now, is this ok?
Since the file cannot be encrypted, can another app access the database file?
When the user decides to delete the app from the device. Will the database file get deleted,too?
Thanks!
Where should I put my copy process? I implemented it in the AppDelegates FinishedLaunching, where I check if it already exists.
That really depends, but finishedLaunching is OK from my point of view.
Where should I copy the file to? I used the MyDocuments folder for now, is this ok?
I'm not sure what you mean by "MyDocuments" folder. Each Application has a dedicated Document directory. That's where you should copy it.
Since the file cannot be encrypted, can another app access the database file?
No, they run sand-boxed (unless the device is jailbroken)
When the user decides to delete the app from the device. Will the database file get deleted,too?
Yes, since the whole document directory will be deleted.
Where should I put my copy process? I implemented it in the AppDelegates FinishedLaunching
Keep in mind that you have a limited amount of time to complete FinishedLaunching execution (around 15 seconds) before the iOS watchdog kills your application.
Depending on the size of your database, the speed of device and other processing you need to do then you might want to consider only checking if it already exists (that should be quick) then do the copy (if required) from to another thread.
I used the MyDocuments folder for now, is this ok?
Yes, using Environment.GetFolderPath (Environment.SpecialFolder.MyDocuments) is correct.
Everything else from #Lightforce answer covers the rest.
Is there any way a new image upload from a PHP form sent to directory a can be copied to directory b after it has been uploaded? In this case it's not possible to alter the upload path itself or copy it during upload so I'm looking for some kind of automatic replication of new directory contents into another directory after the file has been uploaded.
Is there an automated service/script that can move the content of one directory on our server to another directory? We upload files to www.mysite.com/upload/thumb for example but need them to be moved automatically to www.mysite.com/cs/upload/thumb - is this possible without running a move_uploaded_file PHP script (I would prefer it to be done by the server because we use the same page for many different landing page functions).
do you look for copy (http://php.net/manual/en/function.copy.php)?
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.