Home > Computers and Internet > Recycle Bin Mystery

Recycle Bin Mystery

The other week, one of the Windows Server 2008 R2 servers that my team was supporting was rapidly losing disk space.  What was particularly worrisome was that we could not determine what was causing it.  We had to babysit the server 24 hours a day for a few days, freeing up disk space by deleting files and moving off log files to another drive; this firefighting work was not amusing.  It came to a point when we could neither delete nor move off files from the drive anymore.

One of the things one of my team stumbled upon by chance was certain folders inside the Recycle Bin of the drive that was losing disk space, either had large disk usages or were suddenly gaining in size.

Example folders from the Recycle Bin

To display the folders in the Recylce Bin, go to Control Panel > Folder Options > View, and select the Show hidden files, folders, and drives option and uncheck the Hide protected operating system files (Recommended) option.

One thing we learned as a result of researching what these were was that each folder represented the Recycle Bin of a user who has previously logged into the system.  In the case of the screen shot above, the Recycle Bins of the other users are represented by their SIDs; in our case we saw these folders also labeled as “Recycle Bin.”

Some application or process in our server was deleting files, but apparently it was not really deleting it but just moving it into the Recycle Bin.

In the interim, we decided to delete the Recycle Bin folders that consumed the most space, and this workaround bought us more time to investigate the problem some more.

To determine what this application or process could be, I used a Microsoft Sysinternals tool called Process Monitor to list down all the processes that were currently running in the server, and to display which one was doing a lot of reads and writes to the disk.

We found out that there was a scheduled task that was running that had a lot of reads and writes to the disk, and this gave us a clue on where to look next.

Upon opening Task Scheduler, we saw a task created by one of my team that was scheduled to run everyday.  My team member setup this task to auto-archive and delete the log files we were collecting as part of our daily performance monitoring work.  I asked my team member to login and look at his scheduled task some more, and it was then that we saw that his Recycle Bin was full!

So, at this point we have identified the user profile whose Recycle Bin was filling up with files that were consuming disk space, and we’ve narrowed down the suspected cause to the scheduled task that was set to run daily.

The scheduled task involved copying the log files we needed, compressing them using WinZip, moving the compressed files to another drive, and then finally deleting the log files copied.  Instead of using the DEL command to delete the files, however, we relied on a command-line switch of WinZip to delete the files — and there was the problem!  WinZip was “deleting” the files, but it was sending these files to the Recycle Bin instead of really deleting them, which is likely by design.  (Of course, “deleting” a file is really just removing the file’s entry from the file system; the file is still there until it gets overwritten by another file, or the disk is securely wiped.)  We solved our problem by using the DEL command of the operating system to delete the files instead — and with that action, no files were sent to the Recycle Bin.

The problem was solved by a combination of finding out what process was doing any deletes, and correcting the script (the process) we used to use Windows’ DEL command to ensure the files that needed deleting were indeed deleted and not sent to the Recycle Bin.

On a personal note: I was supposed to be on vacation during the particular week that this problem happened, but my boss asked me to defer my leave to continue providing support for this particular week in our release.  I’m actually glad I was working this particular week, otherwise I would have missed this opportunity to learn something new about Windows, and the need to be careful with the file system operations we perform (i.e. be careful in using a third-party application to do a task that the operating system can handle well with its built-in commands).  It was troublesome doing the firefighting work that we did, but when we finally had time to dig deeper, find the root cause and solve the problem, the effort we put into it and the lessons we learned from this experience were all worth it.  Thank You, God, for Your guidance in this matter; I and my team literally could not have done this without You!

Advertisements
  1. No comments yet.
  1. No trackbacks yet.

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: