I would like to create a file type with a personal extension by combining two other file types, like .mp3 and .pdf.
Later I need to re-open the custom files I've made and be able to use the included files in my app.
How do I do that on iOS?
One option is to append the data of the two files together. Include a few bytes of data at the start that tell you the size of each and maybe their original filenames. Then when you want to recreate the two files from the one custom one, you read your header to get the sizes and names, then use that info to recreate the original files.
Another option would be to zip the two files together. Just give the zip file your own custom extension.
Another option would be to use an NSFileWrapper. Include the two regular files in the wrapper.
Related
I'm trying to create PropertyHandler shell extension.
What's the best way for embedding properties like (Title,Author,.....) to use the same file in multi computers or devices?
StgCreateStorageEx ? way or there is other ways to do it?
because StgCreateStorageEx dealing with NTFS files only and i'm not sure if the file hold these properties with it if i open it in other device with same PropertyHandler
Is there any way to save properties inside the my file ?
The StgCreateStorageEx function creates a new storage object using the IStorage interface. This allows storing multiple data objects within a single binary file, see for example https://en.wikipedia.org/wiki/COM_Structured_Storage. So, technically, you can save almost anything in this file including embedded properties.
I don't think that this is limited to NTFS: The old Microsoft Office .doc format (and many other Microsoft products) use this storage format and work also with FAT32.
If you want to use this binary file format is a completely different question. As you did not provide any information about the content and format of your file, I cannot recommend anything. One alternative would be to store the content of your file in an xml file. Properties like Title and Author then could be added easily.
Is it possible to persuade the stream result to download an entire directory and it's contents? And if so, how? I've no problem getting it to download individual files, but I have a need to download a series of files that must be in a specific directory structure.
I don't think so.
Stream result allow you to download ONE content, with its MIME type, its name, etc.
This makes it impossible to work with a lot of files, with different names and content type.
What you can do is:
Render in a JSP the list of files (in anchor tags for example), everyone targeting the Action that will download that single file;
Call multiple Actions via scripting opening multiple pages (target="_blank") for every file you have (dangerous, annoying, almost useless...);
Create a zip with Java in server side, containing all your files and directories, then output the zip with Stream result.
I think you may consider the third option.
Does anyone have some sample code demonstrating how to make a "file browser" view? I'd like to be able to navigate through directories and drill-down the sub-directories and see files located within the various folders. I want the user to be able to create new directories/files and even select an existing file. Is there sample code out there already available to do this?
I don't know about sample code, but this wouldn't be too complicated to achieve using NSFileManager and a UITableView.
You can obtain arrays of directory contents using the subpathsOfDirectoryAtPath:error and associated methods of a file manager. These arrays in turn can populate a UITableView. It would be fairly easy to put together a navigation controller that could display a series of table views showing a file hiearchy.
Bear in mind, however, that you'll only be able to access the directories inside your application sandbox, unless you're running on a jailbroken device.
The iOS programming guide says that
You should never present users with the list of files in this directory and ask them to decide what to do with those files. Instead, sort through the files programmatically and add files without prompting.
This is assuming you are trying to implement file browse feature for your documents directory.
I'm an author of FileExplorer which is a file browser for iOS and fulfills most of your requirements.
Here are some of the features of my control:
Possibility to choose files or/and directories if there is a need for that
Possiblity to remove files or/and directories if there is a need for that
Built-in search functionality
View Audio, Video, Image and PDF files.
Possibility to add support for any file type.
You can find my control here.
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.
I have a upload text file field, and with it I plan to save the file somewhere and then store the location of the file in a database. However, I want to make sure the file they uploaded is a .txt file, and not, say, an image file. I imagine this happens in the validation step. How does one validate such a thing? Also, how do you get the filename of the uploaded file? I could always just check if it said '.txt' but for future reference knowing how to validate without just the filename would be helpful.
Trying to validate the contents of a file based on the filename extension is opening the door for major hackerdom. It's trivial to change the extension and upload the file.
If you are on a Mac/Linux/Unix-based system the OS "file" command is the standard because it looks inside the file for key bytes that flag file types. http://en.wikipedia.org/wiki/File_(Unix) I'm not sure what's available for Windows, but this might help: Determine file type in Ruby
One way of doing it, the simple way really, would be to pass the file through an image loader, preferably one that handles multiple common formats, and see if it throws an error.
The other way is to manually check the file header for common image format headers. For example, .bmp files start with BM. Other formats have their own specific markings you can use.