.DS_Store d'annata

[Paolofast]

Ho un disco dove tengo la mia collezione di software.
In effetti sono due, identici, perché la prudenza non è mai troppa.

Cè una cartella chiamata MacOsX con tante sottocartelle, una per ogni sistema operativo, contenenti installer e aggiornamenti vari, a partire da MacOsX 10.4 Tiger.
Ovviamente le cartelle più vecchie non venivano consultate da anni.
Di conseguenza i loro file .DS_Store non venivano aggiornati da altrettanti anni.
Anche quando ho copiato il contenuto da un disco vecchio al suo sostituto, i .DS_Store sono rimasti uguali.

Con l'aggiornamento di svariati installers, anche d'antiquariato, al nuovo certificato Apple, per la prima volta dopo anni sono entrato in una di quelle cartelle.

E il Finder di Mojave è andato in tilt.

Collegando il disco al vecchio portatile con El Capitan, nessun problema.

Ovviamente il problema non si poneva navigando in cartelle dello stesso disco create o consultate di recente.

Visto che quando si apre una cartella, l'unico file di cui viene letto il contenuto automaticamente è proprio il .DS_Store, è stato facile trovare il colpevole.

Con EasyFind ho cercato tutti i .DS_Store del disco, li ho cancellati, tanto si ricostruiscono automaticamente quando serve, e tutto ha ripreso a funzionare perfettamente.

[faxus]

Interessante, non lo sapevo.

Non è che ne hai uno vecchio?
(e uno di Mojave che non ho)

Per vedere che differenza morfologica hanno.
Non ho letto da nessuna parte di questa cosa.
Sarebbe un buon articolo tecnico per la home del Forum

[Paolofast]

Interessante, non lo sapevo.

Non è che ne hai uno vecchio?
(e uno di Mojave che non ho)

Per vedere che differenza morfologica hanno.
Non ho letto da nessuna parte di questa cosa.
Sarebbe un buon articolo tecnico per la home del Forum

Sulla copia del disco dei programmi ci sono ancora quelli vecchi.
Vedo che posso fare.

[Hammarby]

Qualche link

https://en.wikipedia.org/wiki/.DS_Store
https://0day.work/parsing-the-ds_store-file-format/

Magari hanno cambiato da un formato con indici a 32 bit verso uno a 64 bit

[Paolofast]

Allora, prima di eliminarli tutti ho duplicato e zippato tre .DS_Store.

Ho provato ad estrarli di nuovo dagli zip e in El Capitan si vedono, in Mojave solo uno.
Boh?

Uno è del 2006, intonso, uno del 2007, intonso e uno che dice di essere stato creato nel 2017, ma in una cartella creata nel 2013 e che credo non sia mai stata visitata almeno dal 2015.
Quest'ultimo era in una delle cartelle che mandavano in tilt il Finder, gli altri in cartelle che non ho neppure provato ad aprire in Mojave.

Questi i link, uno per file, per non avere interferenze:

.DS_Store del 2006

https://mega.nz/#!Y9B12aoQ!qH6Ggdnj1l5P ... l1QxfJatQA

.DS_Store del 2007

https://mega.nz/#!BlY3jYgR!sF1uQf8m40VY ... 2Nf2ba6Bms

.DS_Store del 2017 problematico

https://mega.nz/#!QoYjxSCI!W0eX1bO2SDdw ... WtuQ-DkoxM

Se scopri qualcosa, bene, altrimenti pazienza, resterà uno dei "riti magici" privi di spiegazioni.

[Paolofast]

Qualche link

https://en.wikipedia.org/wiki/.DS_Store
https://0day.work/parsing-the-ds_store-file-format/

Magari hanno cambiato da un formato con indici a 32 bit verso uno a 64 bit

Nel secondo link compare questa frase:

[i]Known Issues
While developing the code and writing the blogpost, I discovered some issues in the implementation and parsing logic, which I would like to discuss briefly. Maybe you will find a fix?
Root block offset
I came across at least one .DS_Store file, where the root block's offset from the initial header parsing was off by 4 bytes. This resulted in a incorrectly parsed offsets list as well as TOC. However, this seemed to be a rare occurence and I am not sure, how or why it occured.
Incorrect file name length
Another issue that I encountered was that the file name length inside a record had a wrong value. For example, it appeared as 0x0a (10 * 2 bytes), but the UTF-16 file name was actually > 20 bytes long. Often, this resulted in an unmatched structure type and an error. Setting the correct length with an hexeditor usually fixed the issue, but I am unsure how that obviously wrong length made it there.
Nonetheless, I have implemented a brute-force like approach to resolve this issue: Re-reading the next two bytes of the file name until a known structure-ID appears. This mostly fixed the issue, but it does not feel like it's the best approach.[/i]

Ovvero:
Problemi noti
Durante lo sviluppo del codice e la scrittura del post sul blog, ho scoperto alcuni problemi nell'implementazione e nella logica di analisi, di cui vorrei discutere brevemente. Forse troverai una soluzione?
Offset blocco radice
Mi sono imbattuto in almeno un file .DS_Store, in cui l'offset del blocco radice dall'analisi dell'intestazione iniziale era disattivato di 4 byte. Ciò ha comportato un elenco di offset analizzato in modo errato e un sommario. Tuttavia, questo sembrava essere un evento raro e non sono sicuro di come o perché si sia verificato.
Lunghezza del nome file errata
Un altro problema che ho riscontrato è stato che la lunghezza del nome file all'interno di un record aveva un valore errato. Ad esempio, è apparso come 0x0a (10 * 2 byte), ma il nome del file UTF-16 era effettivamente lungo> 20 byte. Spesso, ciò ha comportato un tipo di struttura senza eguali e un errore. L'impostazione della lunghezza corretta con un hexeditor di solito risolveva il problema, ma non sono sicuro di come quella lunghezza ovviamente errata lo abbia reso lì.
Tuttavia, ho implementato un approccio simile alla forza bruta per risolvere questo problema: rileggere i successivi due byte del nome del file fino a quando appare un ID struttura noto. Ciò risolveva principalmente il problema, ma non sembra che sia l'approccio migliore.

Vuoi vedere che alcuni .DS_Store erano semplicemente danneggiati e mentre El Capitan non si fa problemi Mojave è più schizzinoso?
Aspettiamo il responso di faxus.

[faxus]

... Uno è del 2006, intonso, ...e uno che dice di essere stato creato nel 2017, ma in una cartella creata nel 2013 e che credo non sia mai stata visitata almeno dal 2015.
Quest'ultimo era in una delle cartelle che mandavano in tilt il Finder...

Ti dico cosa ho fatto.

Non potendo aprire gli zip sulla scrivania, ovviamente perché non potevano essere aperti in presenza di un esistente DS_Store.
Ho creato due cartelle:
2006
2017
Non ho preso in considerazione il DS_Store del 2007 perché so con certezza che sono uguali.

Ho messo i file nella cartella del rispettivo anno.
L'intento è quello di isolare i due DS_Store e compararli con l'utilità diff.
Perché
HexFiend mostra delle differenze (da dentro lo zip) ma non sono, almeno da me utilizzabili.

E quindi con Terminale ho eseguito:

Codice: Seleziona tutto

MacBook-Pro-di-Fabio:~ faxus$ sudo ls /Users/faxus/Desktop/2006 
Password:
.DS_Store		DS_Store 2006.zip
MacBook-Pro-di-Fabio:~ faxus$ cd /Users/faxus/Desktop/2006
MacBook-Pro-di-Fabio:2017 faxus$ sudo rm .DS_Store
MacBook-Pro-di-Fabio:~ faxus$ unzip DS_Store\ 2006
Archive:  /Users/faxus/Desktop/2006/DS_Store 2006.zip
  inflating: DS_Store 2006           
   creating: __MACOSX/
  inflating: __MACOSX/._DS_Store 2006

Poi

Codice: Seleziona tutto

MacBook-Pro-di-Fabio:~ faxus$ sudo ls /Users/faxus/Desktop/2017
DS_Store 2017 problematico.zip

Come? non c'è un DS-Store?
Mah, apro la cartella e verifico, ⌘+⇧+. ma non si vede
Allora apro lo zip...

Va bene, diciamo... Nella cartella compare



Riprendo

Codice: Seleziona tutto

MacBook-Pro-di-Fabio:~ faxus$ sudo ls /Users/faxus/Desktop/2017
Password:
.DS_Store			DS_Store vecchio
DS_Store 2017 problematico.zip
MacBook-Pro-di-Fabio:~ faxus$ cd /Users/faxus/Desktop/2017
MacBook-Pro-di-Fabio:2017 faxus$ sudo rm .DS_Store

Poi ripeto

Codice: Seleziona tutto

MacBook-Pro-di-Fabio:2017 faxus$ sudo rm .DS_Store
rm: .DS_Store: No such file or directory

Bene, allora:

Codice: Seleziona tutto

MacBook-Pro-di-Fabio:2017 faxus$ unzip DS_Store\ 2017\ problematico
Archive:  DS_Store 2017 problematico.zip
replace DS_Store vecchio? [y]es, [n]o, [A]ll, [N]one, [r]ename: Y
  inflating: DS_Store vecchio        
   creating: __MACOSX/
  inflating: __MACOSX/._DS_Store vecchio  
MacBook-Pro-di-Fabio:2017 faxus$

Questo vuol dire che il DS_Store non c'era, ma c'era un DS_Store sostituto (che non compare, però).
Forse l'originale era corrotto.

In ogni caso, esco e rientro in Terminale:

Codice: Seleziona tutto

MacBook-Pro-di-Fabio:~ faxus$ sudo ls /Users/faxus/Desktop/2006 
.DS_Store		DS_Store 2006.zip
DS_Store 2006		__MACOSX
MacBook-Pro-di-Fabio:~ faxus$ sudo ls /Users/faxus/Desktop/2017
DS_Store 2017 problematico.zip	__MACOSX
DS_Store vecchio
MacBook-Pro-di-Fabio:~ faxus$ diff /Users/faxus/Desktop/2006/DS_Store\ 2006 /Users/faxus/Desktop/2017/DS_Store\ vecchio
Binary files /Users/faxus/Desktop/2006/DS_Store 2006 and /Users/faxus/Desktop/2017/DS_Store vecchio differ
MacBook-Pro-di-Fabio:~ faxus$

Ecco.

Ma se vuoi la mia opinione quel DS_Store 2017 problematico era solo corrotto.
Quindi dipendeva dalla corruzione e non da altro


Edit: ho corretto la riga
Non ho preso in considerazione il DS_Store del 2017 perché so con certezza che sono uguali
in: Non ho preso in considerazione il DS_Store del 2007 perché so con certezza che sono uguali.
Perché era incomprensibile...

[faxus]

Ho accorciato un po' il discorso, spero che sia chiaro.

Resta il fatto che i due DS_Store sono differenti.
Considera che io sto su High Sierra e quel DS_Store differente fa pasticci egualmente.

Non so se tu da El Capitan non aprivi più quei file.
Fatto sta che non se ne era mai parlato e se ormai hai cambiato tutto resterebbe indimostrabile.

La mia cartella /Users/faxus/Desktop/2017 è tuttora priva di un suo DS_Store

[Paolofast]

Ma se vuoi la mia opinione quel DS_Store 2017 problematico era solo corrotto.
Quindi dipendeva dalla corruzione e non da altro

A questo punto ne sono convinto anch'io.

Bene, adesso sappiamo che El Capitan, se trova un .DS_Store corrotto, non fa una piega.
Mojave dà fuori di matto.

P.s.: grazie.