Pouruqoi est-il si difficile sur Mac de récupérer un fichier effacé ?
35 réponses
pas.de.spam
Depuis detrès nombreuses années, je vois passer des messages demandant
de l'aide pour récupérer des fichiers effacés, que ce soit sur Mac ou
sur une carte.
J'ai également expérimenté ces difficultés.
Je me souviens de mes débuts dans l'informatique, sur PC sous MS-DOS.
Récupérer un fichier sur lequel on avait fait un "del" intempestif,
était d'une simplicité enfantine (je ne dirais pas biblique, car, selon
moi, la bible est tout sauf simple ... comme les "bibles informatiques",
d'ailleurs). Il suffisait d'avoir un bon utilitaire, qui listait les
fichiers récemment effacés (en fait sous dos, l'effacement consistait à
remplacer le premier caractère du fichier par un autre, spécial. Il
suffisait de redonner au fichier son nom initial pour qu'il
réapparaisse.
Pourquoi diable cela n'est-il pas possible sur Mac ? J'ai beau avoir
essayé des outils comme DataRescue, ou d'autres, aucun ne donne un
résultat pleinement satisfaisant. L'effacement de fichiers est-il donc
géré de manière très très particulière ?
J'ai, ainsi que je l'ai dit il y a quelques temps, commencé un début de vidage de corbeille contenant ma Bibliothèque iTunes (sur un disque externe, donc à priori, non concerné par tous les fichiers générés par le système). Malgré ma tentative, Data Rescue ne me sortait que des fichiers sans leur nom d'origine, et en total désordre, donc inutilisables.
Outre ce que j'ai dit plus haut, j'ajouterais qu'il est impossible d'avoir les noms des fichiers récupérés, car la première chose qui est supprimée quand on supprime un fichier, c'est justement le *** lien *** (lien physique) entre le nom du fichier (entrée dans un répertoire) et le fichier proprement dit (ou plutôt le i-noeud qui permet d'accéder à ce fichier). La raison est qu'un fichier sous Unix peut avoir plusieurs liens physiques, c'est à dire qu'on peut éventuellement accéder à un même fichier par deux chemins différents. Lorsqu'on supprime un fichier on supprime l'un de ces liens. Et lorsque le dernier lien est supprimé, alors le fichier proprement dit est supprimé.
(attention, j'ai eu du mal à trouver des pages en français où il ne disent pas de ~onneries à ce sujet ;-)
Il faut savoir maintenant que les deux propriétés du système Unix dont j'ai parlé ici : 1) le fait qu'il soit multitâche 2) la possibilité de créer plusieurs liens sur un même fichier
sont deux propriétés essentielles, et sont parmi celles (surtout la première) qui ont fait le succès du système Unix.
Les avantages ces deux propriétés font plus que contrebalancer l'inconvénient qui est de ne pas pouvoir récupérer des fichiers malencontreusement effacés. D'autant plus que lorsqu'on prend quelques précautions (ne pas effacer la corbeille de suite, utiliser l'option -i de la commande rm, faire des sauvegardes régulières), on évite cet inconvénient. -- JiPaul. / /--/--// Jean-Paul Blanc |/| L | quelquepart en (somewhere in) /|| = ||| FRANCE
J'ai, ainsi que je l'ai dit il y a quelques temps, commencé un début de
vidage de corbeille contenant ma Bibliothèque iTunes (sur un disque
externe, donc à priori, non concerné par tous les fichiers générés par
le système). Malgré ma tentative, Data Rescue ne me sortait que des
fichiers sans leur nom d'origine, et en total désordre, donc
inutilisables.
Outre ce que j'ai dit plus haut, j'ajouterais qu'il est impossible
d'avoir les noms des fichiers récupérés, car la première chose qui est
supprimée quand on supprime un fichier, c'est justement le *** lien ***
(lien physique) entre le nom du fichier (entrée dans un répertoire) et
le fichier proprement dit (ou plutôt le i-noeud qui permet d'accéder à
ce fichier). La raison est qu'un fichier sous Unix peut avoir plusieurs
liens physiques, c'est à dire qu'on peut éventuellement accéder à un
même fichier par deux chemins différents. Lorsqu'on supprime un fichier
on supprime l'un de ces liens. Et lorsque le dernier lien est supprimé,
alors le fichier proprement dit est supprimé.
(attention, j'ai eu du mal à trouver des pages en français où il ne
disent pas de ~onneries à ce sujet ;-)
Il faut savoir maintenant que les deux propriétés du système Unix dont
j'ai parlé ici :
1) le fait qu'il soit multitâche
2) la possibilité de créer plusieurs liens sur un même fichier
sont deux propriétés essentielles, et sont parmi celles (surtout la
première) qui ont fait le succès du système Unix.
Les avantages ces deux propriétés font plus que contrebalancer
l'inconvénient qui est de ne pas pouvoir récupérer des fichiers
malencontreusement effacés. D'autant plus que lorsqu'on prend quelques
précautions (ne pas effacer la corbeille de suite, utiliser l'option -i
de la commande rm, faire des sauvegardes régulières), on évite cet
inconvénient.
--
JiPaul.
/ /--/--//\ Jean-Paul Blanc
|/| L |\ quelquepart en (somewhere in)
/|| = |||\ FRANCE
J'ai, ainsi que je l'ai dit il y a quelques temps, commencé un début de vidage de corbeille contenant ma Bibliothèque iTunes (sur un disque externe, donc à priori, non concerné par tous les fichiers générés par le système). Malgré ma tentative, Data Rescue ne me sortait que des fichiers sans leur nom d'origine, et en total désordre, donc inutilisables.
Outre ce que j'ai dit plus haut, j'ajouterais qu'il est impossible d'avoir les noms des fichiers récupérés, car la première chose qui est supprimée quand on supprime un fichier, c'est justement le *** lien *** (lien physique) entre le nom du fichier (entrée dans un répertoire) et le fichier proprement dit (ou plutôt le i-noeud qui permet d'accéder à ce fichier). La raison est qu'un fichier sous Unix peut avoir plusieurs liens physiques, c'est à dire qu'on peut éventuellement accéder à un même fichier par deux chemins différents. Lorsqu'on supprime un fichier on supprime l'un de ces liens. Et lorsque le dernier lien est supprimé, alors le fichier proprement dit est supprimé.
(attention, j'ai eu du mal à trouver des pages en français où il ne disent pas de ~onneries à ce sujet ;-)
Il faut savoir maintenant que les deux propriétés du système Unix dont j'ai parlé ici : 1) le fait qu'il soit multitâche 2) la possibilité de créer plusieurs liens sur un même fichier
sont deux propriétés essentielles, et sont parmi celles (surtout la première) qui ont fait le succès du système Unix.
Les avantages ces deux propriétés font plus que contrebalancer l'inconvénient qui est de ne pas pouvoir récupérer des fichiers malencontreusement effacés. D'autant plus que lorsqu'on prend quelques précautions (ne pas effacer la corbeille de suite, utiliser l'option -i de la commande rm, faire des sauvegardes régulières), on évite cet inconvénient. -- JiPaul. / /--/--// Jean-Paul Blanc |/| L | quelquepart en (somewhere in) /|| = ||| FRANCE
Patrick Stadelmann
In article <1itsvw6.yrtd4wqdrjxjN%, (JiPaul) wrote:
Outre ce que j'ai dit plus haut, j'ajouterais qu'il est impossible d'avoir les noms des fichiers récupérés, car la première chose qui est supprimée quand on supprime un fichier, c'est justement le *** lien *** (lien physique) entre le nom du fichier (entrée dans un répertoire) et le fichier proprement dit (ou plutôt le i-noeud qui permet d'accéder à ce fichier).
"supprimer" ne veut pas forcément dire "effacer" : l'entrée peut simplement être marquée comme libre dans le catalogue, sans pour autant être effacée. Le fait que srm commence par renommer le fichier avant de l'effacer (d'après le man) laisse d'ailleurs supposer que le nom pourrait être récupérable,
La raison est qu'un fichier sous Unix peut avoir plusieurs liens physiques, c'est à dire qu'on peut éventuellement accéder à un même fichier par deux chemins différents. Lorsqu'on supprime un fichier on supprime l'un de ces liens. Et lorsque le dernier lien est supprimé, alors le fichier proprement dit est supprimé.
In article <1itsvw6.yrtd4wqdrjxjN%blanc@empty.org>,
blanc@empty.org (JiPaul) wrote:
Outre ce que j'ai dit plus haut, j'ajouterais qu'il est impossible
d'avoir les noms des fichiers récupérés, car la première chose qui est
supprimée quand on supprime un fichier, c'est justement le *** lien ***
(lien physique) entre le nom du fichier (entrée dans un répertoire) et
le fichier proprement dit (ou plutôt le i-noeud qui permet d'accéder à
ce fichier).
"supprimer" ne veut pas forcément dire "effacer" : l'entrée peut
simplement être marquée comme libre dans le catalogue, sans pour autant
être effacée. Le fait que srm commence par renommer le fichier avant de
l'effacer (d'après le man) laisse d'ailleurs supposer que le nom
pourrait être récupérable,
La raison est qu'un fichier sous Unix peut avoir plusieurs
liens physiques, c'est à dire qu'on peut éventuellement accéder à un
même fichier par deux chemins différents. Lorsqu'on supprime un fichier
on supprime l'un de ces liens. Et lorsque le dernier lien est supprimé,
alors le fichier proprement dit est supprimé.
In article <1itsvw6.yrtd4wqdrjxjN%, (JiPaul) wrote:
Outre ce que j'ai dit plus haut, j'ajouterais qu'il est impossible d'avoir les noms des fichiers récupérés, car la première chose qui est supprimée quand on supprime un fichier, c'est justement le *** lien *** (lien physique) entre le nom du fichier (entrée dans un répertoire) et le fichier proprement dit (ou plutôt le i-noeud qui permet d'accéder à ce fichier).
"supprimer" ne veut pas forcément dire "effacer" : l'entrée peut simplement être marquée comme libre dans le catalogue, sans pour autant être effacée. Le fait que srm commence par renommer le fichier avant de l'effacer (d'après le man) laisse d'ailleurs supposer que le nom pourrait être récupérable,
La raison est qu'un fichier sous Unix peut avoir plusieurs liens physiques, c'est à dire qu'on peut éventuellement accéder à un même fichier par deux chemins différents. Lorsqu'on supprime un fichier on supprime l'un de ces liens. Et lorsque le dernier lien est supprimé, alors le fichier proprement dit est supprimé.
In article <4974ab34$0$4051$, Philippe Di Valentin wrote:
Franck a écrit :
> Le système ne défragmente pas les "petits" fichiers tout seul comme un > grand ?
Oui chez tout le monde....y compris en Suisse:-) mais pas chez moi sur deux machines:-(
Soit l'outil que tu utilises pour déterminer le nombre de fragment est buggé, soit tes fichiers ne remplissent pas tous les critères pour être défragmentés (il faut entre autres qu'ils soient en plus de 8 morceaux).
Patrick -- Patrick Stadelmann
In article <4974ab34$0$4051$ba4acef3@news.orange.fr>,
Philippe Di Valentin <Philippe.Divalentin@rien.fr> wrote:
Franck a écrit :
> Le système ne défragmente pas les "petits" fichiers tout seul comme un
> grand ?
Oui chez tout le monde....y compris en Suisse:-) mais pas chez moi
sur deux machines:-(
Soit l'outil que tu utilises pour déterminer le nombre de fragment est
buggé, soit tes fichiers ne remplissent pas tous les critères pour être
défragmentés (il faut entre autres qu'ils soient en plus de 8 morceaux).
Patrick
--
Patrick Stadelmann <Patrick.Stadelmann@unine.ch>
In article <4974ab34$0$4051$, Philippe Di Valentin wrote:
Franck a écrit :
> Le système ne défragmente pas les "petits" fichiers tout seul comme un > grand ?
Oui chez tout le monde....y compris en Suisse:-) mais pas chez moi sur deux machines:-(
Soit l'outil que tu utilises pour déterminer le nombre de fragment est buggé, soit tes fichiers ne remplissent pas tous les critères pour être défragmentés (il faut entre autres qu'ils soient en plus de 8 morceaux).
Patrick -- Patrick Stadelmann
Philippe Di Valentin
Patrick Stadelmann a écrit :
Soit l'outil que tu utilises pour déterminer le nombre de fragment es t buggé, soit tes fichiers ne remplissent pas tous les critères pour être défragmentés (il faut entre autres qu'ils soient en plus de 8 morce aux).
Pas d'inquiétudes l'outil n'est pas buggé,tous les fichiers sont défragmentés quelque soit leur nombre,le nombre de morceaux et leur v aleur.
Patrick Stadelmann a écrit :
Soit l'outil que tu utilises pour déterminer le nombre de fragment es t
buggé, soit tes fichiers ne remplissent pas tous les critères pour être
défragmentés (il faut entre autres qu'ils soient en plus de 8 morce aux).
Pas d'inquiétudes l'outil n'est pas buggé,tous les fichiers sont
défragmentés quelque soit leur nombre,le nombre de morceaux et leur v aleur.
Soit l'outil que tu utilises pour déterminer le nombre de fragment es t buggé, soit tes fichiers ne remplissent pas tous les critères pour être défragmentés (il faut entre autres qu'ils soient en plus de 8 morce aux).
Pas d'inquiétudes l'outil n'est pas buggé,tous les fichiers sont défragmentés quelque soit leur nombre,le nombre de morceaux et leur v aleur.
manet
Patrick Stadelmann wrote:
effectivement ça n'a jamais été facile sur Mac OS.
si, quand meme... Avec des utilitaires très courants dont j'ai oublié le nom, on recuperait tout sans problème.
Je me souviens avoir recupéré sur une machine d'occase l'ensemble des dossiers d'une boite qui organisait des salons sur la sécurité, avec les entreprises et leurs fichiers clients...
Patrick Stadelmann <Patrick.Stadelmann@unine.ch> wrote:
effectivement ça n'a jamais été facile sur Mac OS.
si, quand meme... Avec des utilitaires très courants dont j'ai oublié le
nom, on recuperait tout sans problème.
Je me souviens avoir recupéré sur une machine d'occase l'ensemble des
dossiers d'une boite qui organisait des salons sur la sécurité, avec les
entreprises et leurs fichiers clients...
effectivement ça n'a jamais été facile sur Mac OS.
si, quand meme... Avec des utilitaires très courants dont j'ai oublié le nom, on recuperait tout sans problème.
Je me souviens avoir recupéré sur une machine d'occase l'ensemble des dossiers d'une boite qui organisait des salons sur la sécurité, avec les entreprises et leurs fichiers clients...
romer
Pierre-Olivier TAUBATY wrote:.
Récupérer un fichier sur lequel on avait fait un "del" intempestif, était d'une simplicité enfantine ... Il suffisait d'avoir un bon utilitaire, qui listait les fichiers récemment effacés (en fait sous dos, l'effacement consistait à remplacer le premier caractère du fichier par un autre, spécial. Il suffisait de redonner au fichier son nom initial pour qu'il réapparaisse.
Avec OS 9, on éteignait le Mac en tirant la prise, on rebranchait et on retrouvait la corbeille pleine après l'avoir vidé quelques secondes avant (pas un siècle) ! -- A+
Récupérer un fichier sur lequel on avait fait un "del" intempestif, était
d'une simplicité enfantine ... Il suffisait d'avoir un bon utilitaire, qui
listait les fichiers récemment effacés (en fait sous dos, l'effacement
consistait à remplacer le premier caractère du fichier par un autre,
spécial. Il suffisait de redonner au fichier son nom initial pour qu'il
réapparaisse.
Avec OS 9, on éteignait le Mac en tirant la prise, on rebranchait et on
retrouvait la corbeille pleine après l'avoir vidé quelques secondes
avant (pas un siècle) ! --
A+
Récupérer un fichier sur lequel on avait fait un "del" intempestif, était d'une simplicité enfantine ... Il suffisait d'avoir un bon utilitaire, qui listait les fichiers récemment effacés (en fait sous dos, l'effacement consistait à remplacer le premier caractère du fichier par un autre, spécial. Il suffisait de redonner au fichier son nom initial pour qu'il réapparaisse.
Avec OS 9, on éteignait le Mac en tirant la prise, on rebranchait et on retrouvait la corbeille pleine après l'avoir vidé quelques secondes avant (pas un siècle) ! -- A+
Romer
blanc
Patrick Stadelmann wrote:
"supprimer" ne veut pas forcément dire "effacer" : l'entrée peut simplement être marquée comme libre dans le catalogue, sans pour autant être effacée.
Certes.
Le fait que srm commence par renommer le fichier avant de l'effacer (d'après le man) laisse d'ailleurs supposer que le nom pourrait être récupérable,
Bon. Ok.
> La raison est qu'un fichier sous Unix peut avoir plusieurs > liens physiques, c'est à dire qu'on peut éventuellement accéder à un > même fichier par deux chemins différents. Lorsqu'on supprime un fichier > on supprime l'un de ces liens. Et lorsque le dernier lien est supprimé, > alors le fichier proprement dit est supprimé. > > Pour plus d'infos, voir par exemple : > > <http://www.linux-france.org/article/dalox/unix02.htm#lesin> > <http://www-h.eng.cam.ac.uk/help/sjm/unix/FileSystem.html>
HFS+ gère cela différemment car il ne supporte pas "nativement" cette fonctionnalité.
Et bien j'ai appris quelque chose ce soir. Merci :-)
-- JiPaul. / /--/--// Jean-Paul Blanc |/| L | quelquepart en (somewhere in) /|| = ||| FRANCE
Patrick Stadelmann <Patrick.Stadelmann@unine.ch> wrote:
"supprimer" ne veut pas forcément dire "effacer" : l'entrée peut
simplement être marquée comme libre dans le catalogue, sans pour autant
être effacée.
Certes.
Le fait que srm commence par renommer le fichier avant de
l'effacer (d'après le man) laisse d'ailleurs supposer que le nom
pourrait être récupérable,
Bon. Ok.
> La raison est qu'un fichier sous Unix peut avoir plusieurs
> liens physiques, c'est à dire qu'on peut éventuellement accéder à un
> même fichier par deux chemins différents. Lorsqu'on supprime un fichier
> on supprime l'un de ces liens. Et lorsque le dernier lien est supprimé,
> alors le fichier proprement dit est supprimé.
>
> Pour plus d'infos, voir par exemple :
>
> <http://www.linux-france.org/article/dalox/unix02.htm#lesin>
> <http://www-h.eng.cam.ac.uk/help/sjm/unix/FileSystem.html>
HFS+ gère cela différemment car il ne supporte pas "nativement" cette
fonctionnalité.
"supprimer" ne veut pas forcément dire "effacer" : l'entrée peut simplement être marquée comme libre dans le catalogue, sans pour autant être effacée.
Certes.
Le fait que srm commence par renommer le fichier avant de l'effacer (d'après le man) laisse d'ailleurs supposer que le nom pourrait être récupérable,
Bon. Ok.
> La raison est qu'un fichier sous Unix peut avoir plusieurs > liens physiques, c'est à dire qu'on peut éventuellement accéder à un > même fichier par deux chemins différents. Lorsqu'on supprime un fichier > on supprime l'un de ces liens. Et lorsque le dernier lien est supprimé, > alors le fichier proprement dit est supprimé. > > Pour plus d'infos, voir par exemple : > > <http://www.linux-france.org/article/dalox/unix02.htm#lesin> > <http://www-h.eng.cam.ac.uk/help/sjm/unix/FileSystem.html>
HFS+ gère cela différemment car il ne supporte pas "nativement" cette fonctionnalité.
Et bien j'ai appris quelque chose ce soir. Merci :-)
-- JiPaul. / /--/--// Jean-Paul Blanc |/| L | quelquepart en (somewhere in) /|| = ||| FRANCE
pas.de.spam
Philippe Manet wrote:
Patrick Stadelmann wrote:
> effectivement ça n'a jamais été facile sur Mac OS.
si, quand meme... Avec des utilitaires très courants dont j'ai oublié le nom, on recuperait tout sans problème.
mmouais, c'est pas l'expérience que j'en ai eu. J'ai un jour fait une connerie sur le disque d'un client (et heureusement ami), et je me souviens avoir bataillé comme un damné pour récupérer à peine 10 %. C'était à l'époque sous système 6 et quelque (avant le 7). Et pourtant, ma logithèque était plutôt développée à l'époque.
-- PO.
Pour m'écrire : po_taubaty(arobas)yahoo(point)fr
Philippe Manet <manet@invivo.edu> wrote:
Patrick Stadelmann <Patrick.Stadelmann@unine.ch> wrote:
> effectivement ça n'a jamais été facile sur Mac OS.
si, quand meme... Avec des utilitaires très courants dont j'ai oublié le
nom, on recuperait tout sans problème.
mmouais, c'est pas l'expérience que j'en ai eu. J'ai un jour fait une
connerie sur le disque d'un client (et heureusement ami), et je me
souviens avoir bataillé comme un damné pour récupérer à peine 10 %.
C'était à l'époque sous système 6 et quelque (avant le 7). Et pourtant,
ma logithèque était plutôt développée à l'époque.
> effectivement ça n'a jamais été facile sur Mac OS.
si, quand meme... Avec des utilitaires très courants dont j'ai oublié le nom, on recuperait tout sans problème.
mmouais, c'est pas l'expérience que j'en ai eu. J'ai un jour fait une connerie sur le disque d'un client (et heureusement ami), et je me souviens avoir bataillé comme un damné pour récupérer à peine 10 %. C'était à l'époque sous système 6 et quelque (avant le 7). Et pourtant, ma logithèque était plutôt développée à l'époque.
-- PO.
Pour m'écrire : po_taubaty(arobas)yahoo(point)fr
patrick.1200RTcazaux
Philippe Manet wrote:
Avec des utilitaires très courants dont j'ai oublié le nom, on recuperait tout sans problème.
Il y a fort longtemps, du temps du system 6, avec Norton Utilities, on récupérait pas mal de trucs, je confirme.
-- Tardigradus
Philippe Manet <manet@invivo.edu> wrote:
Avec des utilitaires très courants dont j'ai oublié le
nom, on recuperait tout sans problème.
Il y a fort longtemps, du temps du system 6, avec Norton Utilities, on
récupérait pas mal de trucs, je confirme.
Avec des utilitaires très courants dont j'ai oublié le nom, on recuperait tout sans problème.
Il y a fort longtemps, du temps du system 6, avec Norton Utilities, on récupérait pas mal de trucs, je confirme.
-- Tardigradus
Patrick Stadelmann
In article <1itu7ub.1c4gyxejp2l69N%, (Tardigradus) wrote:
Philippe Manet wrote:
> Avec des utilitaires très courants dont j'ai oublié le > nom, on recuperait tout sans problème.
Il y a fort longtemps, du temps du system 6, avec Norton Utilities, on récupérait pas mal de trucs, je confirme.
Oui, mais avec sa fonction (File Saver je crois) qui conservait des copies des informations importantes avant que les fichiers ne soient effacés, j'imagine. Parce que les quelques fois où je l'ai utilisé sur un disque sans File Saver, il ne retrouvait pas grand chose, ou alors des centaines de fichiers sans nom et dont le contenu était souvent en partie ou totalement corrompu.
Patrick -- Patrick Stadelmann
In article
<1itu7ub.1c4gyxejp2l69N%patrick.1200RTcazaux@cadratin.fr.invalid>,
patrick.1200RTcazaux@cadratin.fr.invalid (Tardigradus) wrote:
Philippe Manet <manet@invivo.edu> wrote:
> Avec des utilitaires très courants dont j'ai oublié le
> nom, on recuperait tout sans problème.
Il y a fort longtemps, du temps du system 6, avec Norton Utilities, on
récupérait pas mal de trucs, je confirme.
Oui, mais avec sa fonction (File Saver je crois) qui conservait des
copies des informations importantes avant que les fichiers ne soient
effacés, j'imagine. Parce que les quelques fois où je l'ai utilisé sur
un disque sans File Saver, il ne retrouvait pas grand chose, ou alors
des centaines de fichiers sans nom et dont le contenu était souvent en
partie ou totalement corrompu.
Patrick
--
Patrick Stadelmann <Patrick.Stadelmann@unine.ch>
In article <1itu7ub.1c4gyxejp2l69N%, (Tardigradus) wrote:
Philippe Manet wrote:
> Avec des utilitaires très courants dont j'ai oublié le > nom, on recuperait tout sans problème.
Il y a fort longtemps, du temps du system 6, avec Norton Utilities, on récupérait pas mal de trucs, je confirme.
Oui, mais avec sa fonction (File Saver je crois) qui conservait des copies des informations importantes avant que les fichiers ne soient effacés, j'imagine. Parce que les quelques fois où je l'ai utilisé sur un disque sans File Saver, il ne retrouvait pas grand chose, ou alors des centaines de fichiers sans nom et dont le contenu était souvent en partie ou totalement corrompu.
