"La mise à jour 10.5.2 est recommandée à tous les utilisateurs de Mac OS X
Leopard et comprend des corrections générales du système d¹exploitation qui
améliorent la stabilité, la compatibilité et la sécurité de votre Mac.
Pour obtenir plus de renseignements sur cette mise à jour, veuillez
consulter le site web suivant :
<http://docs.info.apple.com/article.html?artnum=307109>.
Pour obtenir plus de renseignements sur les mises à jour de sécurité,
veuillez consulter le site web suivant :
<http://docs.info.apple.com/article.html?artnum=61798>."
--
Éric Lévénez -- <http://www.levenez.com/>
Unix is not only an OS, it's a way of life.
Cette question n'a pas de sens car tu y appliques ce que tu connais des alias de Mac OS à une notion Unix. Et ça colle pas :-)
Un fichier sur un disque dur a un nom. Bon. Si on crée un lien dur de ce fichier on lui donne un deuxième nom. Il n'y a pas de nom principal ou secondaire. Il n'y a pas fichier original ou copié. C'est un fichier avec 2 noms. Chaque nom est aussi important que l'autre. Quand on efface un de ces 2 noms, il en reste un. Le fichier est donc toujours accessible. Si on supprime le deuxième nom, le fichier n'a plus de nom, alors le système de fichier, efface le fichier du disque.
Si j'ai bien compris (ce qui veut dire que tu as bien expliqué) ;)
J'ai un fichier A (réf. AQWZSX) qui pointe vers les blocs 12, 13, 25 et ce fichier A est quelque part dans mon arborescence de fichiers genre : ~/Documents/Usenet/A .
Si je fais un alias B, j'ai en fait un _fichier_ qui pointe sur le fichier A ou plutôt vers sa référence AQWZSX. Si je supprime A, sa référence disparaît dans la table (par contre, si je le déplace, la réf. existe toujours et le lien est préservé).
Si je fais un hard link, en fait, je duplique la référence AQWZSX, je peux lui donner un autre nom (ZZ) et le placer où je veux. Ce sont en fait deux entrées dans la table avec deux références différentes (AQWZSX et EDCRFV par ex.) mais qui pointent toutes les deux vers les blocs 12, 13, 25. Si je supprime A, ZZ pointe toujours vers les blocs.
C'est bien beau tout ça, mais, comment le FS sait que les blocs ne sont plus pointé par qui que ce soit ? Dans le cas des alias c'est simple : il n'y a qu'une seule entrée qui pointe vers eux et je peux avoir une autant d'alias que je veux, seule la suppression du seul fichier rend les blocs disponibles. Par contre avec les hards links je peux avoir autant d'entrées que je veux dans le FS qui pointent sur les même blocs.
À chaque fois que je supprime une entrée (un fichier en quelque sorte) je dois vérifier si les blocs qu'il utilisait sont maintenant disponibles ou non, je dois donc regarder si personne d'autre ne pointe vers ces blocs et ça, c'est le Bronx assurer en terme de calcul. Non ? En plus, puisque j'ai plusieurs fichiers qui pointent sur les mêmes blocs comment je garantis les pb de lecture/écriture sur ces blocs.
Bref, comment je peux interdire ou autoriser différentes applis à écrire dans différents fichiers qui pointent sur les mêmes blocs ?
-- Benoit Leraillez
La douleur des autres est tout à fait supportable, hors les cris.
Eric Levenez <usenet@levenez.com> wrote:
Cette question n'a pas de sens car tu y appliques ce que tu connais des
alias de Mac OS à une notion Unix. Et ça colle pas :-)
Un fichier sur un disque dur a un nom. Bon. Si on crée un lien dur de ce
fichier on lui donne un deuxième nom. Il n'y a pas de nom principal ou
secondaire. Il n'y a pas fichier original ou copié. C'est un fichier avec 2
noms. Chaque nom est aussi important que l'autre. Quand on efface un de ces
2 noms, il en reste un. Le fichier est donc toujours accessible. Si on
supprime le deuxième nom, le fichier n'a plus de nom, alors le système de
fichier, efface le fichier du disque.
Si j'ai bien compris (ce qui veut dire que tu as bien expliqué) ;)
J'ai un fichier A (réf. AQWZSX) qui pointe vers les blocs 12, 13, 25
et ce fichier A est quelque part dans mon arborescence de fichiers
genre : ~/Documents/Usenet/A .
Si je fais un alias B, j'ai en fait un _fichier_ qui pointe sur le
fichier A ou plutôt vers sa référence AQWZSX. Si je supprime A, sa
référence disparaît dans la table (par contre, si je le déplace, la réf.
existe toujours et le lien est préservé).
Si je fais un hard link, en fait, je duplique la référence AQWZSX,
je peux lui donner un autre nom (ZZ) et le placer où je veux. Ce sont en
fait deux entrées dans la table avec deux références différentes (AQWZSX
et EDCRFV par ex.) mais qui pointent toutes les deux vers les blocs 12,
13, 25. Si je supprime A, ZZ pointe toujours vers les blocs.
C'est bien beau tout ça, mais, comment le FS sait que les blocs ne
sont plus pointé par qui que ce soit ? Dans le cas des alias c'est
simple : il n'y a qu'une seule entrée qui pointe vers eux et je peux
avoir une autant d'alias que je veux, seule la suppression du seul
fichier rend les blocs disponibles. Par contre avec les hards links je
peux avoir autant d'entrées que je veux dans le FS qui pointent sur les
même blocs.
À chaque fois que je supprime une entrée (un fichier en quelque
sorte) je dois vérifier si les blocs qu'il utilisait sont maintenant
disponibles ou non, je dois donc regarder si personne d'autre ne pointe
vers ces blocs et ça, c'est le Bronx assurer en terme de calcul. Non ?
En plus, puisque j'ai plusieurs fichiers qui pointent sur les mêmes
blocs comment je garantis les pb de lecture/écriture sur ces blocs.
Bref, comment je peux interdire ou autoriser différentes applis à
écrire dans différents fichiers qui pointent sur les mêmes blocs ?
--
Benoit Leraillez
La douleur des autres est tout à fait supportable, hors les cris.
Cette question n'a pas de sens car tu y appliques ce que tu connais des alias de Mac OS à une notion Unix. Et ça colle pas :-)
Un fichier sur un disque dur a un nom. Bon. Si on crée un lien dur de ce fichier on lui donne un deuxième nom. Il n'y a pas de nom principal ou secondaire. Il n'y a pas fichier original ou copié. C'est un fichier avec 2 noms. Chaque nom est aussi important que l'autre. Quand on efface un de ces 2 noms, il en reste un. Le fichier est donc toujours accessible. Si on supprime le deuxième nom, le fichier n'a plus de nom, alors le système de fichier, efface le fichier du disque.
Si j'ai bien compris (ce qui veut dire que tu as bien expliqué) ;)
J'ai un fichier A (réf. AQWZSX) qui pointe vers les blocs 12, 13, 25 et ce fichier A est quelque part dans mon arborescence de fichiers genre : ~/Documents/Usenet/A .
Si je fais un alias B, j'ai en fait un _fichier_ qui pointe sur le fichier A ou plutôt vers sa référence AQWZSX. Si je supprime A, sa référence disparaît dans la table (par contre, si je le déplace, la réf. existe toujours et le lien est préservé).
Si je fais un hard link, en fait, je duplique la référence AQWZSX, je peux lui donner un autre nom (ZZ) et le placer où je veux. Ce sont en fait deux entrées dans la table avec deux références différentes (AQWZSX et EDCRFV par ex.) mais qui pointent toutes les deux vers les blocs 12, 13, 25. Si je supprime A, ZZ pointe toujours vers les blocs.
C'est bien beau tout ça, mais, comment le FS sait que les blocs ne sont plus pointé par qui que ce soit ? Dans le cas des alias c'est simple : il n'y a qu'une seule entrée qui pointe vers eux et je peux avoir une autant d'alias que je veux, seule la suppression du seul fichier rend les blocs disponibles. Par contre avec les hards links je peux avoir autant d'entrées que je veux dans le FS qui pointent sur les même blocs.
À chaque fois que je supprime une entrée (un fichier en quelque sorte) je dois vérifier si les blocs qu'il utilisait sont maintenant disponibles ou non, je dois donc regarder si personne d'autre ne pointe vers ces blocs et ça, c'est le Bronx assurer en terme de calcul. Non ? En plus, puisque j'ai plusieurs fichiers qui pointent sur les mêmes blocs comment je garantis les pb de lecture/écriture sur ces blocs.
Bref, comment je peux interdire ou autoriser différentes applis à écrire dans différents fichiers qui pointent sur les mêmes blocs ?
-- Benoit Leraillez
La douleur des autres est tout à fait supportable, hors les cris.
Anonyme
Benoit wrote:
...
Tu as bien compris.
C'est bien beau tout ça, mais, comment le FS sait que les blocs ne sont plus pointé par qui que ce soit ? Dans le cas des alias c'est simple : il n'y a qu'une seule entrée qui pointe vers eux et je peux avoir une autant d'alias que je veux, seule la suppression du seul fichier rend les blocs disponibles. Par contre avec les hards links je peux avoir autant d'entrées que je veux dans le FS qui pointent sur les même blocs.
C'est super simple. Il y a une table qui dit que tel "nom" pointe vers tels blocs. Dans cette même table, si il y a un autre "nom qui pointe vers le même bloc, ben ça se voit facilement. C'est de la BDD...
À chaque fois que je supprime une entrée (un fichier en quelque sorte) je dois vérifier si les blocs qu'il utilisait sont maintenant disponibles ou non, je dois donc regarder si personne d'autre ne pointe vers ces blocs et ça, c'est le Bronx assurer en terme de calcul. Non ?
Ben non. Y'a un compteur qui se décrémente quand tu efface un fichier, le fichier est alors effacé du disque quand le compteur arrive à 0. Regardes quand tu fais un ls -l :
$ touch toto titi $ ln titi tata $ ls -l total 0 -rw-r--r-- 2 jayce wheel 0 19 fév 00:18 tata -rw-r--r-- 2 jayce wheel 0 19 fév 00:18 titi -rw-r--r-- 1 jayce wheel 0 19 fév 00:18 toto $ rm titi $ ls -l total 0 -rw-r--r-- 1 jayce wheel 0 19 fév 00:18 tata -rw-r--r-- 1 jayce wheel 0 19 fév 00:18 toto
Je crée deux fichiers toto et titi. Je crée tata, lien dur de titi. On voit que tata et titi on un compteur à 2 alors que toto a un compteur à 1. Si j'efface titi, tata a son compteur qui passe à 1.
En plus, puisque j'ai plusieurs fichiers qui pointent sur les mêmes blocs comment je garantis les pb de lecture/écriture sur ces blocs.
Bref, comment je peux interdire ou autoriser différentes applis à écrire dans différents fichiers qui pointent sur les mêmes blocs ?
Ben c'est géré au niveau du système de fichier... Enfin, dans un système de fichier qui gère les liens durs...
-- Anonyme ( jayce <@> mosx.org ) ********* MosX.org <http://www.mosx.org/> ********* (MosX.net renaît sous le nom MosX.org...)
C'est bien beau tout ça, mais, comment le FS sait que les blocs ne
sont plus pointé par qui que ce soit ? Dans le cas des alias c'est
simple : il n'y a qu'une seule entrée qui pointe vers eux et je peux
avoir une autant d'alias que je veux, seule la suppression du seul
fichier rend les blocs disponibles. Par contre avec les hards links je
peux avoir autant d'entrées que je veux dans le FS qui pointent sur les
même blocs.
C'est super simple. Il y a une table qui dit que tel "nom" pointe vers
tels blocs. Dans cette même table, si il y a un autre "nom qui pointe
vers le même bloc, ben ça se voit facilement. C'est de la BDD...
À chaque fois que je supprime une entrée (un fichier en quelque
sorte) je dois vérifier si les blocs qu'il utilisait sont maintenant
disponibles ou non, je dois donc regarder si personne d'autre ne pointe
vers ces blocs et ça, c'est le Bronx assurer en terme de calcul. Non ?
Ben non. Y'a un compteur qui se décrémente quand tu efface un fichier,
le fichier est alors effacé du disque quand le compteur arrive à 0.
Regardes quand tu fais un ls -l :
$ touch toto titi
$ ln titi tata
$ ls -l
total 0
-rw-r--r-- 2 jayce wheel 0 19 fév 00:18 tata
-rw-r--r-- 2 jayce wheel 0 19 fév 00:18 titi
-rw-r--r-- 1 jayce wheel 0 19 fév 00:18 toto
$ rm titi
$ ls -l
total 0
-rw-r--r-- 1 jayce wheel 0 19 fév 00:18 tata
-rw-r--r-- 1 jayce wheel 0 19 fév 00:18 toto
Je crée deux fichiers toto et titi. Je crée tata, lien dur de titi.
On voit que tata et titi on un compteur à 2 alors que toto a un compteur
à 1. Si j'efface titi, tata a son compteur qui passe à 1.
En plus, puisque j'ai plusieurs fichiers qui pointent sur les mêmes
blocs comment je garantis les pb de lecture/écriture sur ces blocs.
Bref, comment je peux interdire ou autoriser différentes applis à
écrire dans différents fichiers qui pointent sur les mêmes blocs ?
Ben c'est géré au niveau du système de fichier... Enfin, dans un système
de fichier qui gère les liens durs...
--
Anonyme ( jayce <@> mosx.org )
********* MosX.org <http://www.mosx.org/> *********
(MosX.net renaît sous le nom MosX.org...)
C'est bien beau tout ça, mais, comment le FS sait que les blocs ne sont plus pointé par qui que ce soit ? Dans le cas des alias c'est simple : il n'y a qu'une seule entrée qui pointe vers eux et je peux avoir une autant d'alias que je veux, seule la suppression du seul fichier rend les blocs disponibles. Par contre avec les hards links je peux avoir autant d'entrées que je veux dans le FS qui pointent sur les même blocs.
C'est super simple. Il y a une table qui dit que tel "nom" pointe vers tels blocs. Dans cette même table, si il y a un autre "nom qui pointe vers le même bloc, ben ça se voit facilement. C'est de la BDD...
À chaque fois que je supprime une entrée (un fichier en quelque sorte) je dois vérifier si les blocs qu'il utilisait sont maintenant disponibles ou non, je dois donc regarder si personne d'autre ne pointe vers ces blocs et ça, c'est le Bronx assurer en terme de calcul. Non ?
Ben non. Y'a un compteur qui se décrémente quand tu efface un fichier, le fichier est alors effacé du disque quand le compteur arrive à 0. Regardes quand tu fais un ls -l :
$ touch toto titi $ ln titi tata $ ls -l total 0 -rw-r--r-- 2 jayce wheel 0 19 fév 00:18 tata -rw-r--r-- 2 jayce wheel 0 19 fév 00:18 titi -rw-r--r-- 1 jayce wheel 0 19 fév 00:18 toto $ rm titi $ ls -l total 0 -rw-r--r-- 1 jayce wheel 0 19 fév 00:18 tata -rw-r--r-- 1 jayce wheel 0 19 fév 00:18 toto
Je crée deux fichiers toto et titi. Je crée tata, lien dur de titi. On voit que tata et titi on un compteur à 2 alors que toto a un compteur à 1. Si j'efface titi, tata a son compteur qui passe à 1.
En plus, puisque j'ai plusieurs fichiers qui pointent sur les mêmes blocs comment je garantis les pb de lecture/écriture sur ces blocs.
Bref, comment je peux interdire ou autoriser différentes applis à écrire dans différents fichiers qui pointent sur les mêmes blocs ?
Ben c'est géré au niveau du système de fichier... Enfin, dans un système de fichier qui gère les liens durs...
-- Anonyme ( jayce <@> mosx.org ) ********* MosX.org <http://www.mosx.org/> ********* (MosX.net renaît sous le nom MosX.org...)
Non, sincèrement, j'ai réfléchis un peu sur le sujet et j'ai imaginé coment ça fonctionnerait si j'avais dû le faire. Et je ne me suis pas trop planté.
C'est bien beau tout ça, mais, comment le FS sait que les blocs ne sont plus pointé par qui que ce soit ? Dans le cas des alias c'est simple : il n'y a qu'une seule entrée qui pointe vers eux et je peux avoir une autant d'alias que je veux, seule la suppression du seul fichier rend les blocs disponibles. Par contre avec les hards links je peux avoir autant d'entrées que je veux dans le FS qui pointent sur les même blocs.
C'est super simple. Il y a une table qui dit que tel "nom" pointe vers tels blocs. Dans cette même table, si il y a un autre "nom qui pointe vers le même bloc, ben ça se voit facilement. C'est de la BDD...
À chaque fois que je supprime une entrée (un fichier en quelque sorte) je dois vérifier si les blocs qu'il utilisait sont maintenant disponibles ou non, je dois donc regarder si personne d'autre ne pointe vers ces blocs et ça, c'est le Bronx assurer en terme de calcul. Non ?
Ben non. Y'a un compteur qui se décrémente quand tu efface un fichier, le fichier est alors effacé du disque quand le compteur arrive à 0.
Alors où est la BDD. Parce que dans le cas d'une BDD si je détruis le fichier A qui utilise le bloc 12, il me suffit de faire une requête sur 12 pour savoir si j'ai un autre pointeur sur lui. 1 est suffisant, qu'il y en ait 2, 10 ou 10^5 cela ne change rien, j'en ai trouvé 1 et donc le bloc est utilisé.
Par contre c'est bien beau mais comment je sais quels blocs sont dispos ? Je ne vasi pas me cogner une requête pour chaque bloc quand je veux écrire. J'ai une table des blocs vides ?
Regardes quand tu fais un ls -l : [SNIP] Je crée deux fichiers toto et titi. Je crée tata, lien dur de titi. On voit que tata et titi on un compteur à 2 alors que toto a un compteur à 1. Si j'efface titi, tata a son compteur qui passe à 1.
cf ci-dessus
En plus, puisque j'ai plusieurs fichiers qui pointent sur les mêmes blocs comment je garantis les pb de lecture/écriture sur ces blocs.
Bref, comment je peux interdire ou autoriser différentes applis à écrire dans différents fichiers qui pointent sur les mêmes blocs ?
Ben c'est géré au niveau du système de fichier... Enfin, dans un système de fichier qui gère les liens durs...
Je dois donc avoir une autre table qui me donne les blocs en lecture seule. Un bloc est donc utilisé ou non, libre en écriture ou non et c'est tout ?
-- Benoit Leraillez
La douleur des autres est tout à fait supportable, hors les cris.
Non, sincèrement, j'ai réfléchis un peu sur le sujet et j'ai imaginé
coment ça fonctionnerait si j'avais dû le faire. Et je ne me suis pas
trop planté.
C'est bien beau tout ça, mais, comment le FS sait que les blocs ne
sont plus pointé par qui que ce soit ? Dans le cas des alias c'est
simple : il n'y a qu'une seule entrée qui pointe vers eux et je peux
avoir une autant d'alias que je veux, seule la suppression du seul
fichier rend les blocs disponibles. Par contre avec les hards links je
peux avoir autant d'entrées que je veux dans le FS qui pointent sur les
même blocs.
C'est super simple. Il y a une table qui dit que tel "nom" pointe vers
tels blocs. Dans cette même table, si il y a un autre "nom qui pointe
vers le même bloc, ben ça se voit facilement. C'est de la BDD...
À chaque fois que je supprime une entrée (un fichier en quelque
sorte) je dois vérifier si les blocs qu'il utilisait sont maintenant
disponibles ou non, je dois donc regarder si personne d'autre ne pointe
vers ces blocs et ça, c'est le Bronx assurer en terme de calcul. Non ?
Ben non. Y'a un compteur qui se décrémente quand tu efface un fichier,
le fichier est alors effacé du disque quand le compteur arrive à 0.
Alors où est la BDD. Parce que dans le cas d'une BDD si je détruis
le fichier A qui utilise le bloc 12, il me suffit de faire une requête
sur 12 pour savoir si j'ai un autre pointeur sur lui. 1 est suffisant,
qu'il y en ait 2, 10 ou 10^5 cela ne change rien, j'en ai trouvé 1 et
donc le bloc est utilisé.
Par contre c'est bien beau mais comment je sais quels blocs sont
dispos ? Je ne vasi pas me cogner une requête pour chaque bloc quand je
veux écrire. J'ai une table des blocs vides ?
Regardes quand tu fais un ls -l :
[SNIP]
Je crée deux fichiers toto et titi. Je crée tata, lien dur de titi.
On voit que tata et titi on un compteur à 2 alors que toto a un compteur
à 1. Si j'efface titi, tata a son compteur qui passe à 1.
cf ci-dessus
En plus, puisque j'ai plusieurs fichiers qui pointent sur les mêmes
blocs comment je garantis les pb de lecture/écriture sur ces blocs.
Bref, comment je peux interdire ou autoriser différentes applis à
écrire dans différents fichiers qui pointent sur les mêmes blocs ?
Ben c'est géré au niveau du système de fichier... Enfin, dans un système
de fichier qui gère les liens durs...
Je dois donc avoir une autre table qui me donne les blocs en lecture
seule. Un bloc est donc utilisé ou non, libre en écriture ou non et
c'est tout ?
--
Benoit Leraillez
La douleur des autres est tout à fait supportable, hors les cris.
Non, sincèrement, j'ai réfléchis un peu sur le sujet et j'ai imaginé coment ça fonctionnerait si j'avais dû le faire. Et je ne me suis pas trop planté.
C'est bien beau tout ça, mais, comment le FS sait que les blocs ne sont plus pointé par qui que ce soit ? Dans le cas des alias c'est simple : il n'y a qu'une seule entrée qui pointe vers eux et je peux avoir une autant d'alias que je veux, seule la suppression du seul fichier rend les blocs disponibles. Par contre avec les hards links je peux avoir autant d'entrées que je veux dans le FS qui pointent sur les même blocs.
C'est super simple. Il y a une table qui dit que tel "nom" pointe vers tels blocs. Dans cette même table, si il y a un autre "nom qui pointe vers le même bloc, ben ça se voit facilement. C'est de la BDD...
À chaque fois que je supprime une entrée (un fichier en quelque sorte) je dois vérifier si les blocs qu'il utilisait sont maintenant disponibles ou non, je dois donc regarder si personne d'autre ne pointe vers ces blocs et ça, c'est le Bronx assurer en terme de calcul. Non ?
Ben non. Y'a un compteur qui se décrémente quand tu efface un fichier, le fichier est alors effacé du disque quand le compteur arrive à 0.
Alors où est la BDD. Parce que dans le cas d'une BDD si je détruis le fichier A qui utilise le bloc 12, il me suffit de faire une requête sur 12 pour savoir si j'ai un autre pointeur sur lui. 1 est suffisant, qu'il y en ait 2, 10 ou 10^5 cela ne change rien, j'en ai trouvé 1 et donc le bloc est utilisé.
Par contre c'est bien beau mais comment je sais quels blocs sont dispos ? Je ne vasi pas me cogner une requête pour chaque bloc quand je veux écrire. J'ai une table des blocs vides ?
Regardes quand tu fais un ls -l : [SNIP] Je crée deux fichiers toto et titi. Je crée tata, lien dur de titi. On voit que tata et titi on un compteur à 2 alors que toto a un compteur à 1. Si j'efface titi, tata a son compteur qui passe à 1.
cf ci-dessus
En plus, puisque j'ai plusieurs fichiers qui pointent sur les mêmes blocs comment je garantis les pb de lecture/écriture sur ces blocs.
Bref, comment je peux interdire ou autoriser différentes applis à écrire dans différents fichiers qui pointent sur les mêmes blocs ?
Ben c'est géré au niveau du système de fichier... Enfin, dans un système de fichier qui gère les liens durs...
Je dois donc avoir une autre table qui me donne les blocs en lecture seule. Un bloc est donc utilisé ou non, libre en écriture ou non et c'est tout ?
-- Benoit Leraillez
La douleur des autres est tout à fait supportable, hors les cris.
Anonyme
Benoit wrote:
Alors où est la BDD. Parce que dans le cas d'une BDD si je détruis le fichier A qui utilise le bloc 12, il me suffit de faire une requête sur 12 pour savoir si j'ai un autre pointeur sur lui. 1 est suffisant, qu'il y en ait 2, 10 ou 10^5 cela ne change rien, j'en ai trouvé 1 et donc le bloc est utilisé.
Le compteur n'est pas forcément une donnée "stockée". Cela dépend du sytème de fichier et de sa manire d'implémenter la chose.
Par contre c'est bien beau mais comment je sais quels blocs sont dispos ? Je ne vasi pas me cogner une requête pour chaque bloc quand je veux écrire. J'ai une table des blocs vides ?
Pareil, cela dépend du système de fichier, mais c'est sa tembouille à lui, "l'utilisateur" du système de fichier n'a pas à s'en préoccuper. (par "utilisateur", j'entends, l'OS, les applis, etc...)
-- Anonyme ( jayce <@> mosx.org ) ********* MosX.org <http://www.mosx.org/> ********* (MosX.net renaît sous le nom MosX.org...)
Alors où est la BDD. Parce que dans le cas d'une BDD si je détruis
le fichier A qui utilise le bloc 12, il me suffit de faire une requête
sur 12 pour savoir si j'ai un autre pointeur sur lui. 1 est suffisant,
qu'il y en ait 2, 10 ou 10^5 cela ne change rien, j'en ai trouvé 1 et
donc le bloc est utilisé.
Le compteur n'est pas forcément une donnée "stockée". Cela dépend du
sytème de fichier et de sa manire d'implémenter la chose.
Par contre c'est bien beau mais comment je sais quels blocs sont
dispos ? Je ne vasi pas me cogner une requête pour chaque bloc quand je
veux écrire. J'ai une table des blocs vides ?
Pareil, cela dépend du système de fichier, mais c'est sa tembouille à
lui, "l'utilisateur" du système de fichier n'a pas à s'en préoccuper.
(par "utilisateur", j'entends, l'OS, les applis, etc...)
--
Anonyme ( jayce <@> mosx.org )
********* MosX.org <http://www.mosx.org/> *********
(MosX.net renaît sous le nom MosX.org...)
Alors où est la BDD. Parce que dans le cas d'une BDD si je détruis le fichier A qui utilise le bloc 12, il me suffit de faire une requête sur 12 pour savoir si j'ai un autre pointeur sur lui. 1 est suffisant, qu'il y en ait 2, 10 ou 10^5 cela ne change rien, j'en ai trouvé 1 et donc le bloc est utilisé.
Le compteur n'est pas forcément une donnée "stockée". Cela dépend du sytème de fichier et de sa manire d'implémenter la chose.
Par contre c'est bien beau mais comment je sais quels blocs sont dispos ? Je ne vasi pas me cogner une requête pour chaque bloc quand je veux écrire. J'ai une table des blocs vides ?
Pareil, cela dépend du système de fichier, mais c'est sa tembouille à lui, "l'utilisateur" du système de fichier n'a pas à s'en préoccuper. (par "utilisateur", j'entends, l'OS, les applis, etc...)
-- Anonyme ( jayce <@> mosx.org ) ********* MosX.org <http://www.mosx.org/> ********* (MosX.net renaît sous le nom MosX.org...)
Anonyme
Benoit wrote:
Je dois donc avoir une autre table qui me donne les blocs en lecture seule. Un bloc est donc utilisé ou non, libre en écriture ou non et c'est tout ?
Chaque FS gère la chose comme il veut, et j'avour que je ne me suis jamais penché sur la question pour savoir comment tel ou tel système gérait la chose...
-- Anonyme ( jayce <@> mosx.org ) ********* MosX.org <http://www.mosx.org/> ********* (MosX.net renaît sous le nom MosX.org...)
Je dois donc avoir une autre table qui me donne les blocs en lecture
seule. Un bloc est donc utilisé ou non, libre en écriture ou non et
c'est tout ?
Chaque FS gère la chose comme il veut, et j'avour que je ne me suis
jamais penché sur la question pour savoir comment tel ou tel système
gérait la chose...
--
Anonyme ( jayce <@> mosx.org )
********* MosX.org <http://www.mosx.org/> *********
(MosX.net renaît sous le nom MosX.org...)
Je dois donc avoir une autre table qui me donne les blocs en lecture seule. Un bloc est donc utilisé ou non, libre en écriture ou non et c'est tout ?
Chaque FS gère la chose comme il veut, et j'avour que je ne me suis jamais penché sur la question pour savoir comment tel ou tel système gérait la chose...
-- Anonyme ( jayce <@> mosx.org ) ********* MosX.org <http://www.mosx.org/> ********* (MosX.net renaît sous le nom MosX.org...)
Patrick Stadelmann
In article <1ickn60.1hgr1iuc6mhxuN%, (Anonyme) wrote:
Benoit wrote:
Je dois donc avoir une autre table qui me donne les blocs en lecture seule. Un bloc est donc utilisé ou non, libre en écriture ou non et c'est tout ?
Chaque FS gère la chose comme il veut, et j'avour que je ne me suis jamais penché sur la question pour savoir comment tel ou tel système gérait la chose...
Dans le cas de HFS, il y a une table d'allocation, appelée "Volume Bitmap" qui indique au moyen d'un bit le statut (libre / occupé) de chacun des blocs. Dans HFS+ c'est remplacé par un l'Allocation File qui est géré comme un fichier.
La restriction en lecture seule est gérée plus haut, au niveau fichier.
Patrick -- Patrick Stadelmann
In article <1ickn60.1hgr1iuc6mhxuN%jayce@mosx.org>,
jayce@mosx.org (Anonyme) wrote:
Je dois donc avoir une autre table qui me donne les blocs en lecture
seule. Un bloc est donc utilisé ou non, libre en écriture ou non et
c'est tout ?
Chaque FS gère la chose comme il veut, et j'avour que je ne me suis
jamais penché sur la question pour savoir comment tel ou tel système
gérait la chose...
Dans le cas de HFS, il y a une table d'allocation, appelée "Volume
Bitmap" qui indique au moyen d'un bit le statut (libre / occupé) de
chacun des blocs. Dans HFS+ c'est remplacé par un l'Allocation File qui
est géré comme un fichier.
La restriction en lecture seule est gérée plus haut, au niveau fichier.
Patrick
--
Patrick Stadelmann <Patrick.Stadelmann@unine.ch>
In article <1ickn60.1hgr1iuc6mhxuN%, (Anonyme) wrote:
Benoit wrote:
Je dois donc avoir une autre table qui me donne les blocs en lecture seule. Un bloc est donc utilisé ou non, libre en écriture ou non et c'est tout ?
Chaque FS gère la chose comme il veut, et j'avour que je ne me suis jamais penché sur la question pour savoir comment tel ou tel système gérait la chose...
Dans le cas de HFS, il y a une table d'allocation, appelée "Volume Bitmap" qui indique au moyen d'un bit le statut (libre / occupé) de chacun des blocs. Dans HFS+ c'est remplacé par un l'Allocation File qui est géré comme un fichier.
La restriction en lecture seule est gérée plus haut, au niveau fichier.
Patrick -- Patrick Stadelmann
jenaipasdemail
Anonyme wrote:
Pareil, cela dépend du système de fichier, mais c'est sa tembouille à lui, "l'utilisateur" du système de fichier n'a pas à s'en préoccuper. (par "utilisateur", j'entends, l'OS, les applis, etc...)
Je sens que je vais me trouver un bon bouquin sur les FS du côté du Monde en Tique ;)
-- Benoit Leraillez
La douleur des autres est tout à fait supportable, hors les cris.
Anonyme <jayce@mosx.org> wrote:
Pareil, cela dépend du système de fichier, mais c'est sa tembouille à
lui, "l'utilisateur" du système de fichier n'a pas à s'en préoccuper.
(par "utilisateur", j'entends, l'OS, les applis, etc...)
Je sens que je vais me trouver un bon bouquin sur les FS du côté du
Monde en Tique ;)
--
Benoit Leraillez
La douleur des autres est tout à fait supportable, hors les cris.
Pareil, cela dépend du système de fichier, mais c'est sa tembouille à lui, "l'utilisateur" du système de fichier n'a pas à s'en préoccuper. (par "utilisateur", j'entends, l'OS, les applis, etc...)
Je sens que je vais me trouver un bon bouquin sur les FS du côté du Monde en Tique ;)
-- Benoit Leraillez
La douleur des autres est tout à fait supportable, hors les cris.
jenaipasdemail
Anonyme wrote:
C'est super simple. Il y a une table qui dit que tel "nom" pointe vers tels blocs. Dans cette même table, si il y a un autre "nom qui pointe vers le même bloc, ben ça se voit facilement. C'est de la BDD...
Alors je rajoute une question à propos de TimeMachine. La sauvegarde se fait avec des hards links, ok. Maintenant si je déplace un fichier san l'avoir modifié bien sûr. À la prochaine sauvegarde il est recopié à nouveau ou c'est juste un hard link vers les données ?
Exemple : J'ai un gros dossier que je déplace sur le disque mais aucun fichier n'a été modifié dans la dernière heure. Le dossier de la nouvelle sauvegarde est une recopie complète des données contenues dedans ou c'est juste un hard link qui pointe toujours vers les blocs déjà présents dans une sauvegarde précédente.
-- Benoit Leraillez
La douleur des autres est tout à fait supportable, hors les cris.
Anonyme <jayce@mosx.org> wrote:
C'est super simple. Il y a une table qui dit que tel "nom" pointe vers
tels blocs. Dans cette même table, si il y a un autre "nom qui pointe
vers le même bloc, ben ça se voit facilement. C'est de la BDD...
Alors je rajoute une question à propos de TimeMachine. La sauvegarde
se fait avec des hards links, ok. Maintenant si je déplace un fichier
san l'avoir modifié bien sûr. À la prochaine sauvegarde il est recopié à
nouveau ou c'est juste un hard link vers les données ?
Exemple : J'ai un gros dossier que je déplace sur le disque mais
aucun fichier n'a été modifié dans la dernière heure. Le dossier de la
nouvelle sauvegarde est une recopie complète des données contenues
dedans ou c'est juste un hard link qui pointe toujours vers les blocs
déjà présents dans une sauvegarde précédente.
--
Benoit Leraillez
La douleur des autres est tout à fait supportable, hors les cris.
C'est super simple. Il y a une table qui dit que tel "nom" pointe vers tels blocs. Dans cette même table, si il y a un autre "nom qui pointe vers le même bloc, ben ça se voit facilement. C'est de la BDD...
Alors je rajoute une question à propos de TimeMachine. La sauvegarde se fait avec des hards links, ok. Maintenant si je déplace un fichier san l'avoir modifié bien sûr. À la prochaine sauvegarde il est recopié à nouveau ou c'est juste un hard link vers les données ?
Exemple : J'ai un gros dossier que je déplace sur le disque mais aucun fichier n'a été modifié dans la dernière heure. Le dossier de la nouvelle sauvegarde est une recopie complète des données contenues dedans ou c'est juste un hard link qui pointe toujours vers les blocs déjà présents dans une sauvegarde précédente.
-- Benoit Leraillez
La douleur des autres est tout à fait supportable, hors les cris.
Eric Levenez
Le 20/02/08 15:05, dans <1icm4pf.are3bp16jbq2wN%, « Benoit » a écrit :
Maintenant si je déplace un fichier san l'avoir modifié bien sûr. À la prochaine sauvegarde il est recopié à nouveau ou c'est juste un hard link vers les données ?
Il est copié.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Le 20/02/08 15:05, dans
<1icm4pf.are3bp16jbq2wN%jenaipasdemail@mamado3o.com.invalid>, « Benoit »
<jenaipasdemail@mamado3o.com.invalid> a écrit :
Maintenant si je déplace un fichier
san l'avoir modifié bien sûr. À la prochaine sauvegarde il est recopié à
nouveau ou c'est juste un hard link vers les données ?
Il est copié.
--
Éric Lévénez -- <http://www.levenez.com/>
Unix is not only an OS, it's a way of life.
Le 20/02/08 15:05, dans <1icm4pf.are3bp16jbq2wN%, « Benoit » a écrit :
Maintenant si je déplace un fichier san l'avoir modifié bien sûr. À la prochaine sauvegarde il est recopié à nouveau ou c'est juste un hard link vers les données ?
Il est copié.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
jenaipasdemail
Eric Levenez wrote:
Maintenant si je déplace un fichier san l'avoir modifié bien sûr. À la prochaine sauvegarde il est recopié à nouveau ou c'est juste un hard link vers les données ?
Il est copié.
Vaut mieux pas reclasser ses images, musiques et films de façon trop régiluères alors ;-)
-- Benoit Leraillez
La douleur des autres est tout à fait supportable, hors les cris.
Eric Levenez <usenet@levenez.com> wrote:
Maintenant si je déplace un fichier
san l'avoir modifié bien sûr. À la prochaine sauvegarde il est recopié à
nouveau ou c'est juste un hard link vers les données ?
Il est copié.
Vaut mieux pas reclasser ses images, musiques et films de façon trop
régiluères alors ;-)
--
Benoit Leraillez
La douleur des autres est tout à fait supportable, hors les cris.
Maintenant si je déplace un fichier san l'avoir modifié bien sûr. À la prochaine sauvegarde il est recopié à nouveau ou c'est juste un hard link vers les données ?
Il est copié.
Vaut mieux pas reclasser ses images, musiques et films de façon trop régiluères alors ;-)
-- Benoit Leraillez
La douleur des autres est tout à fait supportable, hors les cris.
