[Time Machine] Y a t'il un moeyn de savoir ce qu'il copie vraiment ?
18 réponses
pas.de.spam
Bonjour à tous,
J'aimerais savoir s'il y un moyen simple de voir ce que copie réellement
Time Machine dans une sauvegarde donnée. Car de temps en temps, il lui
prend la fantaisie de se mettre à faire une sauvegarde de plusieurs Go
(jusqu'à 35 !)
alors que je n'ai pas tant modifié de données. Je soupçonne un
fonctionnement erratique quant à certains dossiers : il doit les
recopier intégralement au lieu de ne prendre que ce qui a été modifié à
l'intérieur.
Vu qu'il créedes hard links, un simple coup d'oeil dans les répertoires
ne renseigne pas beaucoup ...
Je crains que ce programme ne soit pas le miracle tant attendu, ... ,
comme beaucoup de ce qui est présenté par Steve Jobs et qui semble si
alléchant à la présentation, hélas ...
Je vais voir ce que ça donne au bout d'une quinzaine de jours, lorsque
les sauvegardes quotidiennes seront éliminées chaque semaine ...
Parce que là, il m'a facile bouffé 100 Go par rapport à la première
sauvegarde ... si ça continue à ce rythme, c'est pas un Mac Pro qu'il va
me falloir, mais une baie de Xsan ... manque de pot, ça se fait plus :D
:D
In article <1ig5oi7.197yhsl1pumcf6N%, (Pierre-Olivier TAUBATY) wrote:
J'aimerais savoir s'il y un moyen simple de voir ce que copie réellement Time Machine dans une sauvegarde donnée. Car de temps en temps, il lui prend la fantaisie de se mettre à faire une sauvegarde de plusieurs Go (jusqu'à 35 !) alors que je n'ai pas tant modifié de données. Je soupçonne un fonctionnement erratique quant à certains dossiers : il doit les recopier intégralement au lieu de ne prendre que ce qui a été modifié à l'intérieur.
Vu que si le fichier de doit pas être copié, TM crée un hard link vers le fichier existant déjà dans le backup, on peut en déduire que les fichiers créés lors du dernier backup doivent avoir leur "compteur de link" à 1 (i.e. il n'y a qu'une entrée dans le catalogue qui référence ce fichier). Donc la commande :
find /Volumes/Backup/Backups.backupdb/Leopard G5/Latest/ -links 1 -exec ls -l {} ;
(sur une seul ligne)
devrait te donner la liste des fichiers copiés lors du dernier backup.
Patrick -- Patrick Stadelmann
In article <1ig5oi7.197yhsl1pumcf6N%pas.de.spam@chez.moi>,
pas.de.spam@chez.moi (Pierre-Olivier TAUBATY) wrote:
J'aimerais savoir s'il y un moyen simple de voir ce que copie réellement
Time Machine dans une sauvegarde donnée. Car de temps en temps, il lui
prend la fantaisie de se mettre à faire une sauvegarde de plusieurs Go
(jusqu'à 35 !)
alors que je n'ai pas tant modifié de données. Je soupçonne un
fonctionnement erratique quant à certains dossiers : il doit les
recopier intégralement au lieu de ne prendre que ce qui a été modifié à
l'intérieur.
Vu que si le fichier de doit pas être copié, TM crée un hard link vers
le fichier existant déjà dans le backup, on peut en déduire que les
fichiers créés lors du dernier backup doivent avoir leur "compteur de
link" à 1 (i.e. il n'y a qu'une entrée dans le catalogue qui référence
ce fichier). Donc la commande :
find /Volumes/Backup/Backups.backupdb/Leopard G5/Latest/ -links 1
-exec ls -l {} ;
(sur une seul ligne)
devrait te donner la liste des fichiers copiés lors du dernier backup.
Patrick
--
Patrick Stadelmann <Patrick.Stadelmann@unine.ch>
In article <1ig5oi7.197yhsl1pumcf6N%, (Pierre-Olivier TAUBATY) wrote:
J'aimerais savoir s'il y un moyen simple de voir ce que copie réellement Time Machine dans une sauvegarde donnée. Car de temps en temps, il lui prend la fantaisie de se mettre à faire une sauvegarde de plusieurs Go (jusqu'à 35 !) alors que je n'ai pas tant modifié de données. Je soupçonne un fonctionnement erratique quant à certains dossiers : il doit les recopier intégralement au lieu de ne prendre que ce qui a été modifié à l'intérieur.
Vu que si le fichier de doit pas être copié, TM crée un hard link vers le fichier existant déjà dans le backup, on peut en déduire que les fichiers créés lors du dernier backup doivent avoir leur "compteur de link" à 1 (i.e. il n'y a qu'une entrée dans le catalogue qui référence ce fichier). Donc la commande :
find /Volumes/Backup/Backups.backupdb/Leopard G5/Latest/ -links 1 -exec ls -l {} ;
(sur une seul ligne)
devrait te donner la liste des fichiers copiés lors du dernier backup.
Patrick -- Patrick Stadelmann
Patrick Stadelmann
In article <1ig5oi7.197yhsl1pumcf6N%, (Pierre-Olivier TAUBATY) wrote:
J'aimerais savoir s'il y un moyen simple de voir ce que copie réellement Time Machine dans une sauvegarde donnée. Car de temps en temps, il lui prend la fantaisie de se mettre à faire une sauvegarde de plusieurs Go (jusqu'à 35 !) alors que je n'ai pas tant modifié de données. Je soupçonne un fonctionnement erratique quant à certains dossiers : il doit les recopier intégralement au lieu de ne prendre que ce qui a été modifié à l'intérieur.
Vu que si le fichier de doit pas être copié, TM crée un hard link vers le fichier existant déjà dans le backup, on peut en déduire que les fichiers créés lors du dernier backup doivent avoir leur "compteur de link" à 1 (i.e. il n'y a qu'une entrée dans le catalogue qui référence ce fichier). Donc la commande :
find /Volumes/Backup/Backups.backupdb/Leopard G5/Latest/ -links 1 -exec ls -l {} ;
(sur une seul ligne, et remplacer adapter le chemin)
devrait te donner la liste des fichiers copiés lors du dernier backup.
Patrick -- Patrick Stadelmann
In article <1ig5oi7.197yhsl1pumcf6N%pas.de.spam@chez.moi>,
pas.de.spam@chez.moi (Pierre-Olivier TAUBATY) wrote:
J'aimerais savoir s'il y un moyen simple de voir ce que copie réellement
Time Machine dans une sauvegarde donnée. Car de temps en temps, il lui
prend la fantaisie de se mettre à faire une sauvegarde de plusieurs Go
(jusqu'à 35 !)
alors que je n'ai pas tant modifié de données. Je soupçonne un
fonctionnement erratique quant à certains dossiers : il doit les
recopier intégralement au lieu de ne prendre que ce qui a été modifié à
l'intérieur.
Vu que si le fichier de doit pas être copié, TM crée un hard link vers
le fichier existant déjà dans le backup, on peut en déduire que les
fichiers créés lors du dernier backup doivent avoir leur "compteur de
link" à 1 (i.e. il n'y a qu'une entrée dans le catalogue qui référence
ce fichier). Donc la commande :
find /Volumes/Backup/Backups.backupdb/Leopard G5/Latest/ -links 1
-exec ls -l {} ;
(sur une seul ligne, et remplacer adapter le chemin)
devrait te donner la liste des fichiers copiés lors du dernier backup.
Patrick
--
Patrick Stadelmann <Patrick.Stadelmann@unine.ch>
In article <1ig5oi7.197yhsl1pumcf6N%, (Pierre-Olivier TAUBATY) wrote:
J'aimerais savoir s'il y un moyen simple de voir ce que copie réellement Time Machine dans une sauvegarde donnée. Car de temps en temps, il lui prend la fantaisie de se mettre à faire une sauvegarde de plusieurs Go (jusqu'à 35 !) alors que je n'ai pas tant modifié de données. Je soupçonne un fonctionnement erratique quant à certains dossiers : il doit les recopier intégralement au lieu de ne prendre que ce qui a été modifié à l'intérieur.
Vu que si le fichier de doit pas être copié, TM crée un hard link vers le fichier existant déjà dans le backup, on peut en déduire que les fichiers créés lors du dernier backup doivent avoir leur "compteur de link" à 1 (i.e. il n'y a qu'une entrée dans le catalogue qui référence ce fichier). Donc la commande :
find /Volumes/Backup/Backups.backupdb/Leopard G5/Latest/ -links 1 -exec ls -l {} ;
(sur une seul ligne, et remplacer adapter le chemin)
devrait te donner la liste des fichiers copiés lors du dernier backup.
Patrick -- Patrick Stadelmann
Patrick Stadelmann
In article <1ig5oi7.197yhsl1pumcf6N%, (Pierre-Olivier TAUBATY) wrote:
J'aimerais savoir s'il y un moyen simple de voir ce que copie réellement Time Machine dans une sauvegarde donnée. Car de temps en temps, il lui prend la fantaisie de se mettre à faire une sauvegarde de plusieurs Go (jusqu'à 35 !) alors que je n'ai pas tant modifié de données. Je soupçonne un fonctionnement erratique quant à certains dossiers : il doit les recopier intégralement au lieu de ne prendre que ce qui a été modifié à l'intérieur.
Vu que si le fichier de doit pas être copié, TM crée un hard link vers le fichier existant déjà dans le backup, on peut en déduire que les fichiers créés lors du dernier backup doivent avoir leur "compteur de link" à 1 (i.e. il n'y a qu'une entrée dans le catalogue qui référence ce fichier). Donc la commande :
find /Volumes/Backup/Backups.backupdb/Leopard G5/Latest/ -links 1 -exec ls -l {} ;
(sur une seul ligne, et adapter le chemin)
devrait te donner la liste des fichiers copiés lors du dernier backup.
Patrick -- Patrick Stadelmann
In article <1ig5oi7.197yhsl1pumcf6N%pas.de.spam@chez.moi>,
pas.de.spam@chez.moi (Pierre-Olivier TAUBATY) wrote:
J'aimerais savoir s'il y un moyen simple de voir ce que copie réellement
Time Machine dans une sauvegarde donnée. Car de temps en temps, il lui
prend la fantaisie de se mettre à faire une sauvegarde de plusieurs Go
(jusqu'à 35 !)
alors que je n'ai pas tant modifié de données. Je soupçonne un
fonctionnement erratique quant à certains dossiers : il doit les
recopier intégralement au lieu de ne prendre que ce qui a été modifié à
l'intérieur.
Vu que si le fichier de doit pas être copié, TM crée un hard link vers
le fichier existant déjà dans le backup, on peut en déduire que les
fichiers créés lors du dernier backup doivent avoir leur "compteur de
link" à 1 (i.e. il n'y a qu'une entrée dans le catalogue qui référence
ce fichier). Donc la commande :
find /Volumes/Backup/Backups.backupdb/Leopard G5/Latest/ -links 1
-exec ls -l {} ;
(sur une seul ligne, et adapter le chemin)
devrait te donner la liste des fichiers copiés lors du dernier backup.
Patrick
--
Patrick Stadelmann <Patrick.Stadelmann@unine.ch>
In article <1ig5oi7.197yhsl1pumcf6N%, (Pierre-Olivier TAUBATY) wrote:
J'aimerais savoir s'il y un moyen simple de voir ce que copie réellement Time Machine dans une sauvegarde donnée. Car de temps en temps, il lui prend la fantaisie de se mettre à faire une sauvegarde de plusieurs Go (jusqu'à 35 !) alors que je n'ai pas tant modifié de données. Je soupçonne un fonctionnement erratique quant à certains dossiers : il doit les recopier intégralement au lieu de ne prendre que ce qui a été modifié à l'intérieur.
Vu que si le fichier de doit pas être copié, TM crée un hard link vers le fichier existant déjà dans le backup, on peut en déduire que les fichiers créés lors du dernier backup doivent avoir leur "compteur de link" à 1 (i.e. il n'y a qu'une entrée dans le catalogue qui référence ce fichier). Donc la commande :
find /Volumes/Backup/Backups.backupdb/Leopard G5/Latest/ -links 1 -exec ls -l {} ;
(sur une seul ligne, et adapter le chemin)
devrait te donner la liste des fichiers copiés lors du dernier backup.
Patrick -- Patrick Stadelmann
Patrick Stadelmann
In article <1ig5oi7.197yhsl1pumcf6N%, (Pierre-Olivier TAUBATY) wrote:
J'aimerais savoir s'il y un moyen simple de voir ce que copie réellement Time Machine dans une sauvegarde donnée. Car de temps en temps, il lui prend la fantaisie de se mettre à faire une sauvegarde de plusieurs Go (jusqu'à 35 !) alors que je n'ai pas tant modifié de données. Je soupçonne un fonctionnement erratique quant à certains dossiers : il doit les recopier intégralement au lieu de ne prendre que ce qui a été modifié à l'intérieur.
Vu que si le fichier de doit pas être copié, TM crée un hard link vers le fichier existant déjà dans le backup, on peut en déduire que les fichiers créés lors du dernier backup doivent avoir leur "compteur de link" à 1 (i.e. il n'y a qu'une entrée dans le catalogue qui référence ce fichier). Donc la commande :
devrait te donner la liste des fichiers copiés lors du dernier backup.
Patrick -- Patrick Stadelmann
In article <1ig5oi7.197yhsl1pumcf6N%pas.de.spam@chez.moi>,
pas.de.spam@chez.moi (Pierre-Olivier TAUBATY) wrote:
J'aimerais savoir s'il y un moyen simple de voir ce que copie réellement
Time Machine dans une sauvegarde donnée. Car de temps en temps, il lui
prend la fantaisie de se mettre à faire une sauvegarde de plusieurs Go
(jusqu'à 35 !)
alors que je n'ai pas tant modifié de données. Je soupçonne un
fonctionnement erratique quant à certains dossiers : il doit les
recopier intégralement au lieu de ne prendre que ce qui a été modifié à
l'intérieur.
Vu que si le fichier de doit pas être copié, TM crée un hard link vers
le fichier existant déjà dans le backup, on peut en déduire que les
fichiers créés lors du dernier backup doivent avoir leur "compteur de
link" à 1 (i.e. il n'y a qu'une entrée dans le catalogue qui référence
ce fichier). Donc la commande :
In article <1ig5oi7.197yhsl1pumcf6N%, (Pierre-Olivier TAUBATY) wrote:
J'aimerais savoir s'il y un moyen simple de voir ce que copie réellement Time Machine dans une sauvegarde donnée. Car de temps en temps, il lui prend la fantaisie de se mettre à faire une sauvegarde de plusieurs Go (jusqu'à 35 !) alors que je n'ai pas tant modifié de données. Je soupçonne un fonctionnement erratique quant à certains dossiers : il doit les recopier intégralement au lieu de ne prendre que ce qui a été modifié à l'intérieur.
Vu que si le fichier de doit pas être copié, TM crée un hard link vers le fichier existant déjà dans le backup, on peut en déduire que les fichiers créés lors du dernier backup doivent avoir leur "compteur de link" à 1 (i.e. il n'y a qu'une entrée dans le catalogue qui référence ce fichier). Donc la commande :
devrait te donner la liste des fichiers copiés lors du dernier backup.
Patrick -- Patrick Stadelmann
Eric Levenez
Le 29/04/08 10:47, dans , « Patrick Stadelmann » a écrit :
Vu que si le fichier de doit pas être copié, TM crée un hard link vers le fichier existant déjà dans le backup, on peut en déduire que les fichiers créés lors du dernier backup doivent avoir leur "compteur de link" à 1 (i.e. il n'y a qu'une entrée dans le catalogue qui référence ce fichier). Donc la commande :
find /Volumes/Backup/Backups.backupdb/Leopard G5/Latest/ -links 1 -exec ls -l {} ;
L'option "ls" est bien plus rapide qu'exécuter la commande ls à chaque fichier.
Mais cela ne marche pas :-)
Tout simplement parce qu'un fichier qui n'a jamais été modifié depuis la première sauvegarde aura un nombre de lien à 1 dans toutes les sauvegardes car c'est son répertoire, et pas le fichier lui-même, qui sera lié entre chaque sauvegarde.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Le 29/04/08 10:47, dans
<Patrick.Stadelmann-A67C69.10472829042008@individual.net>, « Patrick
Stadelmann » <Patrick.Stadelmann@unine.ch> a écrit :
Vu que si le fichier de doit pas être copié, TM crée un hard link vers
le fichier existant déjà dans le backup, on peut en déduire que les
fichiers créés lors du dernier backup doivent avoir leur "compteur de
link" à 1 (i.e. il n'y a qu'une entrée dans le catalogue qui référence
ce fichier). Donc la commande :
find /Volumes/Backup/Backups.backupdb/Leopard G5/Latest/ -links 1
-exec ls -l {} ;
L'option "ls" est bien plus rapide qu'exécuter la commande ls à chaque
fichier.
Mais cela ne marche pas :-)
Tout simplement parce qu'un fichier qui n'a jamais été modifié depuis la
première sauvegarde aura un nombre de lien à 1 dans toutes les sauvegardes
car c'est son répertoire, et pas le fichier lui-même, qui sera lié entre
chaque sauvegarde.
--
Éric Lévénez -- <http://www.levenez.com/>
Unix is not only an OS, it's a way of life.
Le 29/04/08 10:47, dans , « Patrick Stadelmann » a écrit :
Vu que si le fichier de doit pas être copié, TM crée un hard link vers le fichier existant déjà dans le backup, on peut en déduire que les fichiers créés lors du dernier backup doivent avoir leur "compteur de link" à 1 (i.e. il n'y a qu'une entrée dans le catalogue qui référence ce fichier). Donc la commande :
find /Volumes/Backup/Backups.backupdb/Leopard G5/Latest/ -links 1 -exec ls -l {} ;
L'option "ls" est bien plus rapide qu'exécuter la commande ls à chaque fichier.
Mais cela ne marche pas :-)
Tout simplement parce qu'un fichier qui n'a jamais été modifié depuis la première sauvegarde aura un nombre de lien à 1 dans toutes les sauvegardes car c'est son répertoire, et pas le fichier lui-même, qui sera lié entre chaque sauvegarde.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Patrick Stadelmann
In article <C43CB027.CC1BA%, Eric Levenez wrote:
Mais cela ne marche pas :-)
Tout simplement parce qu'un fichier qui n'a jamais été modifié depuis la première sauvegarde aura un nombre de lien à 1 dans toutes les sauvegardes car c'est son répertoire, et pas le fichier lui-même, qui sera lié entre chaque sauvegarde.
Effectivement. Ca marche chez moi car j'ai lancé la commande en 10.3.9 et elle voit les dossiers "hard linkés" comme des fichier. Le répertoire et tous ces fichiers sont donc ignorés !
Pour que ça marche en 10.5, il faudrait donc modifier la commande pour qu'elle ne traverse pas les répertoires dont le compteur de link est supérieur à 1...
Patrick -- Patrick Stadelmann
In article <C43CB027.CC1BA%usenet@levenez.com>,
Eric Levenez <usenet@levenez.com> wrote:
Mais cela ne marche pas :-)
Tout simplement parce qu'un fichier qui n'a jamais été modifié depuis la
première sauvegarde aura un nombre de lien à 1 dans toutes les sauvegardes
car c'est son répertoire, et pas le fichier lui-même, qui sera lié entre
chaque sauvegarde.
Effectivement. Ca marche chez moi car j'ai lancé la commande en 10.3.9
et elle voit les dossiers "hard linkés" comme des fichier. Le répertoire
et tous ces fichiers sont donc ignorés !
Pour que ça marche en 10.5, il faudrait donc modifier la commande pour
qu'elle ne traverse pas les répertoires dont le compteur de link est
supérieur à 1...
Patrick
--
Patrick Stadelmann <Patrick.Stadelmann@unine.ch>
Tout simplement parce qu'un fichier qui n'a jamais été modifié depuis la première sauvegarde aura un nombre de lien à 1 dans toutes les sauvegardes car c'est son répertoire, et pas le fichier lui-même, qui sera lié entre chaque sauvegarde.
Effectivement. Ca marche chez moi car j'ai lancé la commande en 10.3.9 et elle voit les dossiers "hard linkés" comme des fichier. Le répertoire et tous ces fichiers sont donc ignorés !
Pour que ça marche en 10.5, il faudrait donc modifier la commande pour qu'elle ne traverse pas les répertoires dont le compteur de link est supérieur à 1...
Patrick -- Patrick Stadelmann
Eric Levenez
Le 29/04/08 11:13, dans , « Patrick Stadelmann » a écrit :
In article <C43CB027.CC1BA%, Eric Levenez wrote:
Mais cela ne marche pas :-)
Tout simplement parce qu'un fichier qui n'a jamais été modifié depuis la première sauvegarde aura un nombre de lien à 1 dans toutes les sauvegardes car c'est son répertoire, et pas le fichier lui-même, qui sera lié entre chaque sauvegarde.
Effectivement. Ca marche chez moi car j'ai lancé la commande en 10.3.9 et elle voit les dossiers "hard linkés" comme des fichier. Le répertoire et tous ces fichiers sont donc ignorés !
Pour que ça marche en 10.5, il faudrait donc modifier la commande pour qu'elle ne traverse pas les répertoires dont le compteur de link est supérieur à 1...
Cela ne peut pas marcher. Un répertoire a au minimum 2 liens ("." et le répertoire parent) et plus si il a des sous répertoires.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Le 29/04/08 11:13, dans
<Patrick.Stadelmann-DC8187.11133229042008@individual.net>, « Patrick
Stadelmann » <Patrick.Stadelmann@unine.ch> a écrit :
In article <C43CB027.CC1BA%usenet@levenez.com>,
Eric Levenez <usenet@levenez.com> wrote:
Mais cela ne marche pas :-)
Tout simplement parce qu'un fichier qui n'a jamais été modifié depuis la
première sauvegarde aura un nombre de lien à 1 dans toutes les sauvegardes
car c'est son répertoire, et pas le fichier lui-même, qui sera lié entre
chaque sauvegarde.
Effectivement. Ca marche chez moi car j'ai lancé la commande en 10.3.9
et elle voit les dossiers "hard linkés" comme des fichier. Le répertoire
et tous ces fichiers sont donc ignorés !
Pour que ça marche en 10.5, il faudrait donc modifier la commande pour
qu'elle ne traverse pas les répertoires dont le compteur de link est
supérieur à 1...
Cela ne peut pas marcher. Un répertoire a au minimum 2 liens ("." et le
répertoire parent) et plus si il a des sous répertoires.
--
Éric Lévénez -- <http://www.levenez.com/>
Unix is not only an OS, it's a way of life.
Le 29/04/08 11:13, dans , « Patrick Stadelmann » a écrit :
In article <C43CB027.CC1BA%, Eric Levenez wrote:
Mais cela ne marche pas :-)
Tout simplement parce qu'un fichier qui n'a jamais été modifié depuis la première sauvegarde aura un nombre de lien à 1 dans toutes les sauvegardes car c'est son répertoire, et pas le fichier lui-même, qui sera lié entre chaque sauvegarde.
Effectivement. Ca marche chez moi car j'ai lancé la commande en 10.3.9 et elle voit les dossiers "hard linkés" comme des fichier. Le répertoire et tous ces fichiers sont donc ignorés !
Pour que ça marche en 10.5, il faudrait donc modifier la commande pour qu'elle ne traverse pas les répertoires dont le compteur de link est supérieur à 1...
Cela ne peut pas marcher. Un répertoire a au minimum 2 liens ("." et le répertoire parent) et plus si il a des sous répertoires.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
laurent.pertois
Pierre-Olivier TAUBATY wrote:
Parce que là, il m'a facile bouffé 100 Go par rapport à la première sauvegarde ... si ça continue à ce rythme, c'est pas un Mac Pro qu'il va me falloir, mais une baie de Xsan ... manque de pot, ça se fait plus :D :D
Attention, les baies Xserve RAID n'existent plus, Xsan existe toujours, c'est un produit différent, un logiciel d'ailleurs.
Mais bon, tu pourras toujours acheter une baie Promise VTRAK qui remplace les Xserve RAID, ça contient un peu plus et c'est surtout plus rapide :-)
-- Politically Correct Unix - UTILITIES The "touch" command has been removed from the standard distribution due to its inappropriate use by high-level managers.
Parce que là, il m'a facile bouffé 100 Go par rapport à la première
sauvegarde ... si ça continue à ce rythme, c'est pas un Mac Pro qu'il va
me falloir, mais une baie de Xsan ... manque de pot, ça se fait plus :D
:D
Attention, les baies Xserve RAID n'existent plus, Xsan existe toujours,
c'est un produit différent, un logiciel d'ailleurs.
Mais bon, tu pourras toujours acheter une baie Promise VTRAK qui
remplace les Xserve RAID, ça contient un peu plus et c'est surtout plus
rapide :-)
--
Politically Correct Unix - UTILITIES
The "touch" command has been removed from the standard distribution due
to its inappropriate use by high-level managers.
Parce que là, il m'a facile bouffé 100 Go par rapport à la première sauvegarde ... si ça continue à ce rythme, c'est pas un Mac Pro qu'il va me falloir, mais une baie de Xsan ... manque de pot, ça se fait plus :D :D
Attention, les baies Xserve RAID n'existent plus, Xsan existe toujours, c'est un produit différent, un logiciel d'ailleurs.
Mais bon, tu pourras toujours acheter une baie Promise VTRAK qui remplace les Xserve RAID, ça contient un peu plus et c'est surtout plus rapide :-)
-- Politically Correct Unix - UTILITIES The "touch" command has been removed from the standard distribution due to its inappropriate use by high-level managers.
Patrick Stadelmann
In article <C43CBD77.CC1C8%, Eric Levenez wrote:
Cela ne peut pas marcher. Un répertoire a au minimum 2 liens ("." et le répertoire parent) et plus si il a des sous répertoires.
Ou des fichiers, non ? Le chiffre semble correspondre au nombre d'éléments (y incluse "." et "..") que contient le dossier. Ce chiffre n'a donc pas le même sens pour un dossier que pour un fichier.
Mais, comme pour les fichiers, il faut bien quelque part un compteur qui garde la trace du nombre de liens pointant vers le répertoire, afin de pouvoir supprimer l'objet HFS correspondant quand le dernier lien est détruit...
Patrick -- Patrick Stadelmann
In article <C43CBD77.CC1C8%usenet@levenez.com>,
Eric Levenez <usenet@levenez.com> wrote:
Cela ne peut pas marcher. Un répertoire a au minimum 2 liens ("." et le
répertoire parent) et plus si il a des sous répertoires.
Ou des fichiers, non ? Le chiffre semble correspondre au nombre
d'éléments (y incluse "." et "..") que contient le dossier. Ce chiffre
n'a donc pas le même sens pour un dossier que pour un fichier.
Mais, comme pour les fichiers, il faut bien quelque part un compteur qui
garde la trace du nombre de liens pointant vers le répertoire, afin de
pouvoir supprimer l'objet HFS correspondant quand le dernier lien est
détruit...
Patrick
--
Patrick Stadelmann <Patrick.Stadelmann@unine.ch>
Cela ne peut pas marcher. Un répertoire a au minimum 2 liens ("." et le répertoire parent) et plus si il a des sous répertoires.
Ou des fichiers, non ? Le chiffre semble correspondre au nombre d'éléments (y incluse "." et "..") que contient le dossier. Ce chiffre n'a donc pas le même sens pour un dossier que pour un fichier.
Mais, comme pour les fichiers, il faut bien quelque part un compteur qui garde la trace du nombre de liens pointant vers le répertoire, afin de pouvoir supprimer l'objet HFS correspondant quand le dernier lien est détruit...
Patrick -- Patrick Stadelmann
Eric Levenez
Le 29/04/08 13:29, dans , « Patrick Stadelmann » a écrit :
In article <C43CBD77.CC1C8%, Eric Levenez wrote:
Cela ne peut pas marcher. Un répertoire a au minimum 2 liens ("." et le répertoire parent) et plus si il a des sous répertoires.
Ou des fichiers, non ? Le chiffre semble correspondre au nombre d'éléments (y incluse "." et "..") que contient le dossier. Ce chiffre n'a donc pas le même sens pour un dossier que pour un fichier.
Mince ! Encore un coup du HFS+ ! Vivement qu'il disparaisse.
Mais, comme pour les fichiers, il faut bien quelque part un compteur qui garde la trace du nombre de liens pointant vers le répertoire, afin de pouvoir supprimer l'objet HFS correspondant quand le dernier lien est détruit...
Avec HFS+, j'abandonne à trouvé une logique dans les choix d'implémentation d'Apple.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Le 29/04/08 13:29, dans
<Patrick.Stadelmann-1747A6.13290929042008@individual.net>, « Patrick
Stadelmann » <Patrick.Stadelmann@unine.ch> a écrit :
In article <C43CBD77.CC1C8%usenet@levenez.com>,
Eric Levenez <usenet@levenez.com> wrote:
Cela ne peut pas marcher. Un répertoire a au minimum 2 liens ("." et le
répertoire parent) et plus si il a des sous répertoires.
Ou des fichiers, non ? Le chiffre semble correspondre au nombre
d'éléments (y incluse "." et "..") que contient le dossier. Ce chiffre
n'a donc pas le même sens pour un dossier que pour un fichier.
Mince ! Encore un coup du HFS+ ! Vivement qu'il disparaisse.
Mais, comme pour les fichiers, il faut bien quelque part un compteur qui
garde la trace du nombre de liens pointant vers le répertoire, afin de
pouvoir supprimer l'objet HFS correspondant quand le dernier lien est
détruit...
Avec HFS+, j'abandonne à trouvé une logique dans les choix d'implémentation
d'Apple.
--
Éric Lévénez -- <http://www.levenez.com/>
Unix is not only an OS, it's a way of life.
Le 29/04/08 13:29, dans , « Patrick Stadelmann » a écrit :
In article <C43CBD77.CC1C8%, Eric Levenez wrote:
Cela ne peut pas marcher. Un répertoire a au minimum 2 liens ("." et le répertoire parent) et plus si il a des sous répertoires.
Ou des fichiers, non ? Le chiffre semble correspondre au nombre d'éléments (y incluse "." et "..") que contient le dossier. Ce chiffre n'a donc pas le même sens pour un dossier que pour un fichier.
Mince ! Encore un coup du HFS+ ! Vivement qu'il disparaisse.
Mais, comme pour les fichiers, il faut bien quelque part un compteur qui garde la trace du nombre de liens pointant vers le répertoire, afin de pouvoir supprimer l'objet HFS correspondant quand le dernier lien est détruit...
Avec HFS+, j'abandonne à trouvé une logique dans les choix d'implémentation d'Apple.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
