A month or so back, I untarred the Linux source in a folder in Cygwin (I was curious as to whether or not it would compile with MinGW 'cause my other computer running Linux is a slow single core Sempron). I tried deleting it, but there's 1 file left, and it will not delete...

Cygwin resides in C:\cygwin, and I untarred the source in C:\cygwin\src\linux-3.7.1. It didn't compile... So I tried deleting the folder. It was going well, until at the end, when I realized not all files are deleted. I tried deleting linux-3.7.1 folder again, and an error popped up:

Item not found

I opened the folder, and found that there's 1 source file left: aux.c, which is in C:\cygwin\src\linux-3.7.1\drivers\gpu\drm\nouveau\core\subdev\i2c\aux.c.

It will not:

  • Delete
  • Open
  • Move

General properties:


Security properties:


How do I remove this file?

  • Alright, running it at the moment – Alex Feb 19 '13 at 0:52
  • Done, didn't work though... – Alex Feb 19 '13 at 0:55
  • 1
    Should not work. The inability to delete it from inside DOS/windows is as designed. Thus it is not an error which you can fix this way. – Hennes Feb 19 '13 at 0:56

Try this from an (elevated) command prompt:

del \\?\C:\cygwin\src\linux-3.7.1\drivers\gpu\drm\nouveau\core\subdev\i2c\aux.c
| improve this answer | |
  • Ok aux.c is deleted, but now the `src` folder is apparently in use when I try to delete that – Alex Feb 19 '13 at 1:02
  • Nothing hidden inside it? Perhaps rd /s /q \\?\C:\cygwin\src will help. – Karan Feb 19 '13 at 1:04
  • Prints output that `src` is in use – Alex Feb 19 '13 at 1:06
  • 2
    Karan: Oh, clever. Avoiding the normal filesystem namespace. @Alex Yan: No cmd window open in the folder? – Hennes Feb 19 '13 at 1:06
  • Yeah, rd should do the trick unless something's grabbed hold of the folder, or a file inside it... Close all other open windows/apps, and check src's Properties. What's the size and number of files inside shown? – Karan Feb 19 '13 at 1:07

The problem you ran into is due to ancient DOS reservations.

Files in the list below had special meanings. Part of that is still present in modern day windows versions:


The easiest way to delete them is to boot an operating system which does not treat these filenames as special. (e.g. boot any non-windows liveCD).

[edit] Tests done on win7-x86 ultimate:

Creating a simple test file:

S:\>copy con foo.c
        1 file(s) copied.

Checking the contents:

S:\>type foo.c

Now with aux.c

S:\>copy con aux.c
The system cannot find the file specified.
        0 file(s) copied.

It seems parts of windows still is backwards compatible.

| improve this answer | |
  • But this file is aux.c – Alex Feb 19 '13 at 0:57
  • 3
    It still starts with aux, and old filename style is "Filename" dot "extension". And I just tested copy con aux.c on win7 and it failed. (copy con test.c does work). – Hennes Feb 19 '13 at 0:58
  • Wow I just stumbled upon this. They should at least update the error message! – Mark Sep 19 at 2:57

In this case it was obviously about the special meaning of aux inherited from DOS times, as Hennes pointed out correctly. However, for the readers stumbling over this in future I would like to add another possible case where this behavior can be seen.

That's when a file was created with a trailing dot. There are more exotic cases as well. But filename.ext. would be such a filename and could not normally deleted from the Win32 subsystem. This is where the trick from Karan comes in. S/he uses a name that before being passed to the layer below the Win32 subsystem will be changed from its \\?\C:\... form to the "native" (this is also how file system filter drivers see it) form \??\C:\.... Whereas depending on the version of Windows this can be a so-called object directory (use WinObj from Sysinternals/Microsoft to peek into the object manager namespace) or a symbolic link (not to be confused with the identically named entity in NTFS since Vista) to another object directory such as \DosDevices. The latter is merely one name and describes the part of the object manager namespace visible to Win32 processes by default. For more details check out the book series Windows Internals or read up on path parsing in particular over on Google's Project Zero (The Definitive Guide on Win32 to NT Path Conversion). In particular you may want to pay attention to the difference between Win32 File Namespaces and Win32 Device Namespaces.

Now how can such a file be created in the first place? There are several possibilities.

  1. a Win32 program that employs the \\?\X: prefix for path names in order to extend the available path length from 260 characters to approximately 32767 characters (see footnote 1!) created the file in the first place, thus circumventing some limitations of the Win32 subsystem.
  2. a program rooted in a different subsystem. The former POSIX subsystem (later Interix now SUA), the OS/2 subsystem (long gone, but used to exist on NT 3.51) or some layer that isn't exactly a subsystem in the Windows sense (Cygwin, to my knowledge) created the file or folder. Similarly WSL (Windows Subsystem for Linux) on Windows 10 is now another candidate.
  3. a different operating system created it (parallel Linux boot, for example).
  4. it's a file on a network share located on a non-Windows server.

The last two points also hint at one of the mentioned remedies: boot a non-Windows live CD and remove the file(s).

The issue can actually compared to the case where an old non-Unicode Win32 program is confronted with filenames from multiple code pages. Oftentimes it won't be able to "find" some of them, because each respective ANSI codepage can only fit 256 characters, whereas UTF-16 (not its subset UCS-2, however) can theoretically encode a virtually unlimited amount of code points (read up on the topic over at unicode.org and Wikipedia).

Hope this helps understand the underlying issues a bit more. Didn't want to edit this long answer into one of the other answers, although it only complements them. The other answers are perfectly valid without this one.

Footnote 1: the maximum amount of characters in the path is not absolute because a path that is close to the absolute maximum (32767 characters) may well get expanded by both the object manager and file system filters or file systems themselves (e.g. reparse points).

| improve this answer | |
  • I love the added technical background. – Hennes Feb 19 '13 at 15:46

I had this issue and was very frustrated, nothing worked. Then, I used a Linux Ubuntu CD. Booted from CDROM, went to demo mode, accessed where the troublesome files were and simply deleted them. It works like a dream.

| improve this answer | |
  • 1
    Be aware, that the reason for Windows not being able to delete a file, can be the fact that characters not allowed in Windows has been put into the filename on Linux. I am pretty sure it's not because Linux don't care. I asked the moderators to approve removing some of the text and keep the part that is usable. – Mogget Nov 7 '13 at 3:57

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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