Hei, solo un mese in ritardo ma ok 
siamo sicuri che le foto fossero cifrate su fs on device?
perché se non sono cifrate su fs, la fix che hanno rilasciato potrebbe, in linea teorica, cercare i file delle foto cancellati ma non sovrascritti sul filesystem e reindicizzarli sul DB. Questo, sempre teoricamente, potrebbe far recuperare foto presenti a livello di bit su un dispositivo ripristinato e non più associato all’account iCloud.
Scenario poco probabile e che necessita, ad esempio, la non attivazione di passcode o face/touch ID. Cosa che non permette l’attivazione di data protection e di conseguenza la crittografia on device.
Poco probabile, ma teoricamente possibile.
1 Like
oh madre di Cristo donami la grazia, si chiamano BUG. BUG, possa un angelo biblicamente accurato farmi visita se mento, non FIX CATTIVI.
Certo, anch’io se cancello qualcosa sul disco posso recuperare file (finché non vengono sovrascritti) che magari erano su dropbox senza accedere all’account.
Allora però si può andare in full-borzo e pensare che il post su reddit sia stato cancellato sotto richiesta di apple che non voleva far sapere troppo.
A me fanno ridere gli impossibru
Tra l’altro non escludiamo a priori che magari l’azione di cancellazione da parte dell’utente si limita a marcare la foto eliminata sul db, e poi un job si occupa di cancellare il file sul fs e il bug aveva causato la non cancellazione del file, che quindi su fs continua ad esistere e non è nemmeno marcato come eliminato
3 Likes
Sicuro sarà successo qualcosa di simile altrimenti col cavolo che tornavano i file.
asdasdsadasd
Che poi bastava un bellissimo prompt
“questa versione di iOS contiene un bug fix che permette di reindicizzare la galleria foto. In rari casi questo può comportare il ripristino di fotografie cancellate dall’utente. Vuoi procedere con la reindicizzazione?”
la metà di quei vocaboli è sconosciuta all’utente medio apple
Oppure un bellissimo prompt “Oh vuoi vedere una feature che non ha nessun telefono?? clicca e ti ricreiamo con iAI foto che ti “sembra” di aver scattato e poi cancellato”
“oh ciccio, se vuoi sistemo la galleria. pò esse che magari risalta fuori a foto der cazzo che hai mandato a tua cugina e che hai scancellato. vuoi che ce provo a sistemà a galeria?”
meglio?
Non lo so, magari capiscono pure ma pigiano sempre di Si anche ai prompt sulla privacy che sono molto più corti e fanno i giochini “che verdura sei”.
Meglio lasciar tutto così com’è, queste nuove featuressss fanno sempre comparire apple nelle testate giornalistiche di tutto il mondo e gratis, male non fa.
vabbè si chiama fanboyismo, a sto giro abbiamo addirittura la barzelletta che apple ammette il bug e addirittura si affretta a rilasciare il fix per un problema così grave e un utente a caso che nega il bug
Poteva succedere a chiunque, a sto giro è capitato a mtt 
1 Like
Premessa, tu qua dici che non sei esperto, ma dici sempre la tua.
Prima hai anche fatto passare che avevi informazioni riservate e non potevi dirle perchè ancora non erano pubbliche.
Da altre parti parli di programmazione, che usi quel linguaggio o l’altro, e dai consigli a programmatori.
A che gioco pensi di giocare?
Per tornare alla questione: o il “database” di cui parli è il filesystem e parli di una situazione in cui si corrompe il filesystem, oppure il database di cui parli è qualcosa di diverso, e non si capisce da dove riesca a prendere qualcosa che il filesystem, che a livello gerarchico credo dovrebbe avere più autorità di altri processi, dice che non esiste perchè non c’è nelle sue tabelle.
A meno che quando tu dici di cancellare in realtà lo togli solo dall’ indicizzazione ma non dal filesystem, e questa permettimi non mi sembra una gran feature.
1 Like
Guarda pensavo tu fossi interessato a discutere e capirne di piu ma se ci devi mettere l’attacchino ad ogni post allora vai pure a informarti su Reddit 
non hai capito o non vuoi capire.
ne sai o non ne sai?
Se ne sai, come fai a mettere sullo stesso piano un database (sqlite) e il filesystem?
A meno che sia strumentale alla tua narrazione, ovviamente.
Magari mi sbaglio io, ci sta. In quel caso dimostramelo e sarò il primo a dirti che hai ragione e io torto. L’ ho fatto più di una volta sul forum.
Poi ti ricordo, sei tu a non volerci mettere la faccia e a tirarti indietro quando ti si chiede la tua esperienza, non gli altri. Quantomeno, non io.
Sono un programmatore, so cosa sia un database e cosa sia un filesystem, non lavoro sull’app delle foto. Quando dico che non sono un esperto e’ perche’ riconosco che la mia conoscenza e’ superficiale in confronto a chi lavora in questa specifica area, tutto qui.
Non so cosa tu voglia dire con “mettere sullo stesso piano” quando ho scritto frasi del genere
Ci riprovo:
- il database e’ responsabile di indicizzare le foto e tutti i metadati relativi ad esse, metadati che a parte quelli base tipo exif data non possono essere salvati su filesystem ma devono rimanere in un database per essere fruiti al meglio
- il filesystem e’ responsabile dello storage di queste foto, banalmente lo stesso file .jpeg che salvi dalla macchina fotografica che contiene il contenuto della foto stessa piu’ i metadati exif, ma su questo dettaglio dovresti saperne piu tu di me
Entrambe le parti sono fondamentali per il buon funzionamento, parlare di “gerarchia” non so a cosa tu voglia alludere sinceramente.
Il contenuto delle foto deve essere presente sul filesystem per poterle visualizzare. Per il funzionamento di tutto il resto, che sia la galleria delle foto, che sia la funzionalita’ per fare sorting in base alla data, per filtrare immagini specifiche basate su una query tipo “foto che hanno un cane” etc serve il database.
Non puoi fare delle query di quel tipo direttamente al filesystem ti serve avere un database, strumento che e’ ottimizzato per lo scopo di fare delle query e gestire relazioni (tipo foto che fanno parte di uno stesso album)
E’ ovvio che queste due entita’ devono rimanere in sync.
Se il database pensa che esista una foto che non esiste sul filesystem e’ un problema.
Se il filesystem contiene una foto che non esiste sul database, e’ altrettanto un problema.
l’OS penso parli sempre al database prima di tutto nel contesto di aprire un app tipo galleria.
Se apri un album probabilmente fa una query “dammi le foto che appartengono all’album X”, che ritorna una serie di risultati il cui all’interno tra le varie proprieta’ c’e’ anche il posto dove sono fisicamente salvate sul filesystem cosi che possono essere caricate (molto probabilmente una thumbnail quando sei nella vista galleria)
Nel contesto di questi giorni ci sono due tipi di bug
- il database si corrompe nel normale uso e pensa che una foto non esista piu’ anche se e’ ancora presente nel filesystem. L’intenzione dell’utente in questo caso non era di eliminare quelle foto, sono sparite per via della corruzione.
- Nel contesto di un operazione esplicita di cancellazione di una foto da parte dell’utente l’OS esegue correttamente il delete dell’entry nel database ma per via del bug fallisce nel cancellare la foto dal filesystem.
Cosa e’ successo quindi:
- nel primo caso quelle foto erano perse e gli utenti avrebbero voluto recuperarle quindi apple ha pensato di forzare una reindicizzazione del database come fix a questo problema
- nel secondo caso quelle foto dovevano essere state cancellate ma non lo erano, gli utenti non volevano ovviamente recuperarle e apple non ha ovviamente pensato a questo tipo di effetto collaterale, banalmente non sapendo dell’esistenza del secondo bug in passato
Ha senso scritto cosi?
1 Like
Ma il fs di per sé non è già un database?
Quindi o si corrompe il fs, che ci sta, viene recuperata una sua vecchia copia e se i file cancellati non sono sovrascritti sono leggibili interamente o parzialmente, oppure stiamo parlando di un database secondario che indicizza un percorso.
In quel caso se si corrompe poco male, basta fare di nuovo l’indice e hai la situazione corretta.
Se nel farlo escono fuori file cancellati, vuol dire non è mai arrivato al fs il comando di cancellazione, e quindi la cancellazione era solo un flag non nel fs ma nell’indice.
Questo mi suona strano e pericoloso. Tutto qua.