Ce qui est bizarre dans l'histoire c'est que les fichiers ou répertoires
cachés crées sous Linux ne sont pas cachés sous Windows. (on voit
le .fichiers...)
Et les fichiers ou répertoires cachés crées sous Windows ne sont pas cachés
sous Linux?!?
Ce sont les utilitaires de listage qui appliquent par défaut un filtre, et non le système (de fichier ou d'exploitation) qui empeche les utilitaires de lire les fichiers en question (par un systeme quelconque de permission).
C'est comme cela que je comprends les choses.
Parfaitement exact.
R12y wrote in message <g5kpob$810$1@cabale.usenet-fr.net>:
Ce sont les utilitaires de listage qui appliquent par défaut un filtre,
et non le système (de fichier ou d'exploitation) qui empeche les
utilitaires de lire les fichiers en question (par un systeme quelconque
de permission).
Ce sont les utilitaires de listage qui appliquent par défaut un filtre, et non le système (de fichier ou d'exploitation) qui empeche les utilitaires de lire les fichiers en question (par un systeme quelconque de permission).
C'est comme cela que je comprends les choses.
Parfaitement exact.
Luc.Habert.00__arjf
Nicolas George :
C'est comme cela que je comprends les choses.
Parfaitement exact.
Comment sais-tu qu'il est parfaitement exact que c'est comme ça qu'il comprend les choses?
Nicolas George :
C'est comme cela que je comprends les choses.
Parfaitement exact.
Comment sais-tu qu'il est parfaitement exact que c'est comme ça qu'il
comprend les choses?
Comment sais-tu qu'il est parfaitement exact que c'est comme ça qu'il comprend les choses?
Voyons, Luc... :-) Pour une fois que je n'ai pas dit trop de conneries, on pourrait finir sur un sourire...
Nicolas S.
Fabien LE LEZ a écrit:
On Wed, 16 Jul 2008 02:46:35 +0200, "Nicolas S." :
>> le caractère "." était un séparateur entre >> le nom du fichier et l'extension, et non pas un caractère >> quelconque du nom du fichier comme sous UNIX... Donc impossible de >> prendre la même convention > >L'un n'empêche pas l'autre : les fichiers cachés sont ceux dont le >nom /commence/ par un point.
Dans la logique DOS (un nom de huit caractères maximum + une extension optionnelle), ça n'a pas de sens : si un nom de fichier commençait par un point, ça voudrait dire qu'il n'a pas de nom, juste une extension. (Même aujourd'hui, l'explorateur Windows râle un brin si on veut créer un fichier avec un nom qui commence par un point, avec le message "Vous devez spécifier un nom de fichier.")
C'est que Windows est limité. Rien n'empêchait d'implémenter les fichiers cachés à la façon Unix ; à condition de traiter correctement le cas particulier où le nom du fichier est vide. Rien n'empêche d'avoir deux significations possibles pour le caractère point en fonction de sa place dans le nom.
Bref, ce n'est très certainement pas cette explication qui explique les différentes implémentations.
-- Nicolas S.
Fabien LE LEZ a écrit:
On Wed, 16 Jul 2008 02:46:35 +0200, "Nicolas S."
<ni.s-factice@laposte.net.invalid>:
>> le caractère "." était un séparateur entre
>> le nom du fichier et l'extension, et non pas un caractère
>> quelconque du nom du fichier comme sous UNIX... Donc impossible de
>> prendre la même convention
>
>L'un n'empêche pas l'autre : les fichiers cachés sont ceux dont le
>nom /commence/ par un point.
Dans la logique DOS (un nom de huit caractères maximum + une extension
optionnelle), ça n'a pas de sens : si un nom de fichier commençait par
un point, ça voudrait dire qu'il n'a pas de nom, juste une extension.
(Même aujourd'hui, l'explorateur Windows râle un brin si on veut créer
un fichier avec un nom qui commence par un point, avec le message
"Vous devez spécifier un nom de fichier.")
C'est que Windows est limité. Rien n'empêchait d'implémenter les
fichiers cachés à la façon Unix ; à condition de traiter correctement le
cas particulier où le nom du fichier est vide.
Rien n'empêche d'avoir deux significations possibles pour le caractère
point en fonction de sa place dans le nom.
Bref, ce n'est très certainement pas cette explication qui explique les
différentes implémentations.
On Wed, 16 Jul 2008 02:46:35 +0200, "Nicolas S." :
>> le caractère "." était un séparateur entre >> le nom du fichier et l'extension, et non pas un caractère >> quelconque du nom du fichier comme sous UNIX... Donc impossible de >> prendre la même convention > >L'un n'empêche pas l'autre : les fichiers cachés sont ceux dont le >nom /commence/ par un point.
Dans la logique DOS (un nom de huit caractères maximum + une extension optionnelle), ça n'a pas de sens : si un nom de fichier commençait par un point, ça voudrait dire qu'il n'a pas de nom, juste une extension. (Même aujourd'hui, l'explorateur Windows râle un brin si on veut créer un fichier avec un nom qui commence par un point, avec le message "Vous devez spécifier un nom de fichier.")
C'est que Windows est limité. Rien n'empêchait d'implémenter les fichiers cachés à la façon Unix ; à condition de traiter correctement le cas particulier où le nom du fichier est vide. Rien n'empêche d'avoir deux significations possibles pour le caractère point en fonction de sa place dans le nom.
Bref, ce n'est très certainement pas cette explication qui explique les différentes implémentations.
-- Nicolas S.
Nicolas S.
YBM a écrit:
Nicolas S. a écrit : > YBM a écrit: > >> le caractère "." était un séparateur entre >> le nom du fichier et l'extension, et non pas un caractère >> quelconque du nom du fichier comme sous UNIX... Donc impossible de >> prendre la même convention > > L'un n'empêche pas l'autre : les fichiers cachés sont ceux dont le > nom /commence/ par un point.
Oui, justement !
Justement quoi ?
-- Nicolas S.
YBM a écrit:
Nicolas S. a écrit :
> YBM a écrit:
>
>> le caractère "." était un séparateur entre
>> le nom du fichier et l'extension, et non pas un caractère
>> quelconque du nom du fichier comme sous UNIX... Donc impossible de
>> prendre la même convention
>
> L'un n'empêche pas l'autre : les fichiers cachés sont ceux dont le
> nom /commence/ par un point.
Nicolas S. a écrit : > YBM a écrit: > >> le caractère "." était un séparateur entre >> le nom du fichier et l'extension, et non pas un caractère >> quelconque du nom du fichier comme sous UNIX... Donc impossible de >> prendre la même convention > > L'un n'empêche pas l'autre : les fichiers cachés sont ceux dont le > nom /commence/ par un point.
Oui, justement !
Justement quoi ?
-- Nicolas S.
Nicolas S.
YBM a écrit:
Le point de départ est FAT, où "caché" a été implémenté comme attribut
On est d'accord, on parle de ce qui était aussi possible.
la convention unix ne pouvant être raisonnablement prise (sinon seul des fichiers .xxx auraient pu être "cachés")
Non. On aurait très bien pu avoir une implémentation qui suive le masque suivant :
[.]nom_du_fichier.extension
Le seul motif optionnel étant le premier point.
Vous auriez voulu quoi ? Qu'il supporte deux façon de "cacher" un fichier ?
Non. Je dis juste que DOS pouvait garder le même mécanisme que Unix pour cacher les fichiers sans que ça ne gêne vraiment l'autre mécanisme « nom + . + extension ».
Où alors c'est juste que c'est un sport pour vous de venir enc***r les mouches ?
Je suis en train de te dire qu'ils ont fait des choix d'implémentation et que, contrairement à ce que tu penses, ceux-ci auraient pu être compatibles Unix même en gardant le système de nommage avec « .extension ». Ce n'est donc pas ça qui explique l'implémentation sous forme d'attribut.
-- Nicolas S.
YBM a écrit:
Le point de départ est FAT, où
"caché" a été implémenté comme attribut
On est d'accord, on parle de ce qui était aussi possible.
la convention unix ne
pouvant être raisonnablement prise (sinon seul des fichiers .xxx
auraient pu être "cachés")
Non. On aurait très bien pu avoir une implémentation qui suive le masque
suivant :
[.]nom_du_fichier.extension
Le seul motif optionnel étant le premier point.
Vous auriez
voulu quoi ? Qu'il supporte deux façon de "cacher" un fichier ?
Non. Je dis juste que DOS pouvait garder le même mécanisme que Unix
pour cacher les fichiers sans que ça ne gêne vraiment l'autre mécanisme
« nom + . + extension ».
Où alors c'est juste que c'est un sport pour vous de venir
enc***r les mouches ?
Je suis en train de te dire qu'ils ont fait des choix d'implémentation
et que, contrairement à ce que tu penses, ceux-ci auraient pu être
compatibles Unix même en gardant le système de nommage avec
« .extension ». Ce n'est donc pas ça qui explique l'implémentation sous
forme d'attribut.
Le point de départ est FAT, où "caché" a été implémenté comme attribut
On est d'accord, on parle de ce qui était aussi possible.
la convention unix ne pouvant être raisonnablement prise (sinon seul des fichiers .xxx auraient pu être "cachés")
Non. On aurait très bien pu avoir une implémentation qui suive le masque suivant :
[.]nom_du_fichier.extension
Le seul motif optionnel étant le premier point.
Vous auriez voulu quoi ? Qu'il supporte deux façon de "cacher" un fichier ?
Non. Je dis juste que DOS pouvait garder le même mécanisme que Unix pour cacher les fichiers sans que ça ne gêne vraiment l'autre mécanisme « nom + . + extension ».
Où alors c'est juste que c'est un sport pour vous de venir enc***r les mouches ?
Je suis en train de te dire qu'ils ont fait des choix d'implémentation et que, contrairement à ce que tu penses, ceux-ci auraient pu être compatibles Unix même en gardant le système de nommage avec « .extension ». Ce n'est donc pas ça qui explique l'implémentation sous forme d'attribut.
Donc, comme dit YBM faut parler d'attribut de fichiers pour les fichier cachés. Bon, merci pour cette discussion très instructive, même si pour l'instant il me reste quelques blancs à remplir. Ce qui prouve qu'informaticien est quand même un métier.
-- @+ gr
Mihamina Rakotomandimby (R12y) wrote:
C'est comme cela que je comprends les choses.
(Je vois seulement maintenant cette discussion.)
Donc, comme dit YBM faut parler d'attribut de fichiers pour les fichier
cachés.
Bon, merci pour cette discussion très instructive, même si pour l'instant il
me reste quelques blancs à remplir.
Ce qui prouve qu'informaticien est quand même un métier.
Donc, comme dit YBM faut parler d'attribut de fichiers pour les fichier cachés. Bon, merci pour cette discussion très instructive, même si pour l'instant il me reste quelques blancs à remplir. Ce qui prouve qu'informaticien est quand même un métier.
