9

Примерно месяц назад я вытащил исходный код 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 .

Я не буду:

  • удалять
  • открыто
  • Переехать

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

генеральный

Защитные свойства:

Безопасность

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

|источник

4 ответа4

14

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

del \\?\C:\cygwin\src\linux-3.7.1\drivers\gpu\drm\nouveau\core\subdev\i2c\aux.c
|источник
13

Проблема, с которой вы столкнулись, связана с древним бронированием 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:\>copy con foo.c
test
^Z
        1 file(s) copied.

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

S:\>type foo.c
test

Теперь с aux.c

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

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

|источник
6

В этом случае, очевидно, речь шла об особом значении 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 символов), может быть расширен как самими диспетчером объектов, так и фильтрами файловой системы или самими файловыми системами (например, точками повторной обработки) ,

|источник
0

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

|источник

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .