J'envisage d'acheter un serveur réseau LaCie pour centraliser les
backups "time machine" d'une demi-douzaine de macs sous le futur OSX.
Mon souci est le suivant: ce que je sais des specs Apple sur la question
est assez maigre:
- Time Machine va fonctionner sur tout serveur même réseau mais il faut
que celui-ci soit formaté HFS+
- Time Machine utilise(rait?) des symlinks hard pour facilement remettre
à jour/éliminer les fichiers lors des sauvegardes incrémentales.
Par ailleurs, les NAS LaCie (ex. ceux nommés "Ethernet Disk" sur leur
site) n'indiquent pas le format du disque interne; on arrive tout juste
à découvrir au détour d'un commentaire que manifestement ils supportent
le protocole AFP et apparemment n'importe quel nom de fichier "type
Apple", mais pas moyen de savoir ce qu'il se passe par ex. si on veut
créer un symlink dans le volume NAS.
Je crains, par exemple, que si LaCie "simule" le format Apple par-dessus
un autre format réel, ça ne ralentisse tout dans le cas où Time Machine
enverrait des rafales de symlinks.
Je crains aussi de n'avoir pas assez d'information (voire des
informations fausses: Apple comme LaCie sont peu réactifs dans les
détails en ce moment), mais d'un autre côté il est important pour moi
d'avoir le serveur prêt avant l'arrivée d'OSX :-(
Ma question est la suivante: quelqu'un a-t-il plus d'information, et/ou
testé un NAS LaCie avec une version dev de Leopard?
Merci!
Hervé
--
Frédérique & Hervé Sainct, h.sainct@laposte.net [fr,es,en,it]
Frédérique's initial is missing in front of the above address
l'initiale de Frédérique manque devant l'adresse email ci-dessus
Nicolas MICHEL <Nicolas-MICHEL'_remove_'@bluewin.ch> wrote:
Un exemple au hasard, j'ai un dossier Mail qui fait 786 Mo et 28'410 fichiers. Si je renomes mon dossier inbox, je suppose que Time Machine va recopier les 28k fichiers. Non ?
Pourquoi donc irait-il recopier le contenu d'un dossier dont seul le nom a changé ?
C'est comme ça que travaillent tous les outils de synchro que je connais. L'inverse demanderais une analyse du contennu que permet peut-être l'indexation spootlight, mais que je fait pas rsync par exemple.
-- Nicolas - MICHEL at bluewin point ch AIM : michelnicolas
Nicolas MICHEL <Nicolas-MICHEL'_remove_'@bluewin.ch> wrote:
Un exemple au hasard, j'ai un dossier Mail qui fait 786 Mo et 28'410
fichiers. Si je renomes mon dossier inbox, je suppose que Time Machine
va recopier les 28k fichiers. Non ?
Pourquoi donc irait-il recopier le contenu d'un dossier dont seul le nom
a changé ?
C'est comme ça que travaillent tous les outils de synchro que je
connais.
L'inverse demanderais une analyse du contennu que permet peut-être
l'indexation spootlight, mais que je fait pas rsync par exemple.
--
Nicolas - MICHEL at bluewin point ch
AIM : michelnicolas
Nicolas MICHEL <Nicolas-MICHEL'_remove_'@bluewin.ch> wrote:
Un exemple au hasard, j'ai un dossier Mail qui fait 786 Mo et 28'410 fichiers. Si je renomes mon dossier inbox, je suppose que Time Machine va recopier les 28k fichiers. Non ?
Pourquoi donc irait-il recopier le contenu d'un dossier dont seul le nom a changé ?
C'est comme ça que travaillent tous les outils de synchro que je connais. L'inverse demanderais une analyse du contennu que permet peut-être l'indexation spootlight, mais que je fait pas rsync par exemple.
-- Nicolas - MICHEL at bluewin point ch AIM : michelnicolas
Anonyme
Nicolas MICHEL <Nicolas-MICHEL'_remove_'@bluewin.ch> wrote:
Un exemple au hasard, j'ai un dossier Mail qui fait 786 Mo et 28'410 fichiers. Si je renomes mon dossier inbox, je suppose que Time Machine va recopier les 28k fichiers. Non ?
Non, et merci les liens durs de dossier. Il fera simplement un lien dur sur le dossier (enfin, pas forcément si simple si y'a eu des modifs dans le dossier en plus du renommage, mais bon, on va pas refaire l'algo de TimeMachine ici).
ça prendra combien de temps ?
Quelques cycles du processeur...
-- Anonyme ( jayce <@> mosx.org ) ********* MosX.org <http://www.mosx.org/> ********* (MosX.net renaît sous le nom MosX.org...)
Nicolas MICHEL <Nicolas-MICHEL'_remove_'@bluewin.ch> wrote:
Un exemple au hasard, j'ai un dossier Mail qui fait 786 Mo et 28'410
fichiers. Si je renomes mon dossier inbox, je suppose que Time Machine
va recopier les 28k fichiers. Non ?
Non, et merci les liens durs de dossier.
Il fera simplement un lien dur sur le dossier (enfin, pas forcément si
simple si y'a eu des modifs dans le dossier en plus du renommage, mais
bon, on va pas refaire l'algo de TimeMachine ici).
ça prendra combien de temps ?
Quelques cycles du processeur...
--
Anonyme ( jayce <@> mosx.org )
********* MosX.org <http://www.mosx.org/> *********
(MosX.net renaît sous le nom MosX.org...)
Nicolas MICHEL <Nicolas-MICHEL'_remove_'@bluewin.ch> wrote:
Un exemple au hasard, j'ai un dossier Mail qui fait 786 Mo et 28'410 fichiers. Si je renomes mon dossier inbox, je suppose que Time Machine va recopier les 28k fichiers. Non ?
Non, et merci les liens durs de dossier. Il fera simplement un lien dur sur le dossier (enfin, pas forcément si simple si y'a eu des modifs dans le dossier en plus du renommage, mais bon, on va pas refaire l'algo de TimeMachine ici).
ça prendra combien de temps ?
Quelques cycles du processeur...
-- Anonyme ( jayce <@> mosx.org ) ********* MosX.org <http://www.mosx.org/> ********* (MosX.net renaît sous le nom MosX.org...)
Anonyme
Fra wrote:
Pourtant je me souviens d'un époque où le fait de faire passer un .dmg via une clé usb formaté fat32 suffisait à le pourrir.
Les .img... Ou alors les .dmg compressés. Les .dmg non compressés n'ont que les datas d'utiles.
-- Anonyme ( jayce <@> mosx.org ) ********* MosX.org <http://www.mosx.org/> ********* (MosX.net renaît sous le nom MosX.org...)
Fra <fra@alussinan.org> wrote:
Pourtant je me souviens d'un époque où le fait de faire passer un .dmg
via une clé usb formaté fat32 suffisait à le pourrir.
Les .img... Ou alors les .dmg compressés. Les .dmg non compressés n'ont
que les datas d'utiles.
--
Anonyme ( jayce <@> mosx.org )
********* MosX.org <http://www.mosx.org/> *********
(MosX.net renaît sous le nom MosX.org...)
Pourtant je me souviens d'un époque où le fait de faire passer un .dmg via une clé usb formaté fat32 suffisait à le pourrir.
Les .img... Ou alors les .dmg compressés. Les .dmg non compressés n'ont que les datas d'utiles.
-- Anonyme ( jayce <@> mosx.org ) ********* MosX.org <http://www.mosx.org/> ********* (MosX.net renaît sous le nom MosX.org...)
laurent.pertois
Nicolas MICHEL <Nicolas-MICHEL'_remove_'@bluewin.ch> wrote:
Laurent Pertois wrote:
Pourquoi donc irait-il recopier le contenu d'un dossier dont seul le nom a changé ?
C'est comme ça que travaillent tous les outils de synchro que je connais.
Donc, ça veut dire qu'il faut que tout le monde fasse pareil ?
L'inverse demanderais une analyse du contennu que permet peut-être l'indexation spootlight, mais que je fait pas rsync par exemple.
Eh bien TimeMachine s'appuie sur le fsevents (utilisés aussi par Spotlight) et ensuite utilise les liens hard pour ne pas recopier ce qui n'a pas changé (en résumé) :
Ca offre un assez bon résumé de la manière dont ça fonctionne.
-- Politically Correct Unix - UTILITIES The "touch" command has been removed from the standard distribution due to its inappropriate use by high-level managers.
Nicolas MICHEL <Nicolas-MICHEL'_remove_'@bluewin.ch> wrote:
Pourquoi donc irait-il recopier le contenu d'un dossier dont seul le nom
a changé ?
C'est comme ça que travaillent tous les outils de synchro que je
connais.
Donc, ça veut dire qu'il faut que tout le monde fasse pareil ?
L'inverse demanderais une analyse du contennu que permet peut-être
l'indexation spootlight, mais que je fait pas rsync par exemple.
Eh bien TimeMachine s'appuie sur le fsevents (utilisés aussi par
Spotlight) et ensuite utilise les liens hard pour ne pas recopier ce qui
n'a pas changé (en résumé) :
Ca offre un assez bon résumé de la manière dont ça fonctionne.
--
Politically Correct Unix - UTILITIES
The "touch" command has been removed from the standard distribution due
to its inappropriate use by high-level managers.
Nicolas MICHEL <Nicolas-MICHEL'_remove_'@bluewin.ch> wrote:
Laurent Pertois wrote:
Pourquoi donc irait-il recopier le contenu d'un dossier dont seul le nom a changé ?
C'est comme ça que travaillent tous les outils de synchro que je connais.
Donc, ça veut dire qu'il faut que tout le monde fasse pareil ?
L'inverse demanderais une analyse du contennu que permet peut-être l'indexation spootlight, mais que je fait pas rsync par exemple.
Eh bien TimeMachine s'appuie sur le fsevents (utilisés aussi par Spotlight) et ensuite utilise les liens hard pour ne pas recopier ce qui n'a pas changé (en résumé) :
Ca offre un assez bon résumé de la manière dont ça fonctionne.
-- Politically Correct Unix - UTILITIES The "touch" command has been removed from the standard distribution due to its inappropriate use by high-level managers.
fra
Anonyme wrote:
Pourtant je me souviens d'un époque où le fait de faire passer un .dmg via une clé usb formaté fat32 suffisait à le pourrir.
Les .img...
Oui peut êtr. C'était dû à quoi ? Ca le ferais encore ? -- Fra
Anonyme <jayce@mosx.org> wrote:
Pourtant je me souviens d'un époque où le fait de faire passer un .dmg
via une clé usb formaté fat32 suffisait à le pourrir.
Les .img...
Oui peut êtr. C'était dû à quoi ? Ca le ferais encore ?
--
Fra
In article <1i6fvik.1nvqphi1o5j3udN%, (Anonyme) wrote:
Les .img avaient tout en resource.
Euh! le principal était en data, la partie "resource" pouvait être oublié.
C'était plus critique pour les .smi surtout pour les images segmentées,, qui avaient le binaire en resource.
Les .dmg avec compression ont l'algo de compression en resource.
Ce ne semble plus être le cas... (Mac OS X 10.4.10)
-- Jacques PERROCHEAU Synthèse et Electrosynthèse Organiques, C.N.R.S. UMR 6510 Université de Rennes I, Campus de Beaulieu, F-35042 RENNES Cedex Tel: +33 2 23 23 63 74, Fax: +33 2 23 23 63 74
fra
Anonyme wrote:
Oui peut être. C'était dû à quoi ? Ca le ferais encore ?
C'était dû à une mauvaise gestion du Resource Fork...
Une application qui utilise des ressources pourrait aussi poser probleme alors ? Cette gestion des ressources a-t-elle été corrigée dans Mac OS X ? -- Fra
Anonyme <jayce@mosx.org> wrote:
Oui peut être. C'était dû à quoi ? Ca le ferais encore ?
C'était dû à une mauvaise gestion du Resource Fork...
Une application qui utilise des ressources pourrait aussi poser probleme
alors ? Cette gestion des ressources a-t-elle été corrigée dans Mac OS X
?
--
Fra
Oui peut être. C'était dû à quoi ? Ca le ferais encore ?
C'était dû à une mauvaise gestion du Resource Fork...
Une application qui utilise des ressources pourrait aussi poser probleme alors ? Cette gestion des ressources a-t-elle été corrigée dans Mac OS X ? -- Fra
Patrick Stadelmann
In article <1i6g8fq.yzvysc1juyfpcN%, (Fra) wrote:
Anonyme wrote:
Oui peut être. C'était dû à quoi ? Ca le ferais encore ?
C'était dû à une mauvaise gestion du Resource Fork...
Une application qui utilise des ressources pourrait aussi poser probleme alors ? Cette gestion des ressources a-t-elle été corrigée dans Mac OS X ?
Non, le Mac sait depuis longtemps stocker et récupérer les ressources sur un volume FAT. Les problèmes ne se posent que quand les fichiers ont été manipulés sur un PC (copie, déplacement) ou quand la méthode de stockage est différente entre le Mac qui a écrit les fichiers et celui qui les relis. C'est le cas entre Mac OS 9 et Mac OS X. Sinon, tout cela est transparent pour les applications.
Patrick -- Patrick Stadelmann
In article <1i6g8fq.yzvysc1juyfpcN%fra@alussinan.org>,
fra@alussinan.org (Fra) wrote:
Anonyme <jayce@mosx.org> wrote:
Oui peut être. C'était dû à quoi ? Ca le ferais encore ?
C'était dû à une mauvaise gestion du Resource Fork...
Une application qui utilise des ressources pourrait aussi poser probleme
alors ? Cette gestion des ressources a-t-elle été corrigée dans Mac OS X
?
Non, le Mac sait depuis longtemps stocker et récupérer les ressources
sur un volume FAT. Les problèmes ne se posent que quand les fichiers ont
été manipulés sur un PC (copie, déplacement) ou quand la méthode de
stockage est différente entre le Mac qui a écrit les fichiers et celui
qui les relis. C'est le cas entre Mac OS 9 et Mac OS X. Sinon, tout cela
est transparent pour les applications.
Patrick
--
Patrick Stadelmann <Patrick.Stadelmann@unine.ch>
Oui peut être. C'était dû à quoi ? Ca le ferais encore ?
C'était dû à une mauvaise gestion du Resource Fork...
Une application qui utilise des ressources pourrait aussi poser probleme alors ? Cette gestion des ressources a-t-elle été corrigée dans Mac OS X ?
Non, le Mac sait depuis longtemps stocker et récupérer les ressources sur un volume FAT. Les problèmes ne se posent que quand les fichiers ont été manipulés sur un PC (copie, déplacement) ou quand la méthode de stockage est différente entre le Mac qui a écrit les fichiers et celui qui les relis. C'est le cas entre Mac OS 9 et Mac OS X. Sinon, tout cela est transparent pour les applications.
Patrick -- Patrick Stadelmann
fra
Patrick Stadelmann wrote:
Non, le Mac sait depuis longtemps stocker et récupérer les ressources sur un volume FAT. Les problèmes ne se posent que quand les fichiers ont été manipulés sur un PC (copie, déplacement) ou quand la méthode de stockage est différente entre le Mac qui a écrit les fichiers et celui qui les relis. C'est le cas entre Mac OS 9 et Mac OS X. Sinon, tout cela est transparent pour les applications.
OK. Merci. Time Machine et NAS serait donc envisageable... -- Fra
Patrick Stadelmann <Patrick.Stadelmann@unine.ch> wrote:
Non, le Mac sait depuis longtemps stocker et récupérer les ressources
sur un volume FAT. Les problèmes ne se posent que quand les fichiers ont
été manipulés sur un PC (copie, déplacement) ou quand la méthode de
stockage est différente entre le Mac qui a écrit les fichiers et celui
qui les relis. C'est le cas entre Mac OS 9 et Mac OS X. Sinon, tout cela
est transparent pour les applications.
OK. Merci. Time Machine et NAS serait donc envisageable...
--
Fra
Non, le Mac sait depuis longtemps stocker et récupérer les ressources sur un volume FAT. Les problèmes ne se posent que quand les fichiers ont été manipulés sur un PC (copie, déplacement) ou quand la méthode de stockage est différente entre le Mac qui a écrit les fichiers et celui qui les relis. C'est le cas entre Mac OS 9 et Mac OS X. Sinon, tout cela est transparent pour les applications.
OK. Merci. Time Machine et NAS serait donc envisageable... -- Fra
