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
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 " . Alors question subsidiaire : à quoi ça sert ? -- Nina
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 " .
Alors question subsidiaire : à quoi ça sert ?
--
Nina
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 " . Alors question subsidiaire : à quoi ça sert ? -- Nina
Erwan David
Eric Levenez écrivait :
Le 26/02/07 21:28, dans , « Erwan David » a écrit :
Oui, mais l'image ne devrait PAS être sparse,
Elle ne l'est pas au sens où tu l'entends car Mac OS X ne gère pas "les fichiers à trou" comme tu les appelles sur HFS+. Ces fichiers ne sont gérés que sur UFS et ZFS.
même les zones non utilisées dans l'image devraient être chiffrées.
Mauvaise conclusion pour une mauvaise hypothèse de départ basée sur une mauvaise interprétation du nom du fichier.
Ok, merci.
-- Erwan
Eric Levenez <news@levenez.com> écrivait :
Le 26/02/07 21:28, dans <m2veho64tw.fsf@ratagaz.local>, « Erwan David »
<erwan@rail.eu.org> a écrit :
Oui, mais l'image ne devrait PAS être sparse,
Elle ne l'est pas au sens où tu l'entends car Mac OS X ne gère pas "les
fichiers à trou" comme tu les appelles sur HFS+. Ces fichiers ne sont gérés
que sur UFS et ZFS.
même les zones non
utilisées dans l'image devraient être chiffrées.
Mauvaise conclusion pour une mauvaise hypothèse de départ basée sur une
mauvaise interprétation du nom du fichier.
Le 26/02/07 21:28, dans , « Erwan David » a écrit :
Oui, mais l'image ne devrait PAS être sparse,
Elle ne l'est pas au sens où tu l'entends car Mac OS X ne gère pas "les fichiers à trou" comme tu les appelles sur HFS+. Ces fichiers ne sont gérés que sur UFS et ZFS.
même les zones non utilisées dans l'image devraient être chiffrées.
Mauvaise conclusion pour une mauvaise hypothèse de départ basée sur une mauvaise interprétation du nom du fichier.
Ok, merci.
-- Erwan
patpro ~ Patrick Proniewski
In article , Nina Popravka wrote:
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 " . Alors question subsidiaire : à quoi ça sert ?
ben ca sert précisément à pas réserver l'espace, sinon tu crées directement le fichier à sa taille maximum... non ? :)
patpro
-- http://www.patpro.net/
In article <ln78u2lbj3fe69l9rq0egm02gj4ookgcl3@4ax.com>,
Nina Popravka <Nina@nospam> wrote:
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 " .
Alors question subsidiaire : à quoi ça sert ?
ben ca sert précisément à pas réserver l'espace, sinon tu crées
directement le fichier à sa taille maximum... non ? :)
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 " . Alors question subsidiaire : à quoi ça sert ?
ben ca sert précisément à pas réserver l'espace, sinon tu crées directement le fichier à sa taille maximum... non ? :)
patpro
-- http://www.patpro.net/
Nina Popravka
On Tue, 27 Feb 2007 14:51:04 +0100, patpro ~ Patrick Proniewski wrote:
ben ca sert précisément à pas réserver l'espace, sinon tu crées directement le fichier à sa taille maximum... non ? :)
Bin non... Pourquoi faire un fichier d'une race particulière, à ce compte ???? Toute base de données ou assimilée sait faire un truc qui y ressemble, et c'est le principal besoin que je puisse voir, du bout de mon nez (qui est court) Sinon tout fichier est amené à grossir jusque... on sait pas où. Bref donne-moi un exemple d'application précis. -- Nina
On Tue, 27 Feb 2007 14:51:04 +0100, patpro ~ Patrick Proniewski
<patpro@boleskine.patpro.net> wrote:
ben ca sert précisément à pas réserver l'espace, sinon tu crées
directement le fichier à sa taille maximum... non ? :)
Bin non...
Pourquoi faire un fichier d'une race particulière, à ce compte ????
Toute base de données ou assimilée sait faire un truc qui y ressemble,
et c'est le principal besoin que je puisse voir, du bout de mon nez
(qui est court)
Sinon tout fichier est amené à grossir jusque... on sait pas où.
Bref donne-moi un exemple d'application précis.
--
Nina
On Tue, 27 Feb 2007 14:51:04 +0100, patpro ~ Patrick Proniewski wrote:
ben ca sert précisément à pas réserver l'espace, sinon tu crées directement le fichier à sa taille maximum... non ? :)
Bin non... Pourquoi faire un fichier d'une race particulière, à ce compte ???? Toute base de données ou assimilée sait faire un truc qui y ressemble, et c'est le principal besoin que je puisse voir, du bout de mon nez (qui est court) Sinon tout fichier est amené à grossir jusque... on sait pas où. Bref donne-moi un exemple d'application précis. -- Nina
cfranco
Nina Popravka 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 " . Alors question subsidiaire : à quoi ça sert ?
Au hasard : je télécharge un gros fichier (du style 699.99Mo..), avec - comme par hasard - un logiciel qui ne le télécharge pas forcément du début jusqu'à la fin, mais plutôt petit bout par petit bout, éparpillés un peu partout dans le fichier, et je veux que le fichier en cours de téléchargement soit stocké "tel qu'il sera quand il sera fini" pour que certains logiciels puissent arriver à commencer à le lire sans forcément attendre qu'il soit complètement téléchargé (et tout ça, en ne gaspillant pas l'espace disque, sachant que sur 10 fichiers du même genre que je télécharge, il peut y en avoir facilement 2 ou 3 où le téléchargement ne finira jamais parce que les sources de téléchargement n'ont qu'un ensemble incomplet des fragments...)
Me suis-je bien fait comprendre ?... ;-)
-- Christophe Franco
Nina Popravka <Nina@nospam> 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 " .
Alors question subsidiaire : à quoi ça sert ?
Au hasard : je télécharge un gros fichier (du style 699.99Mo..), avec -
comme par hasard - un logiciel qui ne le télécharge pas forcément du
début jusqu'à la fin, mais plutôt petit bout par petit bout, éparpillés
un peu partout dans le fichier, et je veux que le fichier en cours de
téléchargement soit stocké "tel qu'il sera quand il sera fini" pour que
certains logiciels puissent arriver à commencer à le lire sans forcément
attendre qu'il soit complètement téléchargé (et tout ça, en ne
gaspillant pas l'espace disque, sachant que sur 10 fichiers du même
genre que je télécharge, il peut y en avoir facilement 2 ou 3 où le
téléchargement ne finira jamais parce que les sources de téléchargement
n'ont qu'un ensemble incomplet des fragments...)
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 " . Alors question subsidiaire : à quoi ça sert ?
Au hasard : je télécharge un gros fichier (du style 699.99Mo..), avec - comme par hasard - un logiciel qui ne le télécharge pas forcément du début jusqu'à la fin, mais plutôt petit bout par petit bout, éparpillés un peu partout dans le fichier, et je veux que le fichier en cours de téléchargement soit stocké "tel qu'il sera quand il sera fini" pour que certains logiciels puissent arriver à commencer à le lire sans forcément attendre qu'il soit complètement téléchargé (et tout ça, en ne gaspillant pas l'espace disque, sachant que sur 10 fichiers du même genre que je télécharge, il peut y en avoir facilement 2 ou 3 où le téléchargement ne finira jamais parce que les sources de téléchargement n'ont qu'un ensemble incomplet des fragments...)
Me suis-je bien fait comprendre ?... ;-)
-- Christophe Franco
patpro ~ Patrick Proniewski
In article , Nina Popravka wrote:
On Tue, 27 Feb 2007 14:51:04 +0100, patpro ~ Patrick Proniewski wrote:
ben ca sert précisément à pas réserver l'espace, sinon tu crées directement le fichier à sa taille maximum... non ? :)
Bin non... Pourquoi faire un fichier d'une race particulière, à ce compte ???? Toute base de données ou assimilée sait faire un truc qui y ressemble, et c'est le principal besoin que je puisse voir, du bout de mon nez (qui est court) Sinon tout fichier est amené à grossir jusque... on sait pas où. Bref donne-moi un exemple d'application précis.
je n'ai pas les connaissances fonctionnelles de bas niveau pour prouver la pertinence de ce choix technologiques... je pense que les vieux barbus pourront t'en dire plus sur les tenants et les aboutissants des fichiers à trous et autres sparseimage.
patpro
-- http://www.patpro.net/
In article <hje8u2l9vsth8dfu98ute6erfj6aj8hirv@4ax.com>,
Nina Popravka <Nina@nospam> wrote:
On Tue, 27 Feb 2007 14:51:04 +0100, patpro ~ Patrick Proniewski
<patpro@boleskine.patpro.net> wrote:
ben ca sert précisément à pas réserver l'espace, sinon tu crées
directement le fichier à sa taille maximum... non ? :)
Bin non...
Pourquoi faire un fichier d'une race particulière, à ce compte ????
Toute base de données ou assimilée sait faire un truc qui y ressemble,
et c'est le principal besoin que je puisse voir, du bout de mon nez
(qui est court)
Sinon tout fichier est amené à grossir jusque... on sait pas où.
Bref donne-moi un exemple d'application précis.
je n'ai pas les connaissances fonctionnelles de bas niveau pour prouver
la pertinence de ce choix technologiques... je pense que les vieux
barbus pourront t'en dire plus sur les tenants et les aboutissants des
fichiers à trous et autres sparseimage.
On Tue, 27 Feb 2007 14:51:04 +0100, patpro ~ Patrick Proniewski wrote:
ben ca sert précisément à pas réserver l'espace, sinon tu crées directement le fichier à sa taille maximum... non ? :)
Bin non... Pourquoi faire un fichier d'une race particulière, à ce compte ???? Toute base de données ou assimilée sait faire un truc qui y ressemble, et c'est le principal besoin que je puisse voir, du bout de mon nez (qui est court) Sinon tout fichier est amené à grossir jusque... on sait pas où. Bref donne-moi un exemple d'application précis.
je n'ai pas les connaissances fonctionnelles de bas niveau pour prouver la pertinence de ce choix technologiques... je pense que les vieux barbus pourront t'en dire plus sur les tenants et les aboutissants des fichiers à trous et autres sparseimage.
patpro
-- http://www.patpro.net/
laurent.pertois
Benoit Leraillez wrote:
Laurent Pertois wrote:
Mais sinon, oui, j'en ai vu comme ça :)
Si seulement on pouvait désactiver le bouton « Plus tard » sur les dialogues de recherche de mise à jour Apple.
Arf...
-- Politically Correct Unix - UTILITIES The "touch" command has been removed from the standard distribution due to its inappropriate use by high-level managers.
Si seulement on pouvait désactiver le bouton « Plus tard » sur les
dialogues de recherche de mise à jour Apple.
Arf...
--
Politically Correct Unix - UTILITIES
The "touch" command has been removed from the standard distribution due
to its inappropriate use by high-level managers.
Si seulement on pouvait désactiver le bouton « Plus tard » sur les dialogues de recherche de mise à jour Apple.
Arf...
-- Politically Correct Unix - UTILITIES The "touch" command has been removed from the standard distribution due to its inappropriate use by high-level managers.
laurent.pertois
Nina Popravka wrote:
J'y ai pensé, mais j'ai un gros doute sur la possibilité de trouver une machine qui sache booter sur un disque USB *et* sache fonctionner avec la version de MacOSX qu'il y a dessus.
Ah ça, faudrait plutôt mettre le disque dedans ou en FireWire, c'est plus universel.
-- Politically Correct Unix - UTILITIES The "touch" command has been removed from the standard distribution due to its inappropriate use by high-level managers.
Nina Popravka <Nina@nospam> wrote:
J'y ai pensé, mais j'ai un gros doute sur la possibilité de trouver
une machine qui sache booter sur un disque USB *et* sache fonctionner
avec la version de MacOSX qu'il y a dessus.
Ah ça, faudrait plutôt mettre le disque dedans ou en FireWire, c'est
plus universel.
--
Politically Correct Unix - UTILITIES
The "touch" command has been removed from the standard distribution due
to its inappropriate use by high-level managers.
J'y ai pensé, mais j'ai un gros doute sur la possibilité de trouver une machine qui sache booter sur un disque USB *et* sache fonctionner avec la version de MacOSX qu'il y a dessus.
Ah ça, faudrait plutôt mettre le disque dedans ou en FireWire, c'est plus universel.
-- Politically Correct Unix - UTILITIES The "touch" command has been removed from the standard distribution due to its inappropriate use by high-level managers.
laurent.pertois
Christophe Franco wrote:
Si tu remet le disque dans la machine, et que tu bootes dessus avec un CD système, tu devrais pouvoir réinitialiser ce fameux mot de passe non ? Avec un peu de chance, si Mac OS X est bien fait, il devrait propager la modification à File Vault...
Euh, non, au contraire, ça me gènerait qu'il sache le propager à FileVault...
Sinon, il y a bien le mot de passe Safety Net qu'on définit quand on active FileVault mais vu que la demoiselle ne se souvient déjà pas de son mot de passe, je pense qu'elle a aussi oublié celui-ci, voire l'a carrément évité.
-- Politically Correct Unix - UTILITIES The "touch" command has been removed from the standard distribution due to its inappropriate use by high-level managers.
Christophe Franco <cfranco@pobox.com> wrote:
Si tu remet le disque dans la machine, et que tu bootes dessus avec un
CD système, tu devrais pouvoir réinitialiser ce fameux mot de passe non
? Avec un peu de chance, si Mac OS X est bien fait, il devrait propager
la modification à File Vault...
Euh, non, au contraire, ça me gènerait qu'il sache le propager à
FileVault...
Sinon, il y a bien le mot de passe Safety Net qu'on définit quand on
active FileVault mais vu que la demoiselle ne se souvient déjà pas de
son mot de passe, je pense qu'elle a aussi oublié celui-ci, voire l'a
carrément évité.
--
Politically Correct Unix - UTILITIES
The "touch" command has been removed from the standard distribution due
to its inappropriate use by high-level managers.
Si tu remet le disque dans la machine, et que tu bootes dessus avec un CD système, tu devrais pouvoir réinitialiser ce fameux mot de passe non ? Avec un peu de chance, si Mac OS X est bien fait, il devrait propager la modification à File Vault...
Euh, non, au contraire, ça me gènerait qu'il sache le propager à FileVault...
Sinon, il y a bien le mot de passe Safety Net qu'on définit quand on active FileVault mais vu que la demoiselle ne se souvient déjà pas de son mot de passe, je pense qu'elle a aussi oublié celui-ci, voire l'a carrément évité.
-- Politically Correct Unix - UTILITIES The "touch" command has been removed from the standard distribution due to its inappropriate use by high-level managers.
laurent.pertois
patpro ~ Patrick Proniewski wrote:
pour le cas particulier de FileVault, il existe un mot de passe admin, en plus du mot de passe utilisateur, qu'il est fortement conseillé de régler, car il permet (si mes souvenirs sont bons) la récupération d'un fichier filevault si l'utilisateur à perdu son pass. Laurent (P.) me corrigera si je m'égare, je n'ai jamais utilisé Filevault.
Oui, le "mot de passe maître" appelé aussi "safety net". Il fonctionne avec des certificats et une clé qui permet d'ouvrir un keychain qui contient la clé privée du certificat (je schématise).
Sinon, en entreprise il suffit de ne pas mettre les utilisateurs en admin de leur poste, il faut le mot de passe de l'admin de la machine pour activer FileVault sur un compte (Préférence système Sécurité).
Quant au chiffrement des image-disques de Mac OS X c'est de l'AES-128 pour les curieux.
-- 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:
pour le cas particulier de FileVault, il existe un mot de passe admin,
en plus du mot de passe utilisateur, qu'il est fortement conseillé de
régler, car il permet (si mes souvenirs sont bons) la récupération d'un
fichier filevault si l'utilisateur à perdu son pass. Laurent (P.) me
corrigera si je m'égare, je n'ai jamais utilisé Filevault.
Oui, le "mot de passe maître" appelé aussi "safety net". Il fonctionne
avec des certificats et une clé qui permet d'ouvrir un keychain qui
contient la clé privée du certificat (je schématise).
Sinon, en entreprise il suffit de ne pas mettre les utilisateurs en
admin de leur poste, il faut le mot de passe de l'admin de la machine
pour activer FileVault sur un compte (Préférence système Sécurité).
Quant au chiffrement des image-disques de Mac OS X c'est de l'AES-128
pour les curieux.
--
Politically Correct Unix - UTILITIES
The "touch" command has been removed from the standard distribution due
to its inappropriate use by high-level managers.
pour le cas particulier de FileVault, il existe un mot de passe admin, en plus du mot de passe utilisateur, qu'il est fortement conseillé de régler, car il permet (si mes souvenirs sont bons) la récupération d'un fichier filevault si l'utilisateur à perdu son pass. Laurent (P.) me corrigera si je m'égare, je n'ai jamais utilisé Filevault.
Oui, le "mot de passe maître" appelé aussi "safety net". Il fonctionne avec des certificats et une clé qui permet d'ouvrir un keychain qui contient la clé privée du certificat (je schématise).
Sinon, en entreprise il suffit de ne pas mettre les utilisateurs en admin de leur poste, il faut le mot de passe de l'admin de la machine pour activer FileVault sur un compte (Préférence système Sécurité).
Quant au chiffrement des image-disques de Mac OS X c'est de l'AES-128 pour les curieux.
-- Politically Correct Unix - UTILITIES The "touch" command has been removed from the standard distribution due to its inappropriate use by high-level managers.
