Jak naprawić szare pliki w Finderze?

13

Czy istnieje sposób, aby zmusić Findera do odświeżenia informacji w użyciu dla szarych (niedostępnych) plików?

Detale:

Rzadko używane pliki przenoszę z komputera Mac (OS X 10.6) na serwer plików Windows Server 2008. Niedawno znalazłem dużą liczbę plików, które Finder w OS X pokazuje jako szary (tak jak gdyby plik był w trakcie kopiowania). Wszystkie pliki są prawidłowe i kompletne: brak uszkodzeń lub brakujących danych; w rzeczywistości mogę bez problemu uzyskać dostęp do plików z terminala lub z komputera z systemem Windows, ale Finder nadal uważa, że ​​należy je uznać za niedostępne.

Mogę „rozwiązać” problem, kopiując oryginalny plik do nowej nazwy, usuwając oryginalny plik, czekając około minuty, a następnie zmieniając nazwę nowego pliku na pierwotną nazwę (jeśli nie będę czekać wystarczająco długo, nowy plik zmieni kolor na szary po zmianie nazwy na oryginalną nazwę).

Zasadniczo wydaje się, że Finder nie wyczyścił flagi „w użyciu” lub „niekompletnej” [przypuszczenie].

Wróćmy więc do pierwotnego pytania: jak to naprawić? Idealnie, chciałbym móc skanować dyski sieciowe i znajdować i naprawiać wszystkie szare pliki za pomocą operacji terminalowej lub rekurencyjnej, dzięki czemu mogę je naprawić bez marnowania dużo czasu.

Robert Altman
źródło
Czy ma to związek z uprawnieniami? Sprawdziłeś to?
Martin Marconcini,
Czy ponowne uruchomienie Findera działa?
Itai Ferber
Brak uprawnień: obrażające pliki są dostępne przez Terminal. Ponowne uruchomienie OS / X nie ma wpływu.
Robert Altman,

Odpowiedzi:

8

To rozwiązało dla mnie! http://macadmins.psu.edu/news/2011/06/grayed_out_finder_folder

Więc co się stało? Wygląda na to, że data utworzenia folderu została ustawiona na losową datę w 1943 r. Chociaż nie jesteśmy pewni, jak to się stało, wymyśliliśmy, jak to naprawić.

Użyliśmy kilku plików binarnych dostarczonych z Narzędziami programisty, GetFileInfo i SetFile. GetFileInfo pokazał nam datę utworzenia folderu. Z początku przeoczyliśmy to, ale przy bliższym zbadaniu przykuło naszą uwagę.

$ GetFileInfo Test / katalog: atrybuty „/ Users / user / Desktop / Test”: utworzono avbstclinmedz: 06/13/1943 06:13:00 zmodyfikowano: 06/13/2011 15:07:33

Następnie możemy zmienić datę utworzenia za pomocą narzędzia SetFile.

$ SetFile -d 13.06.2011 Test /

Po ustawieniu daty z powrotem na rozsądny czas, widzimy, że naprawdę się zmieniła.

$ GetFileInfo Test / katalog: atrybuty „/ Users / userid / Desktop / Test”: avbstclinmedz utworzono: 06/13/2011 06:13:00 zmodyfikowano: 06/13/2011 15:07:33

Folder został następnie poprawnie wyświetlony w Finderze i ponownie można go było użyć. Odkryliśmy również, że jeśli utworzyłeś alias folderu, możesz zobaczyć dane i przenieść je. Po przeniesieniu do innego folderu stary folder można usunąć.

nickganga
źródło
1
To miałoby sens; jeśli dobrze pamiętam, widziałem dziwne daty. Niestety (do testowania teorii) od tego czasu wyczyściłem błędy i nie widziałem tego od dłuższego czasu. Dzięki za informację!
Robert Altman,
5

Służy ls -lado sprawdzania, czy plik ma rozszerzone właściwości. Będzie to wyglądać podobnie do:

-rwxr-xr-x@ 1 user1 staff 439734882 Aug 16 21:34 myfile.zip

Spójrz na @ koniec. To oznacza rozszerzone właściwości.

Aby wyświetlić rozszerzone właściwości, musisz użyć xattr -l filenamepolecenia.

W wielu przypadkach wyszarzone pliki mają com.apple.FinderInfoatrybut, który wygląda następująco:

com.apple.FinderInfo:
00000000  62 72 6F 6B 4D 41 43 53 00 00 00 00 00 00 00 00  |brokMACS........|
00000010  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  |................|
00000020

Aby usunąć ten atrybut, uruchom xattr -d com.apple.FinderInfo filename, a plik wróci do normy.

Jeśli chcesz rekursywnie usunąć ten atrybut ze wszystkich plików, możesz uruchomić:

xattr -dr com.apple.FinderInfo .

Nie przegap kropki .na końcu, która oznacza bieżący katalog.

Oryginalny post: https://tangentlin.wordpress.com/2013/10/18/greyed-out-files-in-mac-osx/

camikiller
źródło
1
Tylko ten działał dla mnie w High Sierra.
Rivera,
2

Rozwiązałem to za pomocą polecenia duplikowania w wyszarzonym folderze. Nowy folder będzie dostępny, a pliki można przenieść do innego folderu. Po przeniesieniu plików usuń oba foldery (szary i kopiuj), teraz oba puste

Adrian Trif
źródło
1

Spróbuj usunąć swoje pamięci podręczne (~ / Library / Caches) i uruchom ponownie. Z mojego doświadczenia wynika, że ​​zwykle rozwiązuje to dziwne problemy związane z ikonami.

Harv
źródło
Niestety nie przyniosło to efektu.
Robert Altman,
1

Możesz spróbować ponownie zsynchronizować pliki za pomocą rsyncnarzędzia:

$ rsync -aut /source/* /destination

lub (jeśli jest zbyt wiele plików):

$ find /source/ -name \* -type f -exec rsync -at {} /destination/ ";"

Oto argumenty za BSD rsync:

-a, --archive               archive mode; equals -rlptgoD (no -H,-A,-X)
-u, --update                skip files that are newer on the receiver
-t, --times                 preserve modification times

Jeśli używasz GNU rsync, rozważ dodanie:

-N, --crtimes               preserve create times (newness)

Uwaga: Możesz zainstalować GNU rsyncprzez brew install rsync.

Jeśli to nie pomoże, spróbuj również bez -u.

kenorb
źródło
@Flimm Racja, używałem GNU do przetestowania go, wyjaśniłem odpowiedź. Usunięto -N, ale możesz go dodać, jeśli masz wersję GNU, w przeciwnym razie użyj składni BSD.
kenorb
Użycie GNU rsync z -Noznaczoną flagą działało dla mnie. Nie jestem pewien, czy to z powodu -Nflagi.
Flimm,
0

Eureka! Zrozumiałem, co jest przyczyną problemu.

Pliki są kopiowane do udziału sieciowego systemu Windows Server 2008 z replikacją DFS (na inny serwer). W jakiś sposób Finder buforuje status pliku „zajęty”; i czasami zdarza się to podczas replikacji pliku.

Obejściem problemu jest użycie terminala do skopiowania pliku, usunięcia oryginału, CZEKAJ !!!, a następnie zmiana nazwy duplikatu na pierwotną nazwę. (Jeśli nie zaczekasz, duplikat mój stanie się szary, gdy zmieni nazwę).

To jest „co”; Nadal mam nadzieję, że ktoś może wyjaśnić, gdzie przechowywane są informacje.

Jeśli ktokolwiek może dowiedzieć się, gdzie informacje są przechowywane w pamięci podręcznej i jak rozpoznać, których plików dotyczy skrypt, zaakceptuję ich odpowiedź; w przeciwnym razie zaznaczę to jako odpowiedź i opiszę dziwność interoperacyjności OS / X i Windows.

Robert Altman
źródło