Rob Brooks-Bilson
Tech, Photography, Stuff
More on ColdFusion 9's Virtual File System: Dealing with Directories and Files
July 14, 2009
In a previous entry, I introduced ColdFusion 9's new RAM based virtual file system (VFS). One question that came up over and over again was how long files stored in the VFS persist. That's a pretty straightforward question. The answer, however, isn't quite as simple. Right now, as of the initial public beta of ColdFusion 9, files saved to the VFS persist until server restart. Obviously this isn't an ideal situation in all cases.
There are a few items you should consider when working with the VFS in ColdFusion 9 when it comes to file and directory persistence as well as security. First, a directory must first be created in the VFS before you can write to it.
1<cfset content="This is a test">
2
3<cfdirectory action="create" directory="ram://myDir/mySubDir">
4<cffile action="write" output="#content#" file="ram://myDir/mySubDir/foo.txt"/>
2
3<cfdirectory action="create" directory="ram://myDir/mySubDir">
4<cffile action="write" output="#content#" file="ram://myDir/mySubDir/foo.txt"/>
By default, any directory and any file in the VFS can be read or written to by any .cfm page or CFC. If you need to create a secure VFS environment, you can do so using sandbox security through the ColdFusion Administrator. I won't go into the details here as it's covered in the beta documentation.
The next issue to be aware of is that currently directories and files in the VFS persist until the server is restarted. I'd be surprised if ColdFusion 9 ships this way as I see it as risky to allow anyone on a server (especially a shared server) create as many files/directories in RAM as they want to. Sandboxing prevents people from gaining access to files and directories that they shouldn't have access to but it doesn't prevent them from denying access to system resources by unnecessarily leaving virtual files littered around the server. I don't know how the ColdFusion Engineering team is planning to deal with this, but I would think at a minimum they would provide a server wide setting in the ColdFusion Administrator letting a server admin specify how long files/directories should be allowed to persist in RAM before the server runs a job to delete them. Which brings me to another point - if you're planning to read/write files to the VFS you need to make sure you always verify the existence of a directory or file before you try to read it - especially if Adobe adds a server-wide way for an Admin to specify a timeout for virtual files.
If you want to see what files are currently stored in the VFS on your server, you can use the cfdirectory tag like so:
1<cfdirectory action="list" directory="ram:///" name="myRamFiles" recurse="true">
2
3<cfdump var="#myRamFiles#">
2
3<cfdump var="#myRamFiles#">
To delete files, you can either use the cffile tag with action="delete" or you can use the cfdirectory tag to wipe out an entire directory worth of files at one time.
I hope this helps clear up some questions that aren't directly answered in the current beta documentation. If you have other questions about the new VFS, let me know.
TweetBacks
7/14/09 7:36 PM
I fail to see a useful use case. Seems like it is about the same as storing the file object in a struct in application scope.
7/15/09 7:55 AM
@Rob:
My understanding was that one of the primary reasons for adding the VFS was for the benefit of all of the frameworks that end up creating temporary files based on XML files. If files were to be deleted automatically, then that's going to obviously conflict with the original purpose of the VFS.
While I haven't played around w/the VFS, I wonder how secure it is. I wonder if they'll be issued in shared environments with the files being available to all users. Is the VFS isolated per application namespace?
7/15/09 8:56 AM
@Henry, there are several good use cases. Right now, you can't dynamically generate a file such as an image and include it in a page without first saving it to the file system. The VFS lets you do this. It's also handy if you store code in a database that you want to execute without first having to write it to a file before being called or included. Also, see Dan's comment below RE frameworks.
@Dan, that makes sense (the framework comment). As for auto-cleanup, I can see the conflict you're talking about. I need to check to see how Railo is handling this now since they also support a VFS. I still think file clean-up is an issue that needs to be addressed.
As for security, you can apply sandbox security in the cf admin just like you can to other drectories/files now. By default, nothing you write to it is secure, so it'll require a fairly active effort to make sure it's being used securely if that's what you need for an app.
7/15/09 9:42 AM
I agree I'd like to see something done for auto-cleanup. What I'd love to see is some kind of expires functionality when writing a file--something that could be used with the VFS or file system. Where you could set an time span for when the file expires. They essentially already have something this in place for things like CFCHART (which expires temporary images.)
This would certainly simplify clean up of files both for VFS and disk operations. While the inclusion of the VFS is nice, it won't necessarily be the best choice in all situations. If you're end up needing to create large temp files, then the VFS might not be the best place for these since you can easily eat up RAM. However, if you could write the file to disk and have CF automatically remove the file for you after a certain amount of time has passed--that would be extremely convenient.
7/16/09 9:16 AM
Generating an image with cfimage and then sending it to the browser directly - there 'is' a way -but I do see the usefulness of this feature for tags that do not allow you to do so.
<cfheader name="Content-Disposition" value="filename=myimage.png">
<cfcontent reset="yes" type="image/x-png" variable="#ImageGetBlob(myImage)#">
7/16/09 11:58 AM
Thanks Paul. Serving up an image was probably a bad example.