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?
Odpowiedzi:
Spróbuj tego z wiersza polecenia (podwyższonego):
źródło
aux.czostało usunięte, ale teraz folder `src` jest najwyraźniej używany, gdy próbuję go usunąćrd /s /q \\?\C:\cygwin\srcmoże pomoże.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:
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.
źródło
aux.ccopy con aux.cna Win7 i to się nie udało. (copy con test.cdziała).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.
\\?\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.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) .
źródło
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.
źródło