Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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?

share|improve this question
up vote 2 down vote accepted

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.

share|improve this answer
So you suggest being very careful? What does that mean at all? Unit test? Validation? What if you want to delete files which you haven't created? What about memory corruption? Imho, if there's a file in your app's temp directory and you delete it, it's the user's fault. – Falcon Aug 17 '11 at 13:13
hehe, that's life. – Falcon Aug 17 '11 at 13:20
@Falcon - You might not want to write your temp file to the default local temp folder, you may actually want to write it to the same location as the data file. Consider a temp file which needs to be bigger than the free space on your local drive, so you need to use a network drive with more free space. – Mark Booth Aug 17 '11 at 13:43
@Falcon - Also, the nice thing about the build a list of things to clean up method is that is is incredibly unlikely that memory corruption could lead to the deletion of unexpected files, it is much more likely that your delete would fail, especially if you are calling single-file or single-directory delete functions (so a corruption including a wildcard wouldn't do something unexpected either). – Mark Booth Aug 17 '11 at 13:48
I agree and usually I don't downvote at all if the post isn't really, really crappy. So I revoked my downvote (that's why I hat to edit your post). TBH, I wholeheartedly agree with your answer and an application should manage that. But I strongly believe that it is overkill and the unexpected events should be covered by filesystem permissions. Have you ever tried to deinstall Oracle? And I strongly believe that it's the user's fault if he puts files into locations where they obviously don't belong, like your app's temporary folder. – Falcon Aug 17 '11 at 13:49

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.

share|improve this answer

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.

share|improve this answer
Can anybody explain the downvote? Protection of files is clearly the responsibility of the OS/file system. – Falcon Aug 17 '11 at 10:46
If your app has such a bug in the first place, chances are that it slips through the validation anyway. I never said you shouldn't validate. All I said is that the best line of defense is a proper setup of file-system permissions. – Falcon Aug 17 '11 at 10:54
+1 I totally agree. Protection of critical files and directories must be the responsibility of SyaAdmin setting up OS. – treecoder Aug 17 '11 at 12:07
@Mark Booth: Please see my edits. – Falcon Aug 17 '11 at 12:16
@Mark Booth: Well, show me an example of how you validate file/directory deletions then. – Falcon Aug 17 '11 at 12:51

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.