Почему этот файл явно не существует при попытке удалить его?

Примерно месяц назад я вытащил исходный код Linux в папку в Cygwin (мне было любопытно, будет ли он компилироваться с MinGW, потому что мой другой компьютер под управлением Linux представляет собой медленный одноядерный Sempron). Я попытался удалить его, но остался 1 файл, и он не будет удален ...

Cygwin проживает в C:\cygwin, и я зацепил источник в C:\cygwin\src\linux-3.7.1. Он не скомпилировался ... Поэтому я попытался удалить папку. Все шло хорошо, пока я не понял, что не все файлы удалены. Я попытался удалить linux-3.7.1папку еще раз, и возникла ошибка:

Я открыл папку и обнаружил, что остался 1 исходный файл:, aux.cкоторый находится в C:\cygwin\src\linux-3.7.1\drivers\gpu\drm\nouveau\core\subdev\i2c\aux.c.

Он не будет:

• удалять
• открыто
• Шаг

Общие свойства:

Свойства безопасности:

Как мне удалить этот файл?

Попробуйте это из командной строки (с повышенными правами):

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

Проблема, с которой вы столкнулись, связана с древним бронированием DOS.

Файлы в списке ниже имеют особое значение. Часть этого все еще присутствует в современных версиях окон:

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

Самый простой способ удалить их - это загрузить операционную систему, которая не рассматривает эти имена как особые. (например, загрузите любой не-windows liveCD).

[править] Тесты, проведенные на win7-x86 ultimate:

Создание простого тестового файла:

S: \> скопировать con foo.c
тестовое задание
^ Z
        1 файл (ов) скопирован.

Проверка содержимого:

S: \> введите foo.c
тестовое задание

Теперь с aux .c

S: \> копировать con aux.c
^ Z
Система не может найти указанный файл.
        0 файл (ов) скопирован.

Кажется, что части окна все еще обратно совместимы.

В этом случае, очевидно, речь шла об особом значении, auxунаследованном от времен DOS , как правильно указала Хеннес . Однако для читателей, спотыкающихся об этом в будущем, я хотел бы добавить еще один возможный случай, когда это поведение можно увидеть.

Вот когда файл был создан с конечной точкой. Есть и более экзотические случаи. Но filename.ext.было бы такое имя файла и не может обычно удаляться из подсистемы Win32. Вот тут-то и приходит хитрость из Каран . Он / она использует имя, которое перед передачей на уровень ниже подсистемы Win32 будет изменено с его \\?\C:\...формы на «родную» (это также видят драйверы файловой системы) форма \??\C:\.... Принимая во внимание, что в зависимости от версии Windows это может быть так называемый объектный каталог (используйте WinObj из Sysinternals / Microsoft, чтобы заглянуть в пространство имен менеджера объектов) или символическую ссылку (не путать с одноименным объектом в NTFS начиная с Vista) в другой объектный каталог, такой как\DosDevices, Последнее является просто одним именем и описывает часть пространства имен менеджера объектов, видимую для процессов Win32 по умолчанию. Для получения более подробной информации ознакомьтесь с серией книг «Внутренние компоненты Windows» или ознакомьтесь с разбором путей, в частности, в Google Project Zero («Полное руководство по преобразованию путей Win32 в NT») . В частности, вы можете обратить внимание на разницу между пространствами имен файлов Win32 и пространствами имен устройств Win32 .

Теперь, как вообще можно создать такой файл? Есть несколько возможностей.

1. Программа Win32, которая использует \\?\X:префикс для имен путей, чтобы увеличить доступную длину пути с 260 символов до приблизительно 32767 символов (см. сноску 1!), создала файл в первую очередь, обойдя таким образом некоторые ограничения подсистемы Win32.
2. программа коренится в другой подсистеме. Была создана бывшая подсистема POSIX (позже Interix, теперь SUA), подсистема OS / 2 (давно ушедшая, но существовавшая в NT 3.51) или какой-то слой, который не совсем подсистема в смысле Windows (Cygwin, насколько мне известно) файл или папка. Точно так же WSL (Windows Subsystem для Linux) в Windows 10 теперь является другим кандидатом.
3. его создала другая операционная система (например, параллельная загрузка Linux).
4. это файл в сетевой папке, расположенный на сервере, отличном от Windows.

Последние два пункта также намекают на одно из упомянутых средств: загрузите не-Windows live CD и удалите файл (ы).

Эта проблема на самом деле может сравниться со случаем, когда старая не-Unicode Win32 программа сталкивается с именами файлов из нескольких кодовых страниц. Часто он не может «найти» некоторые из них, потому что каждая соответствующая кодовая страница ANSI может вмещать только 256 символов, тогда как UTF-16 (но не его подмножество UCS-2) теоретически может кодировать практически неограниченное количество кодовых точек. (читайте эту тему на unicode.org и в Википедии ).

Надеюсь, что это поможет понять основные проблемы немного больше. Не хотел редактировать этот длинный ответ в одном из других ответов, хотя он только дополняет их. Другие ответы совершенно без него действительны.

Сноска 1: максимальное количество символов в пути не является абсолютным, поскольку путь, близкий к абсолютному максимуму (32767 символов), может быть расширен как менеджерами объектов, так и фильтрами файловой системы или самими файловыми системами (например, точками повторной обработки) ,

У меня была эта проблема, и я был очень расстроен, ничего не получалось. Затем я использовал Linux Ubuntu CD. Загрузился с CDROM, перешел в демонстрационный режим, получил доступ к проблемным файлам и просто удалил их. Это работает как сон.