Why does this file apparently not exist when attempting to delete it?

Solution 1:

Try this from an (elevated) command prompt:

del \\?\C:\cygwin\src\linux-3.7.1\drivers\gpu\drm\nouveau\core\subdev\i2c\aux.c

Solution 2:

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:

CON, PRN, AUX, CLOCK$, NUL, COM1, COM2, COM3, COM4, COM5, COM6, COM7, COM8, COM9 LPT1, LPT2, LPT3, LPT4, LPT5, LPT6, LPT7, LPT8, and LPT9.

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
test
^Z
        1 file(s) copied.

Checking the contents:

S:\>type foo.c
test

Now with aux.c

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

It seems parts of windows still is backwards compatible.

Solution 3:

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).