Dlaczego ten plik najwyraźniej nie istnieje podczas próby jego usunięcia?

Mniej więcej miesiąc temu rozpakowałem źródła Linuxa w folderze w Cygwin (byłem ciekawy, czy kompiluje się z MinGW, ponieważ mój drugi komputer z systemem Linux jest wolno działającym pojedynczym rdzeniem Sempron). Próbowałem go usunąć, ale został 1 plik i nie można go usunąć ...

Cygwin mieszka w nim C:\cygwin, a ja nie zmieniłem źródła w C:\cygwin\src\linux-3.7.1. Nie udało się go skompilować ... Więc próbowałem usunąć folder. Wszystko szło dobrze, dopóki nie zdałem sobie sprawy, że nie wszystkie pliki zostały usunięte. Próbowałem linux-3.7.1ponownie usunąć folder i pojawił się błąd:

Otworzyłem folder i stwierdziłem, że został 1 plik źródłowy: aux.cktóry jest w C:\cygwin\src\linux-3.7.1\drivers\gpu\drm\nouveau\core\subdev\i2c\aux.c.

Nie będzie:

• Usunąć
• otwarty
• Ruszaj się

Ogólne właściwości:

Właściwości bezpieczeństwa:

Jak mogę usunąć ten plik?

Spróbuj tego z wiersza polecenia (podwyższonego):

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

Problem, na który wpadłeś, jest spowodowany starymi rezerwacjami DOS.

Pliki z poniższej listy miały specjalne znaczenie. Część tego jest nadal obecna we współczesnych wersjach systemu Windows:

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

Najłatwiejszym sposobem ich usunięcia jest uruchomienie systemu operacyjnego, który nie traktuje tych nazw plików jako specjalnych. (np. uruchom dowolny liveCD inny niż Windows).

[edytuj] Testy przeprowadzone na Win7-x86 Ultimate:

Tworzenie prostego pliku testowego:

S: \> copy con foo.c
test
^ Z
        1 plik (i) skopiowane.

Sprawdzanie zawartości:

S: \> wpisz foo.c
test

Teraz z Aux .c

S: \> copy con aux.c
^ Z
System nie może odnaleźć określonego pliku.
        Skopiowano 0 plików.

Wygląda na to, że części systemu Windows nadal są kompatybilne wstecz.

W tym przypadku chodziło oczywiście o szczególne znaczenie auxodziedziczone z czasów DOS , jak słusznie wskazał Hennes . Jednak dla czytelników, którzy potykają się o to w przyszłości, chciałbym dodać kolejny możliwy przypadek, w którym można zobaczyć to zachowanie.

Wtedy właśnie utworzono plik z kropką końcową. Są też bardziej egzotyczne przypadki. Ale filename.ext.byłaby taka nazwa pliku i normalnie nie mogłaby zostać usunięta z podsystemu Win32. W tym momencie pojawia się trik Karana . Używa nazwy, która przed przeniesieniem do warstwy poniżej podsystemu Win32 zostanie zmieniona z jego \\?\C:\...formy na „natywną” (tak też widzą to sterowniki filtrów systemu plików) tworzą \??\C:\.... Podczas gdy w zależności od wersji systemu Windows może to być tak zwany katalog obiektów (użyj WinObj z Sysinternals / Microsoft, aby zajrzeć do przestrzeni nazw menedżera obiektów) lub dowiązanie symboliczne (nie mylić z identycznie nazwaną jednostką w NTFS od Visty) do innego katalogu obiektowego, takiego jak\DosDevices. Ta ostatnia jest tylko jedną nazwą i domyślnie opisuje część przestrzeni nazw menedżera obiektów widoczną dla procesów Win32. Aby uzyskać więcej informacji, sprawdź serię książek o Windows Wewnętrzne lub poczytaj o analizie ścieżek, w szczególności w Google Project Zero (The Definitive Guide on Win32 to NT Path Conversion) . W szczególności warto zwrócić uwagę na różnicę między przestrzeniami nazw plików Win32 i przestrzeniami nazw urządzeń Win32 .

Jak w ogóle można utworzyć taki plik? Istnieje kilka możliwości.

1. program Win32, który wykorzystuje \\?\X:przedrostek nazw ścieżek w celu zwiększenia dostępnej długości ścieżki z 260 znaków do około 32767 znaków (patrz przypis 1!), stworzył ten plik w pierwszej kolejności, omijając w ten sposób pewne ograniczenia podsystemu Win32.
2. program zrootowany w innym podsystemie. Poprzedni podsystem POSIX (później Interix teraz SUA), podsystem OS / 2 (dawno już minął, ale istniał w NT 3.51) lub jakaś warstwa, która nie jest dokładnie podsystemem w sensie Windows (Cygwin, o ile mi wiadomo) plik lub folder. Podobnie WSL (Windows Subsystem for Linux) w systemie Windows 10 jest teraz kolejnym kandydatem.
3. utworzył go inny system operacyjny (na przykład równoległe uruchomienie systemu Linux).
4. jest to plik w udziale sieciowym znajdujący się na serwerze innym niż Windows.

Ostatnie dwa punkty wskazują także na jeden z wymienionych sposobów: uruchom dysk CD z systemem innym niż Windows i usuń plik (i).

Problem ten można porównać do przypadku, w którym stary program Win32 inny niż Unicode jest konfrontowany z nazwami plików z wielu stron kodowych. Często nie będzie w stanie „znaleźć” niektórych z nich, ponieważ każda odpowiednia strona kodowa ANSI może zmieścić tylko 256 znaków, podczas gdy UTF-16 (ale nie jego podzbiór UCS-2) może teoretycznie kodować praktycznie nieograniczoną liczbę punktów kodowych (czytaj na ten temat na stronie unicode.org i Wikipedia ).

Mam nadzieję, że to pomoże lepiej zrozumieć podstawowe problemy. Nie chciałem edytować tej długiej odpowiedzi na jedną z pozostałych odpowiedzi, chociaż tylko je uzupełnia. Inne odpowiedzi są całkowicie poprawne bez tego.

Przypis 1: maksymalna liczba znaków na ścieżce nie jest bezwzględna, ponieważ ścieżka zbliżona do absolutnego maksimum (32767 znaków) może zostać rozwinięta zarówno przez menedżer obiektów, jak i filtry systemu plików lub same systemy plików (np. Punkty ponownej analizy) .

Miałem ten problem i byłem bardzo sfrustrowany, nic nie działało. Następnie użyłem dysku CD z systemem Linux Ubuntu. Uruchomiony z CDROM-u, przeszedł do trybu demo, uzyskał dostęp do kłopotliwych plików i po prostu je usunął. To działa jak sen.