La jeune fille s'appelle Justine, son home aussi...
Dans users, j'ai donc :
/justine, qui contient :
.autodiskmounted
.DS_Store
et.../.justine qui contient :
.DS_Store
justine.sparseimage
Le sparseimage fait 8 Go, c'est un truc qui a l'air de s'ouvrir avec
DiskUtility ; j'ai pas le pass, et la jeune Justine est en vacances...
C'EST QUOI CE SPARSEIMAGE ?????
--
Nina
oui, mais je crois qu'il y a des injonctions légale pour te faire cracher le mot de passe ;)
Vivi, d'ailleurs un grand gag, envoyer un mail chiffré avec une clé PGP à quelqu'un qui n'a pas cette clé, il sera fort embêté le jour où on lui demandera de le déchiffrer.
On peut varier les plaisirs, utiliser des certificats et jeter les anciens au moment où on renouvelle, tous les mails chiffrés avec l'ancien sont illisibles ;-)
-- Politically Correct Unix - UTILITIES The "touch" command has been removed from the standard distribution due to its inappropriate use by high-level managers.
patpro ~ Patrick Proniewski <patpro@boleskine.patpro.net> wrote:
oui, mais je crois qu'il y a des injonctions légale pour te faire
cracher le mot de passe ;)
Vivi, d'ailleurs un grand gag, envoyer un mail chiffré avec une clé PGP
à quelqu'un qui n'a pas cette clé, il sera fort embêté le jour où on lui
demandera de le déchiffrer.
On peut varier les plaisirs, utiliser des certificats et jeter les
anciens au moment où on renouvelle, tous les mails chiffrés avec
l'ancien sont illisibles ;-)
--
Politically Correct Unix - UTILITIES
The "touch" command has been removed from the standard distribution due
to its inappropriate use by high-level managers.
oui, mais je crois qu'il y a des injonctions légale pour te faire cracher le mot de passe ;)
Vivi, d'ailleurs un grand gag, envoyer un mail chiffré avec une clé PGP à quelqu'un qui n'a pas cette clé, il sera fort embêté le jour où on lui demandera de le déchiffrer.
On peut varier les plaisirs, utiliser des certificats et jeter les anciens au moment où on renouvelle, tous les mails chiffrés avec l'ancien sont illisibles ;-)
-- Politically Correct Unix - UTILITIES The "touch" command has been removed from the standard distribution due to its inappropriate use by high-level managers.
patpro ~ Patrick Proniewski
In article <1hu7efj.1ci7rc31gjp6lbN%, (Laurent Pertois) wrote:
On peut varier les plaisirs, utiliser des certificats et jeter les anciens au moment où on renouvelle, tous les mails chiffrés avec l'ancien sont illisibles ;-)
toi là, t'es en train de te moquer de moi :))) pas grave, j'ai détruit les preuves ;p
patpro
-- http://www.patpro.net/
In article <1hu7efj.1ci7rc31gjp6lbN%laurent.pertois@alussinan.org>,
laurent.pertois@alussinan.org (Laurent Pertois) wrote:
On peut varier les plaisirs, utiliser des certificats et jeter les
anciens au moment où on renouvelle, tous les mails chiffrés avec
l'ancien sont illisibles ;-)
toi là, t'es en train de te moquer de moi :)))
pas grave, j'ai détruit les preuves ;p
In article <1hu7efj.1ci7rc31gjp6lbN%, (Laurent Pertois) wrote:
On peut varier les plaisirs, utiliser des certificats et jeter les anciens au moment où on renouvelle, tous les mails chiffrés avec l'ancien sont illisibles ;-)
toi là, t'es en train de te moquer de moi :))) pas grave, j'ai détruit les preuves ;p
patpro
-- http://www.patpro.net/
olivier.marti
Gérard Cojot wrote:
Nina Popravka wrote:
On Tue, 27 Feb 2007 11:38:21 +0100, patpro ~ Patrick Proniewski wrote:
Je comprends d'ailleurs pas pourquoi une ado qui se ballade sans mot de passe pour son compte il y en a vraisemblablement un, mais autologon...
se retrouve avec FileVault activé, c'est débile et parfaitement contre productif. Moi je ne comprend pas comment on peut activer FileVault sans taper le
mot de passe.
Moi je comprends pas pourquoi on active FileVault. Et pourtant j'ai des données sensibles et j'ai plusieurs comptes sur mon ordi. La plupart des gens ne connaissent pas grand chose à l'informatique. Le labo de la police échouerait avec FileVault ?
La NSA avait publié il y a quelques années un document sur la sécurité avec Mac OS X. Et ils recommendaient FileFault.
Deux hypothèses :
- FileVault est sûr.
- La NSA sait casser FileVault, et donc le recommande aux futurs espionnés ...
Olivier
Gérard Cojot <gerald.coyot@SaFePaMal.fr> wrote:
Nina Popravka <Nina@nospam> wrote:
On Tue, 27 Feb 2007 11:38:21 +0100, patpro ~ Patrick Proniewski
<patpro@boleskine.patpro.net> wrote:
Je comprends d'ailleurs pas pourquoi une ado qui se ballade sans mot de
passe pour son compte
il y en a vraisemblablement un, mais autologon...
se retrouve avec FileVault activé, c'est débile et
parfaitement contre productif.
Moi je ne comprend pas comment on peut activer FileVault sans taper le
mot de passe.
Moi je comprends pas pourquoi on active FileVault.
Et pourtant j'ai des données sensibles et j'ai plusieurs comptes sur mon
ordi.
La plupart des gens ne connaissent pas grand chose à l'informatique.
Le labo de la police échouerait avec FileVault ?
La NSA avait publié il y a quelques années un document sur la sécurité
avec Mac OS X. Et ils recommendaient FileFault.
Deux hypothèses :
- FileVault est sûr.
- La NSA sait casser FileVault, et donc le recommande aux futurs
espionnés ...
On Tue, 27 Feb 2007 11:38:21 +0100, patpro ~ Patrick Proniewski wrote:
Je comprends d'ailleurs pas pourquoi une ado qui se ballade sans mot de passe pour son compte il y en a vraisemblablement un, mais autologon...
se retrouve avec FileVault activé, c'est débile et parfaitement contre productif. Moi je ne comprend pas comment on peut activer FileVault sans taper le
mot de passe.
Moi je comprends pas pourquoi on active FileVault. Et pourtant j'ai des données sensibles et j'ai plusieurs comptes sur mon ordi. La plupart des gens ne connaissent pas grand chose à l'informatique. Le labo de la police échouerait avec FileVault ?
La NSA avait publié il y a quelques années un document sur la sécurité avec Mac OS X. Et ils recommendaient FileFault.
Deux hypothèses :
- FileVault est sûr.
- La NSA sait casser FileVault, et donc le recommande aux futurs espionnés ...
Olivier
Patrick Stadelmann
In article , Nina Popravka wrote:
Bref donne-moi un exemple d'application précis.
Imagine un Mac OS X avec 100 Go d'espace libre et 4 utilisateurs. Chacun va pouvoir stocker des données dans son dossier jusqu'à ce que le disque soit plein. Mais impossible à priori de savoir si finalement il y aura 25 Go par utilisateur, ou si l'un va utiliser 80 Go. En utilisant des images "sparse" pour FileVault, Mac OS X donne à chaque utilisateur d'utiliser *potentiellement" jusqu'à 100 Go, ce qui serait impossible si les images utilisaient directement 100 Go chacune...
Patrick -- Patrick Stadelmann
In article <hje8u2l9vsth8dfu98ute6erfj6aj8hirv@4ax.com>,
Nina Popravka <Nina@nospam> wrote:
Bref donne-moi un exemple d'application précis.
Imagine un Mac OS X avec 100 Go d'espace libre et 4 utilisateurs. Chacun
va pouvoir stocker des données dans son dossier jusqu'à ce que le disque
soit plein. Mais impossible à priori de savoir si finalement il y aura
25 Go par utilisateur, ou si l'un va utiliser 80 Go. En utilisant des
images "sparse" pour FileVault, Mac OS X donne à chaque utilisateur
d'utiliser *potentiellement" jusqu'à 100 Go, ce qui serait impossible si
les images utilisaient directement 100 Go chacune...
Patrick
--
Patrick Stadelmann <Patrick.Stadelmann@unine.ch>
Imagine un Mac OS X avec 100 Go d'espace libre et 4 utilisateurs. Chacun va pouvoir stocker des données dans son dossier jusqu'à ce que le disque soit plein. Mais impossible à priori de savoir si finalement il y aura 25 Go par utilisateur, ou si l'un va utiliser 80 Go. En utilisant des images "sparse" pour FileVault, Mac OS X donne à chaque utilisateur d'utiliser *potentiellement" jusqu'à 100 Go, ce qui serait impossible si les images utilisaient directement 100 Go chacune...
Patrick -- Patrick Stadelmann
patpro ~ Patrick Proniewski
In article , Patrick Stadelmann wrote:
In article , Nina Popravka wrote:
Bref donne-moi un exemple d'application précis.
Imagine un Mac OS X avec 100 Go d'espace libre et 4 utilisateurs. Chacun va pouvoir stocker des données dans son dossier jusqu'à ce que le disque soit plein. Mais impossible à priori de savoir si finalement il y aura 25 Go par utilisateur, ou si l'un va utiliser 80 Go. En utilisant des images "sparse" pour FileVault, Mac OS X donne à chaque utilisateur d'utiliser *potentiellement" jusqu'à 100 Go, ce qui serait impossible si les images utilisaient directement 100 Go chacune...
ha...aurais-je surestimé la portée de la question. J'avais compris que Nina voulait un exemple justifiant l'implémentation d'un fichier à trou plutôt que d'un fichier pouvant grandir normalement (DB ou simple fichier txt). De plus, Eric nous a dit que ce n'est pas un vrai fichier à trou (la sparseimage Filevault), donc ce n'est pas un exemple réél d'application. Non ?
patpro
-- http://www.patpro.net/
In article <Patrick.Stadelmann-951484.17502227022007@individual.net>,
Patrick Stadelmann <Patrick.Stadelmann@unine.ch> wrote:
In article <hje8u2l9vsth8dfu98ute6erfj6aj8hirv@4ax.com>,
Nina Popravka <Nina@nospam> wrote:
Bref donne-moi un exemple d'application précis.
Imagine un Mac OS X avec 100 Go d'espace libre et 4 utilisateurs. Chacun
va pouvoir stocker des données dans son dossier jusqu'à ce que le disque
soit plein. Mais impossible à priori de savoir si finalement il y aura
25 Go par utilisateur, ou si l'un va utiliser 80 Go. En utilisant des
images "sparse" pour FileVault, Mac OS X donne à chaque utilisateur
d'utiliser *potentiellement" jusqu'à 100 Go, ce qui serait impossible si
les images utilisaient directement 100 Go chacune...
ha...aurais-je surestimé la portée de la question. J'avais compris que
Nina voulait un exemple justifiant l'implémentation d'un fichier à trou
plutôt que d'un fichier pouvant grandir normalement (DB ou simple
fichier txt).
De plus, Eric nous a dit que ce n'est pas un vrai fichier à trou (la
sparseimage Filevault), donc ce n'est pas un exemple réél d'application.
Non ?
Imagine un Mac OS X avec 100 Go d'espace libre et 4 utilisateurs. Chacun va pouvoir stocker des données dans son dossier jusqu'à ce que le disque soit plein. Mais impossible à priori de savoir si finalement il y aura 25 Go par utilisateur, ou si l'un va utiliser 80 Go. En utilisant des images "sparse" pour FileVault, Mac OS X donne à chaque utilisateur d'utiliser *potentiellement" jusqu'à 100 Go, ce qui serait impossible si les images utilisaient directement 100 Go chacune...
ha...aurais-je surestimé la portée de la question. J'avais compris que Nina voulait un exemple justifiant l'implémentation d'un fichier à trou plutôt que d'un fichier pouvant grandir normalement (DB ou simple fichier txt). De plus, Eric nous a dit que ce n'est pas un vrai fichier à trou (la sparseimage Filevault), donc ce n'est pas un exemple réél d'application. Non ?
patpro
-- http://www.patpro.net/
cfranco
Patrick Stadelmann wrote:
Bref donne-moi un exemple d'application précis.
Imagine un Mac OS X avec 100 Go d'espace libre et 4 utilisateurs. Chacun va pouvoir stocker des données dans son dossier jusqu'à ce que le disque soit plein. Mais impossible à priori de savoir si finalement il y aura 25 Go par utilisateur, ou si l'un va utiliser 80 Go. En utilisant des images "sparse" pour FileVault, Mac OS X donne à chaque utilisateur d'utiliser *potentiellement" jusqu'à 100 Go, ce qui serait impossible si les images utilisaient directement 100 Go chacune...
En quoi cela ne pourrait-il pas être implémenté avec un système de quota tout ce qu'il y a de plus traditionnel ?
-- Christophe Franco
Patrick Stadelmann <Patrick.Stadelmann@unine.ch> wrote:
Bref donne-moi un exemple d'application précis.
Imagine un Mac OS X avec 100 Go d'espace libre et 4 utilisateurs. Chacun
va pouvoir stocker des données dans son dossier jusqu'à ce que le disque
soit plein. Mais impossible à priori de savoir si finalement il y aura
25 Go par utilisateur, ou si l'un va utiliser 80 Go. En utilisant des
images "sparse" pour FileVault, Mac OS X donne à chaque utilisateur
d'utiliser *potentiellement" jusqu'à 100 Go, ce qui serait impossible si
les images utilisaient directement 100 Go chacune...
En quoi cela ne pourrait-il pas être implémenté avec un système de quota
tout ce qu'il y a de plus traditionnel ?
Imagine un Mac OS X avec 100 Go d'espace libre et 4 utilisateurs. Chacun va pouvoir stocker des données dans son dossier jusqu'à ce que le disque soit plein. Mais impossible à priori de savoir si finalement il y aura 25 Go par utilisateur, ou si l'un va utiliser 80 Go. En utilisant des images "sparse" pour FileVault, Mac OS X donne à chaque utilisateur d'utiliser *potentiellement" jusqu'à 100 Go, ce qui serait impossible si les images utilisaient directement 100 Go chacune...
En quoi cela ne pourrait-il pas être implémenté avec un système de quota tout ce qu'il y a de plus traditionnel ?
-- Christophe Franco
Eric Levenez
Le 27/02/07 13:10, dans , « Nina Popravka » a écrit :
On Tue, 27 Feb 2007 12:54:36 +0100, Eric Levenez wrote:
Le système fera la même chose qu'un fichier normal : si on ajoute un bloc à un fichier et qu'il n'y a plus de place, il retourne une erreur. Cela est vrai que le bloc soit à la fin (situation "normale") ou dans un trou.
Donc le fichier à trou n'implique pas de notion de réservation d'espace ? Genre "fais-moi une image de ce dossier qui fera au maxi 10 go et démerde-toi avec comme tu le sens, moi je veux pouvoir mettre 10 Go dedans quand ça me chantera " .
Non, il n'y a aucune réservation, et c'est cela l'intérêt.
Alors question subsidiaire : à quoi ça sert ?
C'est utilisé par exemple par certains gros programmes de calcul sur des machines avec peu de RAM. Le programme crée un fichier qui va contenir des données, par exemple un gros tableau (initialisé à 0). Le programme va alors écrire des données de-ci delà dans le fichier. L'intérêt d'un fichier "sparse" est que seuls les blocs qui contiennent des données sont écrits sur disque. Ainsi une matrice gigantesque tiendra dans peu de place disque.
Maintenant on fait la même chose avec la mémoire et des CPU 64 bits. On alloue des giga d'octets en mémoire virtuelle pour le tableau, et donc en pratique cela prend une place RAM nulle. Puis on écrit dans des cases du tableau. Le système va allouer des blocs de RAM pour chaque case occupée. Au final on aura des gigas de mémoire virtuelle mais peu de RAM pris. C'est un des intérêts du 64 bits.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Le 27/02/07 13:10, dans <ln78u2lbj3fe69l9rq0egm02gj4ookgcl3@4ax.com>, « Nina
Popravka » <Nina@nospam> a écrit :
On Tue, 27 Feb 2007 12:54:36 +0100, Eric Levenez <news@levenez.com>
wrote:
Le système fera la même chose qu'un fichier normal : si on ajoute un bloc à
un fichier et qu'il n'y a plus de place, il retourne une erreur. Cela est
vrai que le bloc soit à la fin (situation "normale") ou dans un trou.
Donc le fichier à trou n'implique pas de notion de réservation
d'espace ? Genre "fais-moi une image de ce dossier qui fera au maxi 10
go et démerde-toi avec comme tu le sens, moi je veux pouvoir mettre 10
Go dedans quand ça me chantera " .
Non, il n'y a aucune réservation, et c'est cela l'intérêt.
Alors question subsidiaire : à quoi ça sert ?
C'est utilisé par exemple par certains gros programmes de calcul sur des
machines avec peu de RAM. Le programme crée un fichier qui va contenir des
données, par exemple un gros tableau (initialisé à 0). Le programme va alors
écrire des données de-ci delà dans le fichier. L'intérêt d'un fichier
"sparse" est que seuls les blocs qui contiennent des données sont écrits sur
disque. Ainsi une matrice gigantesque tiendra dans peu de place disque.
Maintenant on fait la même chose avec la mémoire et des CPU 64 bits. On
alloue des giga d'octets en mémoire virtuelle pour le tableau, et donc en
pratique cela prend une place RAM nulle. Puis on écrit dans des cases du
tableau. Le système va allouer des blocs de RAM pour chaque case occupée. Au
final on aura des gigas de mémoire virtuelle mais peu de RAM pris. C'est un
des intérêts du 64 bits.
--
Éric Lévénez -- <http://www.levenez.com/>
Unix is not only an OS, it's a way of life.
Le 27/02/07 13:10, dans , « Nina Popravka » a écrit :
On Tue, 27 Feb 2007 12:54:36 +0100, Eric Levenez wrote:
Le système fera la même chose qu'un fichier normal : si on ajoute un bloc à un fichier et qu'il n'y a plus de place, il retourne une erreur. Cela est vrai que le bloc soit à la fin (situation "normale") ou dans un trou.
Donc le fichier à trou n'implique pas de notion de réservation d'espace ? Genre "fais-moi une image de ce dossier qui fera au maxi 10 go et démerde-toi avec comme tu le sens, moi je veux pouvoir mettre 10 Go dedans quand ça me chantera " .
Non, il n'y a aucune réservation, et c'est cela l'intérêt.
Alors question subsidiaire : à quoi ça sert ?
C'est utilisé par exemple par certains gros programmes de calcul sur des machines avec peu de RAM. Le programme crée un fichier qui va contenir des données, par exemple un gros tableau (initialisé à 0). Le programme va alors écrire des données de-ci delà dans le fichier. L'intérêt d'un fichier "sparse" est que seuls les blocs qui contiennent des données sont écrits sur disque. Ainsi une matrice gigantesque tiendra dans peu de place disque.
Maintenant on fait la même chose avec la mémoire et des CPU 64 bits. On alloue des giga d'octets en mémoire virtuelle pour le tableau, et donc en pratique cela prend une place RAM nulle. Puis on écrit dans des cases du tableau. Le système va allouer des blocs de RAM pour chaque case occupée. Au final on aura des gigas de mémoire virtuelle mais peu de RAM pris. C'est un des intérêts du 64 bits.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Eric Levenez
Le 27/02/07 18:27, dans <1hu7hwd.1jk3tu1mur0khN%, « Christophe Franco » a écrit :
Patrick Stadelmann wrote:
Bref donne-moi un exemple d'application précis.
Imagine un Mac OS X avec 100 Go d'espace libre et 4 utilisateurs. Chacun va pouvoir stocker des données dans son dossier jusqu'à ce que le disque soit plein. Mais impossible à priori de savoir si finalement il y aura 25 Go par utilisateur, ou si l'un va utiliser 80 Go. En utilisant des images "sparse" pour FileVault, Mac OS X donne à chaque utilisateur d'utiliser *potentiellement" jusqu'à 100 Go, ce qui serait impossible si les images utilisaient directement 100 Go chacune...
En quoi cela ne pourrait-il pas être implémenté avec un système de quota tout ce qu'il y a de plus traditionnel ?
Avec ZFS je crois que l'on peut créer des partitions dont la somme de la place est inférieure à la taille du disque. Ainsi avec un disque de 300 Mo on peut faire 4 partitions de 100 Mo pour 4 utilisateurs. Il ne faut pas que ces utilisateurs utilisent toute la place en même temps, et cela revient à avoir un quota de 100 Mo, mais c'est plus souple car chaque partition n'est pas forcément liée à un utilisateur.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Le 27/02/07 18:27, dans <1hu7hwd.1jk3tu1mur0khN%cfranco@pobox.com>,
« Christophe Franco » <cfranco@pobox.com> a écrit :
Patrick Stadelmann <Patrick.Stadelmann@unine.ch> wrote:
Bref donne-moi un exemple d'application précis.
Imagine un Mac OS X avec 100 Go d'espace libre et 4 utilisateurs. Chacun
va pouvoir stocker des données dans son dossier jusqu'à ce que le disque
soit plein. Mais impossible à priori de savoir si finalement il y aura
25 Go par utilisateur, ou si l'un va utiliser 80 Go. En utilisant des
images "sparse" pour FileVault, Mac OS X donne à chaque utilisateur
d'utiliser *potentiellement" jusqu'à 100 Go, ce qui serait impossible si
les images utilisaient directement 100 Go chacune...
En quoi cela ne pourrait-il pas être implémenté avec un système de quota
tout ce qu'il y a de plus traditionnel ?
Avec ZFS je crois que l'on peut créer des partitions dont la somme de la
place est inférieure à la taille du disque. Ainsi avec un disque de 300 Mo
on peut faire 4 partitions de 100 Mo pour 4 utilisateurs. Il ne faut pas que
ces utilisateurs utilisent toute la place en même temps, et cela revient à
avoir un quota de 100 Mo, mais c'est plus souple car chaque partition n'est
pas forcément liée à un utilisateur.
--
Éric Lévénez -- <http://www.levenez.com/>
Unix is not only an OS, it's a way of life.
Le 27/02/07 18:27, dans <1hu7hwd.1jk3tu1mur0khN%, « Christophe Franco » a écrit :
Patrick Stadelmann wrote:
Bref donne-moi un exemple d'application précis.
Imagine un Mac OS X avec 100 Go d'espace libre et 4 utilisateurs. Chacun va pouvoir stocker des données dans son dossier jusqu'à ce que le disque soit plein. Mais impossible à priori de savoir si finalement il y aura 25 Go par utilisateur, ou si l'un va utiliser 80 Go. En utilisant des images "sparse" pour FileVault, Mac OS X donne à chaque utilisateur d'utiliser *potentiellement" jusqu'à 100 Go, ce qui serait impossible si les images utilisaient directement 100 Go chacune...
En quoi cela ne pourrait-il pas être implémenté avec un système de quota tout ce qu'il y a de plus traditionnel ?
Avec ZFS je crois que l'on peut créer des partitions dont la somme de la place est inférieure à la taille du disque. Ainsi avec un disque de 300 Mo on peut faire 4 partitions de 100 Mo pour 4 utilisateurs. Il ne faut pas que ces utilisateurs utilisent toute la place en même temps, et cela revient à avoir un quota de 100 Mo, mais c'est plus souple car chaque partition n'est pas forcément liée à un utilisateur.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
gerald.coyot
Olivier Marti wrote:
La NSA avait publié il y a quelques années un document sur la sécurité avec Mac OS X. Et ils recommendaient FileFault.
Ca na Vault rien donc. -- Amitiés, Gérard Cojot 'Bienheureux les fêlés, ils laisseront passer ma lumière'[M.Audiard] http://perso.orange.fr/gerard.cojot/
Olivier Marti <olivier.marti@ensta.org> wrote:
La NSA avait publié il y a quelques années un document sur la sécurité
avec Mac OS X. Et ils recommendaient FileFault.
Ca na Vault rien donc.
--
Amitiés, Gérard Cojot
'Bienheureux les fêlés, ils laisseront passer ma lumière'[M.Audiard]
http://perso.orange.fr/gerard.cojot/
La NSA avait publié il y a quelques années un document sur la sécurité avec Mac OS X. Et ils recommendaient FileFault.
Ca na Vault rien donc. -- Amitiés, Gérard Cojot 'Bienheureux les fêlés, ils laisseront passer ma lumière'[M.Audiard] http://perso.orange.fr/gerard.cojot/
Patrick Stadelmann
In article , patpro ~ Patrick Proniewski wrote:
ha...aurais-je surestimé la portée de la question. J'avais compris que Nina voulait un exemple justifiant l'implémentation d'un fichier à trou plutôt que d'un fichier pouvant grandir normalement (DB ou simple fichier txt).
C'est bien le cas avec une image disque, vu que même vide (et occupant donc quasi rien sur le disque) l'image monté est vue comme un volume de 100 Go par exemple.
De plus, Eric nous a dit que ce n'est pas un vrai fichier à trou (la sparseimage Filevault), donc ce n'est pas un exemple réél d'application. Non ?
Le fichier sparse, non vu qu'il est stocké sur HFS qui ne supporte pas les fichiers à trous. Mais si l'on crée sur ce fs un fichier de 1 Go vide, la taille de l'image sparse ne change pas. Si on écrit 50 Mo à l'offset 800 Mo de ce fichier, la taille de l'image sparse n'augmente que de 50 Mo. Le fichier est donc bien "à trous", mais pas sur son fs (celui contenu dans l'image, qui considère qu'il occupe 1 Go d'espace) mais sur le fs contenant l'image sparse.
Donc, le mécanisme des images sparse permet d'avoir des fichiers à trous sur HFS, mais indirectement, via un fs intermédiaire !
Patrick -- Patrick Stadelmann
In article <patpro-85098B.18032027022007@localhost>,
patpro ~ Patrick Proniewski <patpro@boleskine.patpro.net> wrote:
ha...aurais-je surestimé la portée de la question. J'avais compris que
Nina voulait un exemple justifiant l'implémentation d'un fichier à trou
plutôt que d'un fichier pouvant grandir normalement (DB ou simple
fichier txt).
C'est bien le cas avec une image disque, vu que même vide (et occupant
donc quasi rien sur le disque) l'image monté est vue comme un volume de
100 Go par exemple.
De plus, Eric nous a dit que ce n'est pas un vrai fichier à trou (la
sparseimage Filevault), donc ce n'est pas un exemple réél d'application.
Non ?
Le fichier sparse, non vu qu'il est stocké sur HFS qui ne supporte pas
les fichiers à trous. Mais si l'on crée sur ce fs un fichier de 1 Go
vide, la taille de l'image sparse ne change pas. Si on écrit 50 Mo à
l'offset 800 Mo de ce fichier, la taille de l'image sparse n'augmente
que de 50 Mo. Le fichier est donc bien "à trous", mais pas sur son fs
(celui contenu dans l'image, qui considère qu'il occupe 1 Go d'espace)
mais sur le fs contenant l'image sparse.
Donc, le mécanisme des images sparse permet d'avoir des fichiers à trous
sur HFS, mais indirectement, via un fs intermédiaire !
Patrick
--
Patrick Stadelmann <Patrick.Stadelmann@unine.ch>
ha...aurais-je surestimé la portée de la question. J'avais compris que Nina voulait un exemple justifiant l'implémentation d'un fichier à trou plutôt que d'un fichier pouvant grandir normalement (DB ou simple fichier txt).
C'est bien le cas avec une image disque, vu que même vide (et occupant donc quasi rien sur le disque) l'image monté est vue comme un volume de 100 Go par exemple.
De plus, Eric nous a dit que ce n'est pas un vrai fichier à trou (la sparseimage Filevault), donc ce n'est pas un exemple réél d'application. Non ?
Le fichier sparse, non vu qu'il est stocké sur HFS qui ne supporte pas les fichiers à trous. Mais si l'on crée sur ce fs un fichier de 1 Go vide, la taille de l'image sparse ne change pas. Si on écrit 50 Mo à l'offset 800 Mo de ce fichier, la taille de l'image sparse n'augmente que de 50 Mo. Le fichier est donc bien "à trous", mais pas sur son fs (celui contenu dans l'image, qui considère qu'il occupe 1 Go d'espace) mais sur le fs contenant l'image sparse.
Donc, le mécanisme des images sparse permet d'avoir des fichiers à trous sur HFS, mais indirectement, via un fs intermédiaire !
