I/O Performance Sanity Check - Checking for a file's existence

Question

Are you aware of any serious performance problems with checking if a file exists before you open it and send it? The context for this is a web application that serves up files dynamically via an ASP page. I was told that there is no check for whether or not the file exists because the database stores this information and shouldn't be wrong. It is of course sometimes wrong for any number of reasons so we end up sending back nothing leaving the user unhappy.

My instinct is that checking for a file's existence is so cheap that you shouldn't worry about it but I was told otherwise. Our storage solution is a pretty high powered one (not just an IDE drive on the web server) if that helps. My question is basically: Is my instinct correct?

Thanks!

Note: These files are never just deleted. Something has to go wrong for them to be missing but this happens a few times a week. Also, the reason I want to check for a file's existence is because I can return an alternate asset that is on disk so I'd like to be able to have that logic all in one spot rather than deal with catching an exception and dealing with that in that context.

Answer 1

You shouldn't experience any serious performance issues so long as you're not using some sort of really weird storage scheme.

Answer 2

I'm not aware of any major performance problems with this approach, but checking for a file's existence before opening it can have unexpected results (another process can delete the file between the check and opening it).

Answer 3

If the file not being there is an exceptional circumstance (as you say the db is always right), you should not check for it.

If its not there you get an exception and handle it accordingly. That seems to be the way you say the system works, and I would handle it as such.

One more note, If your saying that a file not being there when opened is just returning nothing, then that tells me there is a design flaw in your exception hanlding, and your lower level is not bubbling the exception far up enough to be properly handled so you can convey an error message back to the client.

With proper exception handling/bublling you should have no problem returning an alernate asset. Rethink your exception handling rather than redesigning the way the system is supposed to work.

Answer 4

Even if you check it exists just before you try to serve it, it could be deleted between the check and you serving it.

The problem here is that you send back nothing if you can't serve the file. Trying to serve a non-existent file should throw an exception (or whatever the equivalent is on your platform) - you should handle that exception by returning an appropriate "Sorry, we couldn't find your file" error page.

Answer 5

I really don't know if it is a cheap or expensive task, but, considering that not checking for the existence of the file could result in an unpleasant response to the client I would say it's not expensive.

I do have some web apps where I check for file existence and is working just fine.

Answer 6

Are you redirecting to the file, or reading and serving up the contents of the file through code?

If the first, what happens if the file for some reason doesn't exist? Standard 404 error, or do you have a specialized error page? Is that acceptable for that case?

If the latter, simply open the file and handle the exception appropriately.

Answer 7

File IO is generally costly in comparison to database or in-memory reads, but I have heard the old "the database stores the information so it shouldn't be wrong" too many times when hunting down a system crash or unhandled exception. So I would check for existence and recover elegantly unless your performance requirements are unusually high.

Answer 8

If not checking for the file causes confusion for the user and/or doesn't give them what they need, or at least display an error message indicating the problem - then it doesn't matter what the cost is.

The application needs the check.

Ron

Answer 9

Performance wise there should be essentially no impact. The slow part here is going to disk to read a file header, but if you're going to load the file you'll have to do that anyway and any decent storage system (pretty much any one from the past couple of decades) will cache the read from the check so that part of the read is much faster when you actually open the file. Having said that, I agree with mattlant that it would be generally better to catch the file not there exception and deal with it properly if the file is generally expected to be there.

Answer 10

If you're going to open it immediately after then checking for it's existance is essentially free.

Answer 11

Try opening the file and then streaming it. Is that a possibility? That way if you're unable to open and stream it then you will be unable to send it and can action the appropriate error handling.