Can I assume nobody deletes user generated content off my server's file system?

Question

Situation

Currently I'm developing a web service in which users can (generally) upload binary files. These files are stored in the file system of the host OS and some additional metadata about the file is stored in another SQL database, including its available version identifiers (a file may exist in multiple versions). From the metadata in the database the local version-specific file path can be derived.

Problem

As of now, when I want to give information about the existence of a specific file version, I only check if there is a corresponding database entry. This simplifies a lot of code for more advanced use cases. That means I will run into an error if the file is still recorded in the database but does not exist any more. Logically this should never happen, but it could easily be deleted by e.g. the admin.

Is it bad practice to assume that server-side file will never be deleted by external forces?

Answer 1

To give you a direct answer to

Is it bad practice to assume that server side file will never be deleted by external forces

It is not bad practice to assume it is unlikely a file will never be deleted (in case it is, which we cannot tell you, this depends on tons of details of the particular case).

However, you always need to implement some error handling strategy for the unlikely event - never ever let your program run into undefined behaviour just because you were to lazy to implement at least some minimal error handling.

Answer 2

This kind of depends on where and how you expect this application to be deployed.

If you control the deployment or can make rules (such as in the form of a "maintenance guide") that those who operate the application must follow, then this is perfectly OK. There are a lot more aspects to this that you might want to consider:

• Could there be a requirement that this webservice should run clustered on multiple servers? If so, how will the file system access work?
• Do these files need to be backed up, and how will that be done?
• How do you ensure there is always enough free disk space to store the files? What happens if there isn't?
• What exactly does happen if a file cannot be found?

There's more to development than just writing code...

Answer 3

As said by Michael, it depends on who manages your environment. There's certainly nothing 100% secure to prevent the accidental or intentional deletion of files that have metadata in the DB.

Unless you really need the files to be accessible in the filesystem, you could consider storing the files in the database as well. This might require some changes in your architecture and/or infrastructure which could incur additional costs (beefier database server), but from a performance point of view there shouldn't be any problems.

Answer 4

Your concern consists of two factors:

Consistent Data: You can ensure that the server code ensures that: file change and DB record update together, is an atomic operation. You can also choose to save the file in db it self, wrapping both operations in a transaction.

Sysops/Devops failures: Minimize accidental deletes of files or records. For serious projects, you can use any of existing distributed file system implementations as a robust storage solution. These handle metadata as well as file storage and querying capabilities.