views:

301

answers:

3

Recently I was working on displaying workflow diagram images in our web application. I managed to use the rehosted WF designer and create images on-the-fly on the server, but imagining how large the workflow diagrams can very quickly become, I wanted to give a better user experience by using some ajax control for displaying images that would support zoom & pan functionality.

I happened to come across the website of seadragon, which seems to be just an amazing piece of work that I could use. There is just one disadvantage - in order to use their library for generating deep zoom versions of images I have to use the file structure on a server. Because of the temporary nature of the images I am using (workflow diagrams with progress indicators), it is important to not only be able to create such images but also to get rid of them after some time.

Now the question is how can I best ensure that the temporary image files and the folder hierarchy can be created on a server (ASP.NET web app), and later cleaned up. I was thinking of using the cache functionality and by the expiration of the cache item delete the corresponding image folder hierarchy, or simply in the Application_Start and Application_End of Global.asax delete the content of the whole temporary folder, but I'm not really sure whether this is a good idea and whether there are some security restrictions or file-system-related troubles. What do you think ?

A: 

First, you have to make sure your IIS worker process has rights to write/delete files from your cache directory (and NOT the rest of your site, just in case)

2nd, I would stay away from using App_Start and App_End, App end to clean up files is not 100% guaranteed to fire, and you could end up with a growing pile of orphaned images.

I would instead make a scheduled process, maybe runs once per hour, or once a day, depending on what you want. And have it check how old each image in your cache is, and if its older than your arbitrary "expiure time" then delete it.

Other than that there's not much to it.

Neil N
+1  A: 

Use the App_Data folder. This folder is inside your application and writable by your app without having to go outside the context of the app, but it's also secured from casual browsing. It's meant to hold data files for your application.

Application_Start and Application_End will only fire once each, so if you need better cleanup than that, I would consider using a cache structure or a simple windows service to handle the cleanup.

womp
Actually I wanted to use some image folder within the structure of my app, just to be able to serve those (although temporary) files. The reason is that the seadragon generates this folder structure which is used by the clients to request the correct part of the image. Is there any advantage of using App_Data folder (e.g. in permissions or something) ?
Thomas Wanner
+1  A: 

We do something similar for creating PDF reports and found the easiest way is to use a timestamp check to determine how "old" files are, and then delete them based on a period of time, in our case more then 2 hours old. This is done before the next PDF document is created, but as part of the creation process. We also created a specific folder and gave the ASP.Net user read/write access to the folder.

The only disadvantage is that if the process of creating PDF's is not used regularly there will be a build up of files, however they will be cleaned up eventually. In 2 years and close on 4000 PDF's we have yet to have an error doing it this way.

Diago
This seems like a good idea, to get rid of old files when creating new ones. Only thing that worries me is the permission thing - I am not sure whether we can do that for all the customers using the product at their web servers..
Thomas Wanner
Generally it shouldn't be a major problem. However as already mentioned you can always use App_Data or a folder within it.
Diago
If you give the users to opportunity to allow uploads into a certain folder, I would recommend to use a virtual directory for security purposes. Keep in mind, that if the files are aviable from extern over a URL, you need to deny "script performance" (or however the property in the IIS is called) to gain more security.
citronas
In my case these will not be user uploads but server-generated images which I have to be able to serve to the users and I also have to preserve their folder structure because of the way the seadragon works. Security is probably not such a big issue here as the wasting of space..
Thomas Wanner