Da qualche giorno circola in rete una notizia secondo cui il Finder di Leopard sarebbe affetto da un bug, a causa del quale sarebbe possibile la perdita di dati in caso di interruzione dello spostamento di file tra 2 directory.
Se fosse vero, sarebbe una svista clamorosa da parte di Cupertino: ma non affrettiamoci a sparare sentenze e vediamo di analizzare la situazione.
Quando un cartella viene spostata dalla directory d’origine a una nuova destinazione, il Finder esegue uno script unix (che sappiamo essere alla base di OS X) molto simile a questo:
move(source, destination) {
returnVal = copy(source, destination);
if (returnVal == TRUE) { // copy success
delete(source);
else { // copy fail
message("Move failed")
Vediamo che in realtà l’operazione di spostamento è costituita da due fasi distinte, ovvero la copiatura e, se questa è confermata, la cancellazione del file di origine.
A causa della loro peculiare architettura, i sistemi *NIX eseguono questo script in maniera distinta per ogni file e directory che si vogliono spostare.
Se, dunque, si comanda di spostare una cartella “test” con all’interno un file “prova.txt” dalla posizione /~utente/ alla posizione /Volumes/HD2/~utente/documenti/ ecco la sequenza di operazioni che il sistema effettuerà:
Possiamo apprezzare il fatto che il sistema invii la conferma per ogni file presente nella cartella e poi per la cartella stessa. Se ci si trova di fronte a più directory l’una contenuta nell’altra, l’operazione verrà eseguita secondo la gerarchia.
Se passiamo ad analizzare il funzionamento di un sistema DOS, ci troviamo di fronte ad un modo di agire molto diverso.
Lo spostamento della directory “test” (che contiene prova1.txt e prova2.txt) da C:/ a D:/documenti è costituito dalle seguenti operazioni:
Tra i due metodi non se ne può individuare uno migliore, sono semplicemente diversi a causa, come abbiamo già detto, della differente architettura dei due sistemi.
In caso di interruzione durante lo spostamento delle directory, i due sistemi si comporteranno in maniera egualmente differente.
Su *NIX (e dunque OS X), si avranno una parte dei file nella nuova destinazione ed una parte in quella vecchia.
Su DOS (e dunque Windows) si avrà la cartella di origine ed il suo contenuto intatti, mentre nella destinazione i file non saranno mantenuti mancando la conferma della copia totale del contenuto.
In entrambi i casi, quindi, non si ha alcuna perdita di dati.
Problemi possono però sopraggiungere quando lo spostamento è ibrido, per esempio volendo spostare una directory ed il suo contenuto da un disco Mac ad un server SAMBA su una macchina Windows.
In questo caso, mentre OS X cancellerà i file di origine via via che riceverà la conferma della copia, il server SAMBA manterrà definitivamente il contenuto solo quando riceverà la conferma che tutto sarà stato copiato. E’ ben chiaro che, se si dovesse interrompere la connessione, ci si ritroverà con meno dati di quanti se ne aveva in origine.
Alla luce di quanto detto finora è facile evincere il fatto di non trovarsi di fronte ad un bug di OS X (o di UNIX), ma ad un problema di comunicazione tra 2 piattaforme diverse.
Un problema che, tra l’altro, non giunge con Leopard, ma esiste praticamente da sempre.
In ogni caso, pur non potendo attribuire la responsabilità ad Apple, è comunque opportuno compiere due operazioni:
[Grazie delle segnalazioni]
62 COMMENTIAGGIUNGI IL TUO
TheRealJay
Hai fatto un post meraviglioso, chiaro e dettagliato!
#1 - Scritto il
Filippo B.
Effettivamente sulle unità di rete (o anche rimovibili) esterne il finder la prima opzione che propone è la copia.. Speriamo che venga risolto comunque!
#2 - Scritto il
emix
Lo spostamento dei file all'interno dello stesso FS non avviene tramite la copia (non avrebbe senso). Viene modificato solo il descrittore del file presente nella tabella della partizione impostando la nuova posizione. Questo è il motivo per cui lo spostamento di un file molto grande da una cartella ad un'altra è istantaneo. Nel caso in cui si vuole spostare invece un file tra due filesystem diversi (per diversi intendo che stanno su due diverse partizioni) avviene la copia fisica del file e la successiva cancellazione dell'originale.
#3 - Scritto il
Marcello Majonchi
@emix Hai perfettamente ragione. Intendevo tra 2 volumi distinti. Correggo subito, grazie! M.
#4 - Scritto il
Scratch
C'è qualcosa che non mi torna: nell'esempio che mette in relazione le piattaforme differenti, stai presupponendo un trasferimento di dati che comprende più files, non capisco perché l'OS da bravo si metta a gestire gli ack di ogni singolo file prima di procedere alla sua cancellazione, mentre SAMBA pare che tratti solo l'ack complessivo di tutta la transizione (<i>quindi di tutti i files, ma nel complesso e basta</i>) altrimenti cancella quello che gli è arrivato. Sinceramente questa mi giunge nuova. Comunque in ogni caso questo che, con licenza "poetica", chiamiamo bug… …non è (<i>a parer mio</i>) degli OS, ma bensì del protocollo di trasferimento dati… …e la cosa mi stupisce ancora in quanto ci sono tanti di quei metodi che si occupano sia della congestione dei pacchetti che della loro eventuale perdita (<i>o addirittura la perdita del solo ack</i>) che questi problemi di perdita dati… …sinceramente non sussistono. O.o
#5 - Scritto il
Marcello Majonchi
@Scratch Pare strano, ma è così. Tra l'altro lo conferma anche Tom Karpik (l'autore del test linkato) pur dando la colpa, inspiegabilmente a Leopard. M.
#6 - Scritto il
MixNuc
Beh in realtà a me sembra un problema più serio, infatti riguarda tutti i tipi di volume collegati ("The bug occurs regardless of the type of destination being moved to (whether it’s local USB, local Firewire, SMB, etc.)") non solo gli share SAMBA.
#7 - Scritto il
jek
Marcello, bel post.
#8 - Scritto il
Marcello Majonchi
@MixNuc Proprio lì sta l'errore di Tom Karpik: in caso di volumi locali i dati, pur non trovandosi più nella directory d'origine, sono comunque reperibili alla destinazione. Non si può, dunque, parlare di "perdita di dati". Come detto, è invece diverso lo spostamento su un volume di rete… M.
#9 - Scritto il
Scratch
@ Marcello Allora se si verificano i casi di loss, è garantito che il trasferimento di un file NON avvenga con le modalità (<i>ovvie e naturali</i>) citate da te nel post. Perché la dottrina insegna che quelle sono a prova di bomba… …o manca qualche riga di codice o qualcuna è stata invertita. Confido comunque che un "bug" del genere sia talmente facile da correggere che se ne verrà riconosciuta la sua effettiva esistenza, verrà presto resa pubblica la patch per correggerlo.
#10 - Scritto il
-teo-
Ma come si fa a spostare dei file dal Finder fra due volumi invece che copiarli? È una funzione che ha solo Leopard?
#11 - Scritto il
Luca Bernardi
Marcello…ma le graffe non le chiudiamo? altrimenti neanche compila e ci credo che è baggato! ehehehh A parte complimenti davvero per il post completo e dettagliato ci vogliono ogni tanto oltre ai soliti rumors ;)
#12 - Scritto il
gabrielep
per default taglia/incolla e' disabilitato in finder. e il comportamento predefinito del drag and drop tra volumi diversi e' quello di creare una copia del file/cartella. si tratta comunque di espedienti per chiudere una falla con un cerotto.
#13 - Scritto il
PaRRoT
Diciamo che un post più di parte non l'avevo mai visto :D Perché non segnalare che nel momento in cui sposti una directory dello stesso nome da una partizione all'altra o da un'altra directory i file della cartella destinazione vengono cancellati? Questa è una delle più grosse magagne che mi ha fatto perdere 4 GB di dati subito dopo il passaggio da PC a Mac. Su PC lo spostamento è "incrementale", ovvero se la cartella già contiene altre cartelle con lo stesso nome aggiunge i file mancanti e chiede di sovrascrivere quelli già presenti… su Mac chiede di sovrascrivere la cartella principale e cancella tutto il resto…
#14 - Scritto il
-teo-
Vedo che si possono spostare i file fra volumi fal Finder premendo "Command" mentre si fa il drag&drop. Nei miei lunghi anni su Mac non mi ero mai accorto :-o
#15 - Scritto il
cicciolo
se tu sei abituato male non possiamo farci nulla ;-) quello che chiedi tu è un merge tra due directory differenti.. e lo vuoi fare con un move.. che è come tagliare il formaggio grana con il coltello del pane: una fatica inutile e controproducente!
#16 - Scritto il
destroyer85
Appena riesco provo con Linux a fare la stessa cosa e vi dico. Magari è un problema legato alla versione di samba o alla versione di windows
#17 - Scritto il
PaRRoT
@cicciolo Quello è abituarsi bene, tra l'altro senza alcun avvertimento dato dall'OS sulla possibile perdita dei dati. Sto usando un sistema operativo "grafico" non il move di *NIX e mi aspetto un comportamento sensato, non una cosa del genere. Dopo ci fai il callo… ma 4 GB di dati persi a suo tempo furono veramente una mazzata…
#18 - Scritto il
kernel_panic
Nell'articolo originale si dice che il baco si riproduce anche su dischi USB, quindi SAMBA/Windows/Linux c'entrano poco.
#19 - Scritto il
hallohallohola
Il "baco" descritto esiste in tutte le versioni di OSX. Non è propriamente un bug, ma una caratteristica dell'OS. Proprio come quella controversa descritta da Parrot. Marcello, nell'immagine del tuo terminale allegata all'articolo il comando è sbagliato, esegue una copia sullo stesso disco, in questo caso il problema non si verifica (luckily).
#20 - Scritto il
altrodaniele
Alla luce di quanto detto finora è facile evincere il fatto di non trovarsi di fronte ad un bug di OS X (o di UNIX), ma ad un problema di comunicazione tra 2 piattaforme diverse. Ma proprio per nulla! Se un sistema decide di supportare la scrittura su un filesystem terzo si prende tutte le responsabilità del caso e attua le misure di sicurezza necessarie a scongiurare perdita di dati. Punto. Alla faccia del tifo con il paraocchi! P.S. Uso Mac e ne sono soddisfatto
#21 - Scritto il
kernel_panic
Nel post di Majonchi c'e' un errore: su windows se sposti una cartella contenente piu' file e avviene un errore durante l'operazione, i file spostati prima dell'errore saranno tutti presenti nella cartella di destinazione. Quello che puo' succedere e' che nella cartella sorgente ci siano ancora i file che sono stati creati in quella di destinazione. Ma non c'e' alcun caso in cui ci sia perdita di dati o che vengano cancellati i fili che sono stati creati sul disco di destinazione prima dell'errore. Nell'articolo linkato viene detto molto chiaramente che se copiando da OS X a XP avviene un errore durante lo spostamento ci si ritrova alcuni file su XP e la cartella sorgente su OS X viene cancellata per intero. Questo (se avviene realmente come descritto) e' un baco, comunque lo si guardi.
#22 - Scritto il
Trollone
? Perché hai tirato in ballo samba&c quando nel articolo linkato si parla di chiavette USB?
#23 - Scritto il
Trollone
ops era un update, scusa.
#24 - Scritto il
fotogonade
infatti quoto kernel panic.. non capisco lo sforzo dell'autore del post di voler farci credere che non si tratta di un bug. rappresenta un rischio per l'utente di leopard? sì è un problema? sì è un bug? boh è colpa di Apple? no, di belzubù. maddddai
#25 - Scritto il
deus
va be', perdetevi pure i vostri file. io i miei non li perdo UUHAHHAHAHHAHHH … a proposito delle mie posizioni sul file sharing e la distribuzione gratuita di mp3 per tagliare la filiera delle major… notate l'operazione di Radiohead… come al solito Deus ha sempre ragione. sui cd venduti gli artisti non guadagnano quasi nulla, quindi perchè non distribuirli a tutti via offerta libera? grande Deus.
#26 - Scritto il
deus
@kernel_panic e fotogonade se l'80% dei mac prendesse fuoco nella prima settimana di vita, i macpayer loderebbero Apple perchè permette di risparmiare sul riscaldamento.
#27 - Scritto il
kernel_panic
Forse non e' chiaro a tutti che Majonchi e Tom Karpik stanno dicendo due cose diverse. - Majonchi dice che, se avviene l'errore durante lo spostamento da OS X a XP, i file gia' spostati vengono cancellati sia da OS X che da XP (in questo caso sarebbe un baco di XP, non si discute neppure). - Tom Karpik dice che ci si ritrova con alcuni file su XP (quelli spostati prima dell'errore) e nessuno su OS X (in questo caso sarebbe un baco di OS X). Il punto e' che sia in un caso caso che nell'altro c'e' chiaramente un baco, non e' che sia interpretabile diversamente. Si tratta del piu' grave baco possibile su un sistema informativo: DATA LOSS. Sono il tipo di bachi che internamente vengono marcati come SHOWSTOPPER, ovvero prevengono un prodotto dal venir rilasciato. Si puo' giocare allo scarica barile quanto si vuole, ma sia l'uno che l'altro sarebbero bachi di gravita' massima, altro che "problema di comunicazione tra protocolli" o "caratteristica dell’OS" come ha scritto hallohallohola. Chiaro? O devo fare un disegnino? ;-)
#28 - Scritto il
itmandar
Bisogna chiarire che comunque è un difetto che appare quando si sposta da due diversi volumi con diverso filesystem, e che comunque si verifica solo nel caso di una disconnessione del dispositivo destinatario. Su windows non può accadere, di base si possono usare colo volumi NTFS o FAT. Su mac il bug non si verifica utilizzando volumi HFS(+) Bisognerebbe controllare su linux come ha detto destroyer. Ad ogni modo è un difetto grave, andrebbe corretto quanto prima, strano che si sia scoperto solo adesso.
#29 - Scritto il
caos87
ma il taglia-incolla invece nessuno sa come abilitarlo? c'è l'opzione nel menu ma è disabilitata
#30 - Scritto il
MetalSho
@Parrot E' successo pure a me di perdere file sovrascrivendo una cartella, ma OSX ti avverte quando provi a fare questa operazione. Il discorso è che su Unix le cartelle sono considerati file.
#31 - Scritto il
MetalSho
@caos87 E' disabilitato perché ancora non funziona. L' ho provato.
#32 - Scritto il
jack.o.matic
perchè fate finta di non sentire kernel_panic?
#33 - Scritto il
emmebi
Mia esperienza: Spostando una cartella con dei file (4 o 5 Gb) su un volume condiviso via smb (non windows, ma linux come server) ad un certo punto della copia il finder mi ha detto: non posso scrivere un file perchè il filesystem di destinazione non supporta un carattere nel nome del file o il nome è troppo lungo (una cosa del genere, non mi ricordo il messaggio esatto). Morale i file già copiati erano presenti nel disco di destinazione, i rimanenti vaporizzati all'istante. Siccome il finder si è accorto dell'errore e non ha concluso lo spostamento è un suo errore quello di cancellare i file rimanenti. Lo spostamento lo dovrebbe fare così: copia->hai copiato->si:cancella|no:non cancellare ora fa: copia->chissenefrega->cancella. Così configurato è un baco, molto grosso, nel Finder. Non mi interessa che mi consigli di default la copia, se permette lo spostamento (che altro con è di copia/cancella) lo deve fare bene. P.S.: Sono un mac user dal lontano 84 e windows mi ha fatto molto di peggio, ma questo non mi esula dal rilevare il grosso errore.
#34 - Scritto il
itmandar
Hai ragione, leggendo con più attenzione il post di kernel panic, forse il caso si restringe addirittura al network, che non rende meno grave il difetto, ma almeno lo rende sensato.
#35 - Scritto il
kernel_panic
Se siete veramente interessati all'argomento c'e' questo articoletto (il diminutivo e' riferito alla lunghezza non al contenuto) che e' abbastanza illuminante sull'argomento: <a href='http://rixstep.com/1/1/20071106,00.shtml' rel='nofollow'>http://rixstep.com/1/1/20071106,00.shtml</a>
#36 - Scritto il
Marhio
A me è successo, stavo spostando un file di 300 mb da un hd ad un altro, si è interrotto il trasferimento ed il file è andato perso.. Per fortuna ho poi ritrovato una copia del file in TimeMachine, ora sposto sempre con copia, poi cancello a mano, ve lo consiglio..
#37 - Scritto il
mex
giustamente qui: <a href='http://www.macitynet.it/macity/aA30054/index.shtml' rel='nofollow'>http://www.macitynet.it/macity/aA30054/index.shtml</a> parlano di baco di Leopard… in più Marcello non capisco il tuo discorso visto che il problema si manifesta anche su HD esterni, quindi Samba non centra una beneamata cippa!
#38 - Scritto il
DD
@kernel_panic >- Majonchi dice che, se avviene l’errore durante lo >spostamento da OS X a XP, i file gia’ spostati vengono >cancellati sia da OS X che da XP (in questo caso sarebbe >un baco di XP, non si discute neppure). Scusa….ma dove starebbe scritto che in questo caso è un Bug di XP????? XP effettua gli spostamenti di file in un certo modo, OSX in un'altro. Sta al sistema operativo che "comanda" lo spostamento verificare che non ci sia il rischio di DataLoss. Se OSX si fa carico di supportare le copie tra FS differenti, concordo con quanto detto da altrodaniele, si prende tutte le responsabilità del caso e attua le misure di sicurezza encessarie a scongiurare una perdita di dati. Non capisco davvero su quale base fai un'affermazione del genere…. PS. non voglio scatenare flame ne fare crociate a favore di Microsoft, è giusto per sapere. :-) Un abbraccio
#39 - Scritto il
kernel_panic
DD, sta scritto su qualunque testo di informatica ;-) A meno che non si stia parlando di transazione ACID nel qual caso la cosa avrebbe senso, ma per la copia in rete non c'e' supporto per la transazionalita' quindi non essendoci una clausola "begin transaction {trasferimento dati} end transaction; commit;" una qualunque scrittura remota che restituisca un ACK non puo' subire un rollback da parte del sistema destinatario senza comando esplicito del sistema sorgente. Sono le basi dell'informatica, non le ho inventate io, stanno scritte su tutti i testi sacri.
#40 - Scritto il
kernel_panic
Comunque, DD, su Windows non accade quello affermato da Majonchi, quindi in un certo senso il problema non si pone, infatti io ho usato il condizionale per entrambi i casi, il mio punto era che per entrambi si tratterebbe di bug di massima gravita'.
#41 - Scritto il
DD
>una qualunque scrittura remota che restituisca un ACK >non puo’ subire un rollback da parte del sistema >destinatario senza comando esplicito del sistema >sorgente. Mica mi hai convito sai!! :-) Credo che il problema stia proprio nel fatto che il rollback dovrebbe gestirlo il sistema sorgente. Se mi arriva un ack la copia è andata a buon fine e su XP l'ack arriva solo se TUTTI i file sono stati copiati. Se l'ack non arriva il sistema (OSX) fa scattare il rollback che impedisce la cancellazione dei file sorgente. Se i sistemi unix, in caso di spostamento tra fs differenti, cancellano il file ad ogni singola copia dovrebbero (uso il condizionale) prevedere dei sistemi di sicurezza contro questi problemi. In ogni caso concordo con te sul fatto che si tratti di un bug di eccezionale gravita….. ;-) Un abbraccio DD
#42 - Scritto il
shadow
'non affrettiamoci a sparare sentenze' muahahahaha!…una frase del genere su melablog è come dire ad un pesce 'mi raccomando acqua in bocca'…. gesùgesù…ditemi che era intenzionale, sottile ma intenzionale…voto per il post dell'anno!
#43 - Scritto il
kernel_panic
DD, prova a spostare una cartella da un disco ad un'altro su XP e a premere Cancel a meta' operazione. Vedrai che i files gia' trasferiti saranno nella cartella di destinazione e cancellati da quella sorgente. L'ACK avviene file per file e non solo alla fine della copia del contenuto della cartella. Del resto su XP e ancor meglio su Vista quando si fanno copie/spostamenti si puo' scegliere singolarmente come procedere nel caso di presenza di file con lo stesso nome, quindi se per un file sovrascrivo e per un altro no, come potrebbe venir gestita la cosa se ci fosse un solo ACK finale? ;-)
#44 - Scritto il
deus
madonna, non aveve nemmeno il taglia/incolla per i file? mi dispiace… dai, presto lo implementeranno copiandolo da win che invece ne è dotato da decenni… e meno male che è il miglior sistema operativo del mondo.
#45 - Scritto il
DD
@kernel_panic Ho avuto modo di verificare ed in effetti hai ragione. Mi sono fidato di majonchi senza prima controllare e ho fatto male. Quanto scritto nel suo articolo è sbagliato……riporto testualmente…. ———————— Se passiamo ad analizzare il funzionamento di un sistema DOS, ci troviamo di fronte ad un modo di agire molto diverso. Lo spostamento della directory “test” (che contiene prova1.txt e prova2.txt) da C:/ a D:/documenti è costituito dalle seguenti operazioni: creazione della directory D:/documenti/test/ copia del file prova1.txt in D:/documenti/test/ copia del file prova2.txt in D:/documenti/test/ conferma della copia dei file cancellazione della directory c:/test/ e del suo contenuto Tra i due metodi non se ne può individuare uno migliore, sono semplicemente diversi a causa, come abbiamo già detto, della differente architettura dei due sistemi. In caso di interruzione durante lo spostamento delle directory, i due sistemi si comporteranno in maniera egualmente differente. Su *NIX (e dunque OS X), si avranno una parte dei file nella nuova destinazione ed una parte in quella vecchia. Su DOS (e dunque Windows) si avrà la cartella di origine ed il suo contenuto intatti, mentre nella destinazione i file non saranno mantenuti mancando la conferma della copia totale del contenuto. ————— Un abbraccio
#46 - Scritto il
itmandar
Cmq il problema secondo me non sorge dal tipo di copia che fa OSX o WINDOWS, il problema è l'interazione tra i due che collide, non sto assolutamente giustificando, sto solo cercando di dare un senso a questa cosa. Obiettivamente delle volte mi domando se c'è realmente feedback nelle beta di OSX, ci sono stati a volte casi clamorosi, (come FTFF) portati avanti per anni, cioè cose grossolane. Boh, miliardi di aggiornamenti, ma tutti incentrati sempre su problematiche non comuni, almeno non comuni come questa.
#47 - Scritto il
kernel_panic
itmandar, guarda che il caso non e' limitato al move da OS X a XP, come ha detto Marhio capita anche se sposti da un HD ad un altro e se vai al link del post iniziale vedrai che c'e' un video che mostra il problema quando usi un disco USB. Poi se guardi il link che ho messo io al commento #36 leggi cosa ne pensa uno sviluppatore che OS X lo conosce meglio di tutti noi messi assieme. Su… e' un baco di OS X… inutile stracciarsi le vesti, c'e' ma c'e' anche il workaround… e tutti vissero felici e contenti (quasi… adesso non possono piu' prendere per il culo winzozz ;-) )
#48 - Scritto il
MetalSho
@Kernel_panic Non ti preoccupare… di motivi per prendere per il culo winzozz ce ne saranno sempre a palate hiihihihh :-P
#49 - Scritto il
kernel_panic
Beh questo di OS X e' un baco di proporzioni colossali… DATA LOSS… per di piu' su uno scenario comunissimo… poi c'e' sempre chi trova la pagliuzza nell'occhio dell'altro avendo una bella trave in c… LOL
#50 - Scritto il