Do you do any validation on directories when recursively deleting them?

Question

How do you recursively delete paths of the data that your app created?

The deleting process itself is trivial. The question is, do you do extra validation? And if so, what kind?

From one point of view, maybe it's simply an uncomfortable task to do, but on the other, imagine if the program has a bug and something passes "c:\" to the recursive function, or if there is a memory overflow and some data becomes corrupt, causing paths you work on to be truncated etc.

Is there even a way to do a clean validation?

Answer 1

I would suggest that you use a thread safe stack to keep track of all of the specific temporary files and directories that you created and in what order.

After completion of processing (or during exception handling), you then have a complete list of actions to perform (in reverse, hence using a stack) to roll back to the previous clean state.

Note that only files and directories you actually create should go on your clean up list. If you go to create C:\Temp\MyApp, and it already exists, you shouldn't try to delete it afterwards after, even if you normally would. It is possible that someone may have placed other data that you didn't generate in that directory.

---

Overall, you should be very careful about deleting temporary files and directories, especially if you are doing so recursively and even more especially if they are out side of the OS temp directory.

If you are not absolutely sure that you created something, you are better off not deleting it.

A user might get annoyed with a few extra temporary files that you didn't properly clean up, but they are likely to be angry if you delete files they actually wanted to keep.

Also, if a bug in your application causes all of the users data files to be deleted, you could be considered professionally negligent and in some places that might be lead to an actionable legal case for damages.

Answer 2

I think validation should always be in action, but not for every folder you try to delete, just for the top level folder, to get sure that you haven't by any accident issued the deletion command for c:\windows\system32 for example.

However, you don't write the delete method in many frameworks and you simply call a function of the library you use. For example, in .NET you simply call Directory.Delete(path, true) and the second argument specifies whether you want a recursive deletion or not.

If the framework you use has a built-in mechanism, then simply trust it. Because I/O operations are tested millions of times in different applications.

However, if you want to create your own implementation, then still I recommend validate the path before each delete action.

Answer 3

In my opinion, it's primarily the responsibility of the operating system to prevent undesired deletes.

The most important folders are write-protected by windows 7 for example. Deleting them will fail with an exception. On Unix, you'll have to make sure appropriate file-system permissions are in place and you can't do much harm.

However, we all know a sysadmin who told us the story of his accidental rm -rf / command, issued as root.

As for applications: Make sure the filesystem-permissions are setup reasonably, then you can prevent at least some harm. It's a best practice to run applications with the least privileges necessary.

If your program needs to be run as root, for whatever reason, then throw in some code to check if the location to be deleted is not critical to the system. Or chroot the system for the application.

You could also white-list the directories that are allowed to be deleted and double check everytime, if that makes you feel safe. But memory corruption for example has a chance to break through any validation-routines. If you have temporary data, keep it in a wellknown folder and don't distribute it accross the system.

Edit: Now I've been talking to various co-workers of mine and we inspected our codes and guess what: All of the directories we are deleting are hard-coded constants. There're only a few cases in which files are deleted, mostly by extension or the name they start with. So in most of our cases another layer of validation is simply pointless and a unit test is enough to make sure that the right directory is cleared or deleted.

Now, there might be other cases where paths are combined with environment variables and so on. But when the environment variable is set to the wrong value and you hit by accident a directory which shouldn't have been deleted, who should've kown that but the sysadmin? Clearly, this falls in his responsibility then.

The only edge case I can imagine are deletions by regular expressions. But what good are regular expressions for deletion when you want to validate by white listing file names? Or what good are validations by regular expressions when you're deleting by regular expressions?

The only case in which I'd recommend some sort of whitelisting validation is, when you are blindly concatenating strings to create a directory name. But I'd rather have a decent unit test for it.

And protection against memory corruption: Well, there's little you can do, because you cannot guarantee any behaviour whatsoever when that strikes.