Bonjour,
Avec un Macbook pro rétina (écran 13") sous macOS 10.14.1, qui a un SSD
de 128 Go, j'avais sans cesse des messages du genre "disque presque
saturé, faites de la place". Du coup, j'achète un SSD de 256 Go (j'avais
exposé ici mes soucis dûs à un pb matériel).
Mais voilà-t-y pas que les messages "disque saturé, faites de la place"
reviennent...
Un Pomme -i sur le disque dur indique :
- une capacité de 239,85 Go,
- 222,62 Go utilisés,
- 10,61 Go libres (49 Ko purgeable)
Comment se fait-il que 120 Go aient été occupés en qq jours ? Je n'ai
rien ramené de volumineux par rapport à "avant" (le changement de SSD).
Les sauvegardes automatiques de Time Machnine sont désactivées.
Du cache qui se remplit à grande vitesse ? Mais même avec un SSD de 1
To, j'aurais ces messages aussi ?
Le cache du navigateur Opéra est limité à qq Go.
Je suis sous HSierra 10.13.3 sous sa forme la plus standard qui soit (SIP enabled etc.)
J'abandonne car tu n'as même pas le respect de lire et compendre les réponses qui te sont faites.
Ok, on arrête, mais sois bien certain que je lis tout, teste en long et en large et ne demande qu'à apprendre. Afficher ma nullité en public ne me gêne en rien à condition d'en apprendre quelque chose. Ne pas savoir n'est pas une tare, on apprend ça très vite quand on côtoie le milieu de la recherche. Au final, tout ce cirque parce que entre 13.3 et 13.6, Apple a changé le comportement de diskutil : très très fort ! Y'a un saint patron ou une sainte patronne des développeurs Apple ? Les pauvres, ils en ont besoin, grand besoin.
In article <ptmrlv$sha$2@dont-email.me>, Matt <matt@lv426.eu.invalid>
wrote:
> Je suis sous HSierra 10.13.3 sous sa forme la plus standard qui soit
> (SIP enabled etc.)
J'abandonne car tu n'as même pas le respect de lire et compendre les
réponses qui te sont faites.
Ok, on arrête, mais sois bien certain que je lis tout, teste en long et
en large et ne demande qu'à apprendre.
Afficher ma nullité en public ne me gêne en rien à condition d'en
apprendre quelque chose.
Ne pas savoir n'est pas une tare, on apprend ça très vite quand on
côtoie le milieu de la recherche.
Au final, tout ce cirque parce que entre 13.3 et 13.6, Apple a changé le
comportement de diskutil : très très fort !
Y'a un saint patron ou une sainte patronne des développeurs Apple ?
Les pauvres, ils en ont besoin, grand besoin.
Je suis sous HSierra 10.13.3 sous sa forme la plus standard qui soit (SIP enabled etc.)
J'abandonne car tu n'as même pas le respect de lire et compendre les réponses qui te sont faites.
Ok, on arrête, mais sois bien certain que je lis tout, teste en long et en large et ne demande qu'à apprendre. Afficher ma nullité en public ne me gêne en rien à condition d'en apprendre quelque chose. Ne pas savoir n'est pas une tare, on apprend ça très vite quand on côtoie le milieu de la recherche. Au final, tout ce cirque parce que entre 13.3 et 13.6, Apple a changé le comportement de diskutil : très très fort ! Y'a un saint patron ou une sainte patronne des développeurs Apple ? Les pauvres, ils en ont besoin, grand besoin.
Matt
On Mer 28 novembre 2018 (22:04), JPP wrote:
Alors, merci du conseil, mais non je ne mets pas HSierra à jour et continue de voir ce que fais Mojave (uptodate) dans une machine virtuelle, jetable au cas où. C'est ce que faisait mon responsable sécurité à l'université avec les mises à jour Windows, avant de les mettre sur le serveur de distribution automatique, les postes individuels étant verrouillés contre toute mise à jour locale.
C'est une très bonne pratique et devient possible aisément grâce aux snapshots.
En passant, tu reconnaitras que pour une évolution mineure de l'OS, changer le comportement de commandes de base, c'est quand même un peu fort !
Oui très car bien documenter les choses c'est la base lorsque l'on fait de tels changements. Pondre des versions tous les ans ça n'est pas bon tout ça. -- Vicemaxx: On a la liberté d'expression, alors tais toi !!! ToXine: ... * bashfr.org
On Mer 28 novembre 2018 (22:04),
JPP <jpp@gmail.com> wrote:
Alors, merci du conseil, mais non je ne mets pas HSierra à jour et
continue de voir ce que fais Mojave (uptodate) dans une machine
virtuelle, jetable au cas où.
C'est ce que faisait mon responsable sécurité à l'université avec les
mises à jour Windows, avant de les mettre sur le serveur de distribution
automatique, les postes individuels étant verrouillés contre toute mise
à jour locale.
C'est une très bonne pratique et devient possible aisément grâce aux
snapshots.
En passant, tu reconnaitras que pour une évolution mineure de l'OS,
changer le comportement de commandes de base, c'est quand même un peu
fort !
Oui très car bien documenter les choses c'est la base lorsque l'on fait
de tels changements. Pondre des versions tous les ans ça n'est pas bon
tout ça.
--
Vicemaxx: On a la liberté d'expression, alors tais toi !!!
ToXine: ...
* bashfr.org
Alors, merci du conseil, mais non je ne mets pas HSierra à jour et continue de voir ce que fais Mojave (uptodate) dans une machine virtuelle, jetable au cas où. C'est ce que faisait mon responsable sécurité à l'université avec les mises à jour Windows, avant de les mettre sur le serveur de distribution automatique, les postes individuels étant verrouillés contre toute mise à jour locale.
C'est une très bonne pratique et devient possible aisément grâce aux snapshots.
En passant, tu reconnaitras que pour une évolution mineure de l'OS, changer le comportement de commandes de base, c'est quand même un peu fort !
Oui très car bien documenter les choses c'est la base lorsque l'on fait de tels changements. Pondre des versions tous les ans ça n'est pas bon tout ça. -- Vicemaxx: On a la liberté d'expression, alors tais toi !!! ToXine: ... * bashfr.org
JPP
In article <ptn0ug$tf5$, Matt wrote:
Oui très car bien documenter les choses c'est la base lorsque l'on fait de tels changements
Petits ou grands changements, quand on publie ou met sur le marché quoi que ce soit, la doc se doit d'être finalisée. Au final, la doc n'est qu'une autre forme du cahier des charges détaillé sous sa forme ultime. Une doc mal ficelée laisse peser des doutes sérieux sur la clarté du cahier des charges. Ces problèm de documentation permettent aussi d'avoir une idée de l'ambiance dans les équipes de développement chez Apple, équipes dont on dit qu'elles sont extrêmement cloisonnées contrairement à l'ère S. Jobs.
In article <ptn0ug$tf5$1@dont-email.me>, Matt <matt@lv426.eu.invalid>
wrote:
Oui très car bien documenter les choses c'est la base lorsque l'on fait
de tels changements
Petits ou grands changements, quand on publie ou met sur le marché quoi
que ce soit, la doc se doit d'être finalisée.
Au final, la doc n'est qu'une autre forme du cahier des charges détaillé
sous sa forme ultime.
Une doc mal ficelée laisse peser des doutes sérieux sur la clarté du
cahier des charges.
Ces problèm de documentation permettent aussi d'avoir une idée de
l'ambiance dans les équipes de développement chez Apple, équipes dont on
dit qu'elles sont extrêmement cloisonnées contrairement à l'ère S. Jobs.
Oui très car bien documenter les choses c'est la base lorsque l'on fait de tels changements
Petits ou grands changements, quand on publie ou met sur le marché quoi que ce soit, la doc se doit d'être finalisée. Au final, la doc n'est qu'une autre forme du cahier des charges détaillé sous sa forme ultime. Une doc mal ficelée laisse peser des doutes sérieux sur la clarté du cahier des charges. Ces problèm de documentation permettent aussi d'avoir une idée de l'ambiance dans les équipes de développement chez Apple, équipes dont on dit qu'elles sont extrêmement cloisonnées contrairement à l'ère S. Jobs.
JPP
In article <ptn0ug$tf5$, Matt wrote:
Oui très car bien documenter les choses c'est la base lorsque l'on fait de tels changements
Petits ou grands changements, quand on publie ou met sur le marché quoi que ce soit, la doc se doit d'être finalisée. Au final, la doc n'est qu'une autre forme du cahier des charges détaillé sous sa forme ultime. Une doc mal ficelée laisse peser des doutes sérieux sur la clarté du cahier des charges. Ces problèmes de documentation permettent aussi d'avoir une idée de l'ambiance dans les équipes de développement chez Apple, équipes dont on dit qu'elles sont extrêmement cloisonnées contrairement à l'ère S. Jobs.
In article <ptn0ug$tf5$1@dont-email.me>, Matt <matt@lv426.eu.invalid>
wrote:
Oui très car bien documenter les choses c'est la base lorsque l'on fait
de tels changements
Petits ou grands changements, quand on publie ou met sur le marché quoi
que ce soit, la doc se doit d'être finalisée.
Au final, la doc n'est qu'une autre forme du cahier des charges détaillé
sous sa forme ultime.
Une doc mal ficelée laisse peser des doutes sérieux sur la clarté du
cahier des charges.
Ces problèmes de documentation permettent aussi d'avoir une idée de
l'ambiance dans les équipes de développement chez Apple, équipes dont on
dit qu'elles sont extrêmement cloisonnées contrairement à l'ère S. Jobs.
Oui très car bien documenter les choses c'est la base lorsque l'on fait de tels changements
Petits ou grands changements, quand on publie ou met sur le marché quoi que ce soit, la doc se doit d'être finalisée. Au final, la doc n'est qu'une autre forme du cahier des charges détaillé sous sa forme ultime. Une doc mal ficelée laisse peser des doutes sérieux sur la clarté du cahier des charges. Ces problèmes de documentation permettent aussi d'avoir une idée de l'ambiance dans les équipes de développement chez Apple, équipes dont on dit qu'elles sont extrêmement cloisonnées contrairement à l'ère S. Jobs.
g4fleurot
Matt a écrit ceci :
Je répondais à ceci : « (il n'y a pas besoin de créer un dossier snapshots au premier niveau du disque). »
Euh... ? ? ? ? -- Gérard FLEUROT plus un
Matt a écrit ceci :
Je répondais à ceci :
« (il n'y a pas besoin de créer un dossier snapshots au
premier niveau du disque). »
Euh... ? ? ? ?
--
Gérard FLEUROT <g4fleurot@free.fr> plus un
Je répondais à ceci : « (il n'y a pas besoin de créer un dossier snapshots au premier niveau du disque). »
Euh... ? ? ? ? -- Gérard FLEUROT plus un
g4fleurot
JPP a écrit ceci :
ce dossier et tous ces sous-dossiers ont une taille Zero bytes. C'est vraiment là que sont les snapshots ?
Ben, si je monte un snapshot (Macintosh ) dans ce dossier et que je fasse Pomme-I dessus et que je compare avec Pomme-I sur Macintosh HD, la différence de poids en octets correspond à la variation de poids entre les deux états. La capacité est la même (500,07 Go) Mais je pense que le snapshot indique une valeur "virtuelle" et que son poids réel (que l'on peut lire dans CCC) est la variation de poids entre les deux états. Mais en fait, je nage, c'est la grande brasse... Comme toi, j'essaie de comprendre tout en sachant que : Heureux celui qui a compris qu'il ne fallait pas chercher à comprendre. -- Gérard FLEUROT plus un
JPP a écrit ceci :
ce dossier et tous ces sous-dossiers ont une taille Zero bytes. C'est
vraiment là que sont les snapshots ?
Ben, si je monte un snapshot (Macintosh HD@snap-le_XID) dans ce dossier
et que je fasse Pomme-I dessus et que je compare avec Pomme-I sur
Macintosh HD, la différence de poids en octets correspond à la variation
de poids entre les deux états. La capacité est la même (500,07 Go)
Mais je pense que le snapshot indique une valeur "virtuelle" et que son
poids réel (que l'on peut lire dans CCC) est la variation de poids entre
les deux états.
Mais en fait, je nage, c'est la grande brasse...
Comme toi, j'essaie de comprendre tout en sachant que :
Heureux celui qui a compris qu'il ne fallait pas chercher à comprendre.
--
Gérard FLEUROT <g4fleurot@free.fr> plus un
ce dossier et tous ces sous-dossiers ont une taille Zero bytes. C'est vraiment là que sont les snapshots ?
Ben, si je monte un snapshot (Macintosh ) dans ce dossier et que je fasse Pomme-I dessus et que je compare avec Pomme-I sur Macintosh HD, la différence de poids en octets correspond à la variation de poids entre les deux états. La capacité est la même (500,07 Go) Mais je pense que le snapshot indique une valeur "virtuelle" et que son poids réel (que l'on peut lire dans CCC) est la variation de poids entre les deux états. Mais en fait, je nage, c'est la grande brasse... Comme toi, j'essaie de comprendre tout en sachant que : Heureux celui qui a compris qu'il ne fallait pas chercher à comprendre. -- Gérard FLEUROT plus un
JPP
In article <1nz0tmf.xe9ooc36ut4kN%, (Fleuger) wrote:
JPP a écrit ceci :
ce dossier et tous ces sous-dossiers ont une taille Zero bytes. C'est vraiment là que sont les snapshots ?
Ben, si je monte un snapshot (Macintosh ) dans ce dossier et que je fasse Pomme-I dessus et que je compare avec Pomme-I sur Macintosh HD, la différence de poids en octets correspond à la variation de poids entre les deux états. La capacité est la même (500,07 Go)
Si le poids du snapshot est le poids de quelque chose de réel (fichier, base de données Š) cela laisserait donc supposer que tu as un SSD interne d'au moins 1TB.
Mais je pense que le snapshot indique une valeur "virtuelle" et que son poids réel (que l'on peut lire dans CCC) est la variation de poids entre les deux états.
AMHA tout ceci n'est que base de données de pointeurs comme semble le montrer la version intermédiare snapshots APFS de 10.13.3 avec ses dossiers qui pèsent 0 octets.
Mais en fait, je nage, c'est la grande brasse... Comme toi, j'essaie de comprendre tout en sachant que : Heureux celui qui a compris qu'il ne fallait pas chercher à comprendre.
Oui, même que chercher à comprendre a suscité beaucoup d'inquiétude sur mon état de santé de la part de certains, hier. :-) Qu'ils soint rassurés, je vais beaucoup mieux Š
In article <1nz0tmf.xe9ooc36ut4kN%g4fleurot@free.fr>,
g4fleurot@free.fr (Fleuger) wrote:
JPP a écrit ceci :
> ce dossier et tous ces sous-dossiers ont une taille Zero bytes. C'est
> vraiment là que sont les snapshots ?
Ben, si je monte un snapshot (Macintosh HD@snap-le_XID) dans ce dossier
et que je fasse Pomme-I dessus et que je compare avec Pomme-I sur
Macintosh HD, la différence de poids en octets correspond à la variation
de poids entre les deux états. La capacité est la même (500,07 Go)
Si le poids du snapshot est le poids de quelque chose de réel (fichier,
base de données Š) cela laisserait donc supposer que tu as un SSD
interne d'au moins 1TB.
Mais je pense que le snapshot indique une valeur "virtuelle" et que son
poids réel (que l'on peut lire dans CCC) est la variation de poids entre
les deux états.
AMHA tout ceci n'est que base de données de pointeurs comme semble le
montrer la version intermédiare snapshots APFS de 10.13.3 avec ses
dossiers qui pèsent 0 octets.
Mais en fait, je nage, c'est la grande brasse...
Comme toi, j'essaie de comprendre tout en sachant que :
Heureux celui qui a compris qu'il ne fallait pas chercher à comprendre.
Oui, même que chercher à comprendre a suscité beaucoup d'inquiétude sur
mon état de santé de la part de certains, hier. :-)
In article <1nz0tmf.xe9ooc36ut4kN%, (Fleuger) wrote:
JPP a écrit ceci :
ce dossier et tous ces sous-dossiers ont une taille Zero bytes. C'est vraiment là que sont les snapshots ?
Ben, si je monte un snapshot (Macintosh ) dans ce dossier et que je fasse Pomme-I dessus et que je compare avec Pomme-I sur Macintosh HD, la différence de poids en octets correspond à la variation de poids entre les deux états. La capacité est la même (500,07 Go)
Si le poids du snapshot est le poids de quelque chose de réel (fichier, base de données Š) cela laisserait donc supposer que tu as un SSD interne d'au moins 1TB.
Mais je pense que le snapshot indique une valeur "virtuelle" et que son poids réel (que l'on peut lire dans CCC) est la variation de poids entre les deux états.
AMHA tout ceci n'est que base de données de pointeurs comme semble le montrer la version intermédiare snapshots APFS de 10.13.3 avec ses dossiers qui pèsent 0 octets.
Mais en fait, je nage, c'est la grande brasse... Comme toi, j'essaie de comprendre tout en sachant que : Heureux celui qui a compris qu'il ne fallait pas chercher à comprendre.
Oui, même que chercher à comprendre a suscité beaucoup d'inquiétude sur mon état de santé de la part de certains, hier. :-) Qu'ils soint rassurés, je vais beaucoup mieux Š
JPP
In article <ptokso$2nt$, Matt wrote:
Le snapshots contient les pointeurs vers les fichiers de la source.
Vers les blocs physiques des dits-fichiers ? Si le snapshot n'enregistre que les modifications, il doit y avoir quelque part un original, un enregistrement initial de tout le système. Où est-il ?
In article <ptokso$2nt$1@dont-email.me>, Matt <matt@lv426.eu.invalid>
wrote:
Le snapshots contient les pointeurs vers les fichiers de la source.
Vers les blocs physiques des dits-fichiers ?
Si le snapshot n'enregistre que les modifications, il doit y avoir
quelque part un original, un enregistrement initial de tout le système.
Où est-il ?
Le snapshots contient les pointeurs vers les fichiers de la source.
Vers les blocs physiques des dits-fichiers ? Si le snapshot n'enregistre que les modifications, il doit y avoir quelque part un original, un enregistrement initial de tout le système. Où est-il ?
Matt
On Jeu 29 novembre 2018 (09:59), Fleuger wrote:
Ben, si je monte un snapshot (Macintosh ) dans ce dossier et que je fasse Pomme-I dessus et que je compare avec Pomme-I sur Macintosh HD, la différence de poids en octets correspond à la variation de poids entre les deux états. La capacité est la même (500,07 Go) Mais je pense que le snapshot indique une valeur "virtuelle" et que son poids réel (que l'on peut lire dans CCC) est la variation de poids entre les deux états.
Tout à fait. Le snapshots contient les pointeurs vers les fichiers de la source. - Si le fichier source est modifié, seules les données ajoutées sont stockées dans le prochain snapshot (partie donnée et métadonnée). - Si le fichier est supprimé de la source, données et métadonnées sont ajoutées au(x) snapshot(s) contenant un pointeur vers le dit-fichier. Rien de magique/vaudou là-dedans. Les snapshots permettent de retrouver le système et les fichiers à l'instant T où ce snapshot a été créé.
Mais en fait, je nage, c'est la grande brasse... Comme toi, j'essaie de comprendre tout en sachant que : Heureux celui qui a compris qu'il ne fallait pas chercher à comprendre.
C'est quelque chose de nouveau pour les Macounets, c'est normal que ce soi déroutant pour ceux et celles n'ayant jamais utilisé de système de fichiers tel que Btrfs, ZFS, etc. -- <Nayanea> ben tu sais y a ceux qui assument et... les autres!! * ManOnDaMoon fait partie des autres, et il l'assume ! * bashfr.org
On Jeu 29 novembre 2018 (09:59),
Fleuger <g4fleurot@free.fr> wrote:
Ben, si je monte un snapshot (Macintosh HD@snap-le_XID) dans ce dossier
et que je fasse Pomme-I dessus et que je compare avec Pomme-I sur
Macintosh HD, la différence de poids en octets correspond à la variation
de poids entre les deux états. La capacité est la même (500,07 Go)
Mais je pense que le snapshot indique une valeur "virtuelle" et que son
poids réel (que l'on peut lire dans CCC) est la variation de poids entre
les deux états.
Tout à fait.
Le snapshots contient les pointeurs vers les fichiers de la source.
- Si le fichier source est modifié, seules les données ajoutées sont
stockées dans le prochain snapshot (partie donnée et métadonnée).
- Si le fichier est supprimé de la source, données et métadonnées sont
ajoutées au(x) snapshot(s) contenant un pointeur vers le dit-fichier.
Rien de magique/vaudou là-dedans. Les snapshots permettent de retrouver
le système et les fichiers à l'instant T où ce snapshot a été créé.
Mais en fait, je nage, c'est la grande brasse...
Comme toi, j'essaie de comprendre tout en sachant que :
Heureux celui qui a compris qu'il ne fallait pas chercher à comprendre.
C'est quelque chose de nouveau pour les Macounets, c'est normal que ce
soi déroutant pour ceux et celles n'ayant jamais utilisé de système de
fichiers tel que Btrfs, ZFS, etc.
--
<Nayanea> ben tu sais y a ceux qui assument et... les autres!!
* ManOnDaMoon fait partie des autres, et il l'assume !
* bashfr.org
Ben, si je monte un snapshot (Macintosh ) dans ce dossier et que je fasse Pomme-I dessus et que je compare avec Pomme-I sur Macintosh HD, la différence de poids en octets correspond à la variation de poids entre les deux états. La capacité est la même (500,07 Go) Mais je pense que le snapshot indique une valeur "virtuelle" et que son poids réel (que l'on peut lire dans CCC) est la variation de poids entre les deux états.
Tout à fait. Le snapshots contient les pointeurs vers les fichiers de la source. - Si le fichier source est modifié, seules les données ajoutées sont stockées dans le prochain snapshot (partie donnée et métadonnée). - Si le fichier est supprimé de la source, données et métadonnées sont ajoutées au(x) snapshot(s) contenant un pointeur vers le dit-fichier. Rien de magique/vaudou là-dedans. Les snapshots permettent de retrouver le système et les fichiers à l'instant T où ce snapshot a été créé.
Mais en fait, je nage, c'est la grande brasse... Comme toi, j'essaie de comprendre tout en sachant que : Heureux celui qui a compris qu'il ne fallait pas chercher à comprendre.
C'est quelque chose de nouveau pour les Macounets, c'est normal que ce soi déroutant pour ceux et celles n'ayant jamais utilisé de système de fichiers tel que Btrfs, ZFS, etc. -- <Nayanea> ben tu sais y a ceux qui assument et... les autres!! * ManOnDaMoon fait partie des autres, et il l'assume ! * bashfr.org
Le Moustique
Le 29/11/2018 à 13:08, Matt a écrit :
- Si le fichier source est modifié, seules les données ajoutées sont stockées dans le prochain snapshot (partie donnée et métadonnée).
OK, mais quid de la partie supprimée du fichier? Elle reste en "cache"? Ca peut représenter pas mal de Ko...voire de Mo.
- Si le fichier est supprimé de la source, données et métadonnées sont ajoutées au(x) snapshot(s) contenant un pointeur vers le dit-fichier.
Là encore, je m'interroge : si le fichier est supprimé, le pointeur correspondant devrait lui aussi être supprimé? Sinon on pourrait récupérer un fichier mis à la corbeille /après/ que la corbeille ait été vidée... Autrement dit, y'a plus de suppression de fichier. C'est comme si on ne pouvait pas supprimer l'historique de son navigateur... -- /) -:oo= Guillaume ) Je nettoyais mon clavier, et le coup est parti tout seul.
Le 29/11/2018 à 13:08, Matt a écrit :
- Si le fichier source est modifié, seules les données ajoutées sont
stockées dans le prochain snapshot (partie donnée et métadonnée).
OK, mais quid de la partie supprimée du fichier? Elle reste en "cache"?
Ca peut représenter pas mal de Ko...voire de Mo.
- Si le fichier est supprimé de la source, données et métadonnées sont
ajoutées au(x) snapshot(s) contenant un pointeur vers le dit-fichier.
Là encore, je m'interroge : si le fichier est supprimé, le pointeur
correspondant devrait lui aussi être supprimé? Sinon on pourrait
récupérer un fichier mis à la corbeille /après/ que la corbeille ait été
vidée... Autrement dit, y'a plus de suppression de fichier. C'est comme
si on ne pouvait pas supprimer l'historique de son navigateur...
--
/)
-:oo= Guillaume
)
Je nettoyais mon clavier, et le coup est parti tout seul.
- Si le fichier source est modifié, seules les données ajoutées sont stockées dans le prochain snapshot (partie donnée et métadonnée).
OK, mais quid de la partie supprimée du fichier? Elle reste en "cache"? Ca peut représenter pas mal de Ko...voire de Mo.
- Si le fichier est supprimé de la source, données et métadonnées sont ajoutées au(x) snapshot(s) contenant un pointeur vers le dit-fichier.
Là encore, je m'interroge : si le fichier est supprimé, le pointeur correspondant devrait lui aussi être supprimé? Sinon on pourrait récupérer un fichier mis à la corbeille /après/ que la corbeille ait été vidée... Autrement dit, y'a plus de suppression de fichier. C'est comme si on ne pouvait pas supprimer l'historique de son navigateur... -- /) -:oo= Guillaume ) Je nettoyais mon clavier, et le coup est parti tout seul.
