by Eric Bright
Updated on July 07, 2018
Objective: removing an apparently irremovable file or folder.
Affected OS: Windows 2000, XP, Vista, 7, and newer versions
You’re given this message:
“Cannot read from the source file or disk.”
Possible “solutions” that might not work:
- You tried to find how to delete it; you googled it, read all newsgroups, posts in some professional forums, asked your friends, downloaded
IObit Unlocker (and an article about it), EMCO MoveOnBoot, LockHunter, CopyLock, KillBox, Delete Doctor, Deleting Invalid Data Files [see the end of this page for more information on this program; this program is more than what you may guess], DeleteFXPFiles, and Unlocker (it has an x64 version too and a Win7-x64 works only with the x64 version of Unlocker), installed, and performed what they suggested; and finally frustrated by failure.
- You downloaded Process Explorer and examined every single process running in memory to find a sign of a program that may be using _something_ in that folder. You closed all programs, every resident applications, and all running processes that can be closed. You also closed even some of Windows process and stopped as many services as possible; no sign of any file handle to anything related to that folder… result: negative.
- You have uninstalled many programs that you suspect they may cause the problem;… negative.
- You booted up in Safe Mode, tried to EndTask explorer.exe while doing some hacks in cmd prompt like deleting the folder and…
- You read “How to Delete a Locked Files,” “How to delete a file when…,” and “How to delete locked files on Windows 10” article;… negative.
- You tried to do “Open with…” then created a file with the same name, saved over the existing one… with no luck.
- You did chkdsk c: /f, RegSeeker, NortonDiskDoctor, Regedit (see also this), and lots of command line instructions that you read in forums;… negative (in regedit, you cannot even see any entry with the same name as that stupid file in your Windows registry.) (more about chkdsk.)
- You have tried ShellExtensionsView (or its LiberKey portable version) to disable the suspected PGP context-menu plug-in, which sometimes causes some problems; … negative.
- In the end, before installing a fresh damn Windows, why don’t you try this one:
[on Windows XP]
C:\Documents and Settings[your log-in name]\Desktop\>RD /S /Q foldername
[on Windows 7]
C:\Users[your log-in name]\Desktop\>RD /S /Q foldername
Another example: assume I have such a bad folder on my desktop; its name is StupidFolder, and there is a file inside it, named BS. with a zero length and no other retrievable properties, or perhaps it has a creation date; assume that my log-in name is eric and we are on a Win 10 system. Now:
- Run -> cmd.exe
- cd c:\Users\eric\Desktop\
- rd /s /q stupidfolder
Be very careful with what you are doing, otherwise, you may lose everything on your desktop. The path of the command must be correct. Please double-check the spelling before pressing the [Enter] button. If you are not sure about what is going to happen or if you don’t know whether the path of the StupidFolder is correct, DO NOT DO WHAT I SAID. If you lose your valuable data, nobody, including me, would be responsible, but you yourself.
A little background about RD command
It was also easy to RemoveDirectory(s) with the following command:
However, the directory that you had attempted to remove had to be “empty,” otherwise, you could not remove it. You also “could not delete” a directory with the following command:
because the delete command could work only on “files” not “folders.” Then, when your folder was not empty, you first had to go inside that folder, delete everything, come out of the folder, and finally remove it. Still, if there were “many” folders inside one another residing in the main folder that you wanted to remove, you had faced a nightmare.
Luckily, there was a solution to that: deltree. It was not a native command of command.com (command.com was a kind of the kernel of the operating system). It was an external file that you could obtain from elsewhere and use it for that purpose. Then your computer could automatically go to the deepest directory, delete everything in it by this command:
(without asking permission from the user except once at the start time) and remove every directory that may be there by an rd command, come up by one sub-directory and repeat these steps again up to the first directory.
When Windows came to the scene, things got changed; directories turned to folders, and rd (remove directory) and del (delete or erase) and deltree merged down to one command: delete. Therefore, you became able to delete a directory, read a “folder” now, regardless of if it has any sub-directory(s) or files inside, and there was no difference between a folder and a file for the purpose of deleting anymore; you could delete a folder as well as a file, a task that was two different tasks in MS-DOS time.
Since the emergence of Win 2000, the external command of deltree went inside the RemoveDirectory command as its switch or parameter, named /s. Then we have had this command:
rd /s [drive:]path
that does this:
It “removes all directories and files in the specified directory in addition to the directory itself. Used to remove a directory tree,” its help says.
- RD and RMDIR are identical commands
- You can also use it this way if you don’t like working directly with cmd.exe:
cmd /C RD /S /Q C:\Users\eric\Desktop\StupidFile
but, replace the username and StupidFile with your own stuff. So the general command would be:
cmd /c rd /s /q [drive:]path
- Generally speaking, no file in the destination path must be currently in use, which means if the path is not empty, no program must be using any file(s) from inside of it. That is why we say, ‘close all applications; even go to task manager and close every program that you can (not the windows itself)’
- If you considered the above-mentioned item, it would be much better to even End Process Tree of explorer.exe from your Task Manager; while in Task Manager, go to the tab that is called “Processes, then right-click on explorer.exe, then choose End Process Tree. Doing this, you make sure that at least there is no open file handle from explorer.exe to anything inside the StupidFile. When you finished, you can bring your explorer (and your desktop) back by ‘File -> New Task (Run)… -> explorer (and [Enter], of course!)
Received comments – Adaptations, Hints, and Tricks
I received great comments full of love. I also love you all, my friends. In some of the received e-mails, I got some variations of the rd method that I would be honoured to share with you.
An adaptation by Uhl Albert:
I had tried a bunch of solutions from your page (and elsewhere) but none of them worked. This is what finally did it for me:
- Log into Windows as another user [must be a user with all administrative privilege]
- Open Windows Explorer and navigate to: c:\Users\UserName <–user name with the bad files
- Go to Tools Folder Options and click the View tab. Make sure all settings that hide files are turned off. You want to make sure all files are visible before the next step
- Move all the files in the Desktop folder to another location (well all except the problem files. If those could be moved you wouldn’t be in this predicament!)
- Open a command prompt and navigate to the above location
- Enter this command which deletes the Desktop folder and its contents: RD /S Desktop
- Create a new Desktop folder
- Move everything back
- Log off, then log in again as the original user
My complementary notes on the adaptation:
When you are using this method, you should have Administration privilege. Otherwise, you would never be allowed to delete the actual Desktop folder of any user in any circumstance.
The problem of more-than-8-charts-long names: Noticed by Nicolas Huguenin
… the folder I wanted to delete had a very long name (two times wrapped in the CMD) so I wasn’t able to delete it with its long name using the rd command. But using first a dir /x to get the 8-chars name of the folder, I could finally remove it with the rd /s/q.
You may want to add that trick to your otherwise great tutorial, as many of the “young” users might not even know that one day (not so far ago) all names were 8-chars max ;)
My complementary notes on the trick: What does dir /x mean?
Well, it is a wise move. Because there are always some instances of horribly-long file-names with lots of symbols and spaces in them. This would make applying rd impossible for folders with space in their names. This makes applying many other MD-DOS commands impossible too.
- I created a folder on my desktop called ‘Stupid Test’. Note that there is a space between Stupid and Test
- Now I want to remove this folder with rd command. Then I write:
C:...\Desktop>rd Stupid Test
And I receive the following messages (one message, two times):
The system cannot find the file specified.
The system cannot find the file specified.
What is the problem? The ‘Stupid Test’ folder is there. Then why the rd command cannot find it? The problem is that the rd command interpreter, like many other MS-DOS commands, cannot understand the space in the name of a file or a folder. It looks for a folder with the name of ‘Stupid’ and a folder with the name of ‘Test’, but does not look for a folder with the name of ‘Stupid Test’. Then it says, ‘the system cannot find the file specified’ two times, once for each part of the name. This behaviour is ridiculous, isn’t it?! Yes, it is, I believe, and so did guys in Microsoft.
Years ago, names of folders couldn’t be longer than 8 characters, because of some profound restrictions in the available ‘file management’ system, and names also couldn’t bear any space in them. They also used to be started with a letter, not a number. We also couldn’t have some symbols in the name of a file or a folder. It sounds awfully restrictive. Then Microsoft changed everything and removed this absurd limitation in its later operating systems, i.e. in its file management system.
However, for the sake of some backward compatibilities, Microsoft decided not to set MD-DOS commands totally apart. So, This problem is inherited from MS-DOS to its descendants. Today, still some of the MS-DOS commands in Windows family face the same difficulty that their predecessor had faced. They cannot understand longer than 8-charts names, nor can they understand folder names containing any space.
What is the solution?
Microsoft guys have provided us with a tool to tackle such a complication. The solution is using dir /x.
The purpose of using dir /x is to create 8-charts long MS-DOS compatible file and folder names that are placed in the current folder. If the desktop is your current folder in DOS prompt, then it means dir /x gives 8-charts long names of all files and folders in your Desktop. Then we can use their 8-charts equivalents with all spaces eliminated and long names shortened up to 8 characters. For instance, a name like:
would be contracted to: ‘TEST12~1’, or a name like: ‘123456789 123456789 123456789’ would be contracted to :
‘123456~1’. By doing this, we have 8-charts long names without space in them that can be understood by many MD-DOS commands in Windows family, let say in Win XP.
Now, let’s go back to our ‘Stupid Test’. Assume you are in your Desktop (that means your current folder is C:…\Desktop):
- To see what exactly dir /x does, type ‘dir’. You’ll see a list of the names of all files and folders on your desktop, and you’ll see our ‘Stupid Test’ folder there as well
- Now, type: C:\...\Desktop>dir /x. You’ll see, again, a list of the names of all files and folders on your desktop, but all longer-than-8-charts names are also given their 8-charts long equivalents this time. So you’ll see that our ‘Stupid Test’ folder has the 8-charts name of ‘STUPID~1’
- Again, try the rd command, but this time give the contracted name:
(the command is not case-sensitive!)
Gratefully, you can get a software named Delinv File. It is also created to delete non-deletable files and folders that show the same symptoms. The author of this program appears to have the longer-than-8-charts-in-name problem in mind. However, you are advised to be careful when you are using this program, and any other program with the same forceful functions, since you may mistakenly delete a wrong file or folder (your whole Desktop, for example). In many cases, once a higher order change is finalized, it would be almost irreversible (at least for novice computer users).
I got an e-mail from the creator of Delinv File, Jim Lawler, in which he explains how the problem with accidental deletion of stuff is partially dealt with in the latest version of the software. Jim has added still another level of confirmation when a folder is selected to make it even harder for one to accidentally delete things. Though the software recently got commercialized, the good news is that the commercial version still contains perfectly-working functions of the original non-commercial version for free. That is really kind of Jim; thank you Jim!
My special thanks go to Uhl Albert and Nicolas Huguenin for sharing their experiences with you and I. I am also thankful for Jim Lawler’s informative e-mail (he is the programmer of Delinv File). He informed me of the latest changes in his useful software, and he gave me some feedback on this writing too.
(last update – July 07, 2018. Changelog: updated broken links, corrected typos, I know. Typos never die. 🤦)
(15th update – January 30, 2018. Changelog: updated broken links, updated for Windows 10, several formatting and typographical improvements)
(14th update – November 11, 2014. Changelog: corrected typos and mechanical errors)
(13th update – March 11, 2014)
(12th update – June 07, 2012. Changelog: updated the external links; added new links; added new applications; minor error corrections; minor extra clarifications; minor textual adjustments)
(11th update – August 25, 2011)
(10th update – January 02, 2010)
(9th update – March 26, 2009)
(8th update – January 23, 2009)
(7th update – October 22, 2008)
(6th update – August 19, 2008)
(5th update – March 26, 2007)
(4th update – March 07, 2007)
(3rd update – December 21, 2006)
(2nd update – February 20, 2006)
(1st update – November 02, 2005)