License.exe invisible sur CDROM !

Le 09/04/2008 08:46, Eric.beaumard@free.fr a écrit :

Bonjour,

J'ai à installer un programme sur W98. Sur mon portable sous XP
l'installation ne pose pas de pb. L'installateur teste
sur le CDROM dans le répertoire "Data" la présence d'un fichier
nommé "license.exe" et en son absence en déduit que l'installation
se fait en mode démo. Ce n'est pas mon cas, le dit fichier est
parfaitement visible sous XP et j'ai déjà installé ce soft sous
XP sans problème (la license est une licence établissement).
Mais sous W98, le soft se met en mode démo et de fait,
le fichier n'existe pas dans "DATA" sur le CDROM (il existe
quand je le scanne sous XP !!)...
J'ai changé les modes d'affichages des répertoires
(extension visible ou pas, fichiers cachés visible ou pas etc.)
sans effet. Comment est-il possible qu'un fichier soit
visible sous XP et pas sous W98 sur un CD ?

Y a-t-il des mécanismes de masquages de fichiers
portant des noms spéciaux sous W98 ?

Cordialement

Jette un coup d'oeuil à ton CD avec ISOBuster, histoire de voir si il
n'a pas plusieurs "systemes de fichiers", pour le détail ..je ne l'ai
plus en tête, mais entre ISO, Joliet, UDF, etc ... Win98 et XP ne
prennent pas le même FS par defaut pour lire un CD qui présente
plusieurs FS ..ça peut être ça ton pb.

Ou alors, un truc un peu con genre un cD gravé multi-session d'une façon
que l'un prend tout et l'autre 1 seule session ...

--
@+
Ascadix
adresse @mail valide, mais ajoutez "sesame" dans l'objet pour que ça
arrive.

Ascadix a écrit :

Le 09/04/2008 08:46, Eric.beaumard@free.fr a écrit :

Bonjour,

J'ai à installer un programme sur W98. Sur mon portable sous XP
l'installation ne pose pas de pb. L'installateur teste
sur le CDROM dans le répertoire "Data" la présence d'un fichier
nommé "license.exe" et en son absence en déduit que l'installation
se fait en mode démo. Ce n'est pas mon cas, le dit fichier est
parfaitement visible sous XP et j'ai déjà installé ce soft sous
XP sans problème (la license est une licence établissement).
Mais sous W98, le soft se met en mode démo et de fait,
le fichier n'existe pas dans "DATA" sur le CDROM (il existe
quand je le scanne sous XP !!)...
J'ai changé les modes d'affichages des répertoires
(extension visible ou pas, fichiers cachés visible ou pas etc.)
sans effet. Comment est-il possible qu'un fichier soit
visible sous XP et pas sous W98 sur un CD ?

Y a-t-il des mécanismes de masquages de fichiers
portant des noms spéciaux sous W98 ?

Cordialement

Jette un coup d'oeuil à ton CD avec ISOBuster, histoire de voir si il
n'a pas plusieurs "systemes de fichiers", pour le détail ..je ne l'ai
plus en tête, mais entre ISO, Joliet, UDF, etc ... Win98 et XP ne
prennent pas le même FS par defaut pour lire un CD qui présente
plusieurs FS ..ça peut être ça ton pb.

Ou alors, un truc un peu con genre un cD gravé multi-session d'une façon
que l'un prend tout et l'autre 1 seule session ...

peut-être aussi par le jeu d'un "lien symbolique", enfin sous *ix on
dirait comme-ça... Je crois que Xp a quelque-chose dans ce genre (en
moins bien, et nommé autrement, hé, forcément !!;-)

mais +1 pour isobuster ;-)

markorki a écrit :

[...]

Ou alors, un truc un peu con genre un cD gravé multi-session d'une
façon que l'un prend tout et l'autre 1 seule session ...

peut-être aussi par le jeu d'un "lien symbolique", enfin sous *ix on
dirait comme-ça... Je crois que Xp a quelque-chose dans ce genre (en
moins bien, et nommé autrement, hé, forcément !!;-)

Hum, ce serait intéressant que tu développe cet histoire de lien
symbolique sur CD vu que c'est d'aprés toi moins bien sous Xp.

Michel_D a écrit :

markorki a écrit :

[...]

Ou alors, un truc un peu con genre un cD gravé multi-session d'une
façon que l'un prend tout et l'autre 1 seule session ...

peut-être aussi par le jeu d'un "lien symbolique", enfin sous *ix on
dirait comme-ça... Je crois que Xp a quelque-chose dans ce genre (en
moins bien, et nommé autrement, hé, forcément !!;-)

Hum, ce serait intéressant que tu développe cet histoire de lien
symbolique sur CD vu que c'est d'aprés toi moins bien sous Xp.

Je développe, mais sur l'aspect Windows, je suis loin d'être très sûr de
moi (sauf pour les dll, au moins jusqu'à W2000 ;-)

Or donc, lien symbolique ...

Sous les *unix (et ce depuis... la fin des années 70 ?), on a la notion
de "lien symbolique", c'est-à-dire qu'un fichier peut être référencé
sous plusieurs chemins d'accès.
Il y a le chemin "canonique" : chemin sous lequel le fichier est créé,
éventuelleemnt par copie d'un autre, peu importe, l'important est que
ces octets, situés à tel endroit dans le système de fichiers (en fait
débutant à tel inode, c'est-à-dire dont le premier secteur est à tel
endroit, référencé par telle entrée de catalogue, les groupes de
secteurs étant ensuite chainés) , ont été catalogiées une première fois
sous ce nom par exemple /users/markorki/newfile.

Après, pour arranger certains utilisateurs, certaines applis ou rendre
des changements de version transparents, ou mettre un batch (en Unix,
c'est shell-script) d'adaptation "en tête" (chose impossible sous
windows où un bat et un exe ne sont pas interchangeables) de façon à ce
qu'un utilisateur ne voie pas une "rustine", on peut accéder à newfile
par des tas d'autres chemins, en utilisant la commande ln "lien" qui
sert à dire au système "le fichier /users/markorki/newfile, je voudrais
qu'il soit aussi connu comme /users/devinezqui/nf_in_disguise.
et on peut créer des tas d'autres noms comme-ça, avec des nuances de
comportement selon les options de création, mais le fichier **existe**
toujours dans le fs tant qu'on n'a pas supprimé tous ses chemins
d'accès, et c'est automatique, l' "inode" possède un compteur de
références d'accès, et quel que soit l'ordre de "suppression" des
différents chemins, le fichier est **effectivement** supprimé quand on a
effacé toutes ses références. Exactement comme une bibliothèque partagée
sous Unix a un compteur de process utilisateurs et est supprimée de la
mémoire si et seulement si le nombre de process utilisateurs passe à
zéro, contrairement à une dll sous Zindoz qui entre en mémoire de façon
dynamique et en sort au tire-bouchon ou au pied de biche (enfin,
moyennant un outil ad-hoc à manier par un spécialiste).

Je sais qu'il y a depuis Xp un moyen d'avoir des "liens" un peu
analogues (ça a un autre nom) mais je suis loin d'être sûr que par
exemple on puisse supprimer les différents noms du fichier dans un ordre
quelconque ;-)

Si tu as un tel lien sur un CD, son format a surement été prévu pour
qu'il soit ignoré par les OS antérieurs sans les planter, et bien sûr XP
le voit .

markorki a écrit :

Michel_D a écrit :

markorki a écrit :

[...]

Ou alors, un truc un peu con genre un cD gravé multi-session d'une
façon que l'un prend tout et l'autre 1 seule session ...

peut-être aussi par le jeu d'un "lien symbolique", enfin sous *ix on
dirait comme-ça... Je crois que Xp a quelque-chose dans ce genre (en
moins bien, et nommé autrement, hé, forcément !!;-)

Hum, ce serait intéressant que tu développe cet histoire de lien
symbolique sur CD vu que c'est d'aprés toi moins bien sous Xp.

Je développe, mais sur l'aspect Windows, je suis loin d'être très sûr de
moi (sauf pour les dll, au moins jusqu'à W2000 ;-)

Or donc, lien symbolique ...

Sous les *unix (et ce depuis... la fin des années 70 ?), on a la notion
de "lien symbolique", c'est-à-dire qu'un fichier peut être référencé
sous plusieurs chemins d'accès.
Il y a le chemin "canonique" : chemin sous lequel le fichier est créé,
éventuelleemnt par copie d'un autre, peu importe, l'important est que
ces octets, situés à tel endroit dans le système de fichiers (en fait
débutant à tel inode, c'est-à-dire dont le premier secteur est à tel
endroit, référencé par telle entrée de catalogue, les groupes de
secteurs étant ensuite chainés) , ont été catalogiées une première fois
sous ce nom par exemple /users/markorki/newfile.

Après, pour arranger certains utilisateurs, certaines applis ou rendre
des changements de version transparents, ou mettre un batch (en Unix,
c'est shell-script) d'adaptation "en tête" (chose impossible sous
windows où un bat et un exe ne sont pas interchangeables) de façon à ce
qu'un utilisateur ne voie pas une "rustine", on peut accéder à newfile
par des tas d'autres chemins, en utilisant la commande ln "lien" qui
sert à dire au système "le fichier /users/markorki/newfile, je voudrais
qu'il soit aussi connu comme /users/devinezqui/nf_in_disguise.
et on peut créer des tas d'autres noms comme-ça, avec des nuances de
comportement selon les options de création, mais le fichier **existe**
toujours dans le fs tant qu'on n'a pas supprimé tous ses chemins
d'accès, et c'est automatique, l' "inode" possède un compteur de
références d'accès, et quel que soit l'ordre de "suppression" des
différents chemins, le fichier est **effectivement** supprimé quand on a
effacé toutes ses références. Exactement comme une bibliothèque partagée
sous Unix a un compteur de process utilisateurs et est supprimée de la
mémoire si et seulement si le nombre de process utilisateurs passe à
zéro, contrairement à une dll sous Zindoz qui entre en mémoire de façon
dynamique et en sort au tire-bouchon ou au pied de biche (enfin,
moyennant un outil ad-hoc à manier par un spécialiste).

Je sais qu'il y a depuis Xp un moyen d'avoir des "liens" un peu
analogues (ça a un autre nom) mais je suis loin d'être sûr que par
exemple on puisse supprimer les différents noms du fichier dans un ordre
quelconque ;-)

Si tu as un tel lien sur un CD, son format a surement été prévu pour
qu'il soit ignoré par les OS antérieurs sans les planter, et bien sûr XP
le voit .

Avant d'aller plus loin, quel est le format des données sur CD
compatible Xp et *ix et quel est son origine ?

Le 12/04/2008 12:54, markorki a écrit :

Michel_D a écrit :

markorki a écrit :

[...]

Ou alors, un truc un peu con genre un cD gravé multi-session d'une
façon que l'un prend tout et l'autre 1 seule session ...

peut-être aussi par le jeu d'un "lien symbolique", enfin sous *ix on
dirait comme-ça... Je crois que Xp a quelque-chose dans ce genre (en
moins bien, et nommé autrement, hé, forcément !!;-)

Hum, ce serait intéressant que tu développe cet histoire de lien
symbolique sur CD vu que c'est d'aprés toi moins bien sous Xp.

Je développe, mais sur l'aspect Windows, je suis loin d'être très sûr de
moi (sauf pour les dll, au moins jusqu'à W2000 ;-)

Or donc, lien symbolique ...

Sous les *unix (et ce depuis... la fin des années 70 ?), on a la notion
de "lien symbolique", c'est-à-dire qu'un fichier peut être référencé
sous plusieurs chemins d'accès.
Il y a le chemin "canonique" : chemin sous lequel le fichier est créé,
éventuelleemnt par copie d'un autre, peu importe, l'important est que
ces octets, situés à tel endroit dans le système de fichiers (en fait
débutant à tel inode, c'est-à-dire dont le premier secteur est à tel
endroit, référencé par telle entrée de catalogue, les groupes de
secteurs étant ensuite chainés) , ont été catalogiées une première fois
sous ce nom par exemple /users/markorki/newfile.

>

Après, pour arranger certains utilisateurs, certaines applis ou rendre
des changements de version transparents, ou mettre un batch (en Unix,
c'est shell-script) d'adaptation "en tête" (chose impossible sous
windows où un bat et un exe ne sont pas interchangeables) de façon à ce
qu'un utilisateur ne voie pas une "rustine", on peut accéder à newfile
par des tas d'autres chemins, en utilisant la commande ln "lien" qui
sert à dire au système "le fichier /users/markorki/newfile, je voudrais
qu'il soit aussi connu comme /users/devinezqui/nf_in_disguise.
et on peut créer des tas d'autres noms comme-ça, avec des nuances de
comportement selon les options de création, mais le fichier **existe**
toujours dans le fs tant qu'on n'a pas supprimé tous ses chemins
d'accès, et c'est automatique, l' "inode" possède un compteur de
références d'accès, et quel que soit l'ordre de "suppression" des
différents chemins, le fichier est **effectivement** supprimé quand on a
effacé toutes ses références.

ça dépend de l'OS et du FS.
Sous DOS Win9x ..que dalle.
Sur FAT ..que dalle
Sous NTx, on peut avoir ça depuis NT4 sur NTFS ..sauf que ya pas
d'outils fourni avec l'OS pour le faire ( mais les API sont dispo pour
les dev. )
Sopus W2k ..je sais plus trop
Sous XP, t'as FSUTIL qui est intégré ( FSUTIL hardlink create ...)


> Exactement comme une bibliothèque partagée

sous Unix a un compteur de process utilisateurs et est supprimée de la
mémoire si et seulement si le nombre de process utilisateurs passe à
zéro, contrairement à une dll sous Zindoz qui entre en mémoire de façon
dynamique et en sort au tire-bouchon ou au pied de biche (enfin,
moyennant un outil ad-hoc à manier par un spécialiste).

Là ..j'veut bien que tu développe ....
à part le fait que par defaut 2k/XP gardent la DLL en cache qq temps
après que son compteur de vie soit passé à 0, je voit pas trop ou est le
tire-bouchon. Ce comportement est là pour améliorer les perfs vu un bon
nombre de DLL sont très souvent sollicité, ça évite de les relire à
chaque fois si elle sont encore dans le "cache DLL".
Si ce comportement te gène ( pour les dev par ex, il suffit de
désactiver cette option pour que la DLL soit évacuée immédiatement dés
que son compteur est à 0.

Je sais qu'il y a depuis Xp un moyen d'avoir des "liens" un peu
analogues (ça a un autre nom) mais je suis loin d'être sûr que par
exemple on puisse supprimer les différents noms du fichier dans un ordre
quelconque ;-)

hardlink

FSUTIL hardlink create "nom_nouveau_lien" "nom_lien_existant"

Si tu as un tel lien sur un CD, son format a surement été prévu pour
qu'il soit ignoré par les OS antérieurs sans les planter, et bien sûr XP
le voit .

Sauf que sur CD c'est ni NTFS ni FAT ( ni ETXx je crois ) mais ISO,
Joliet, UDF, etc .... et tu peut déjà avec la plupart de ces FS générer
lors de la gravure un +/- lien, sauf que ça, à ma connaissance tout les
OS sachant lire le FS du CD verront tous les fichiers y compris ceux
"dédoublés".

La bidouille reste AMHA avis la présence de plusieurs FS sur le CD
chacun de ces "index" ne référençant pas tous les fichiers, et là
suivant le FS utilisé par défaut par chaque OS ...on voit un contenu
différent.

ISObuster reste AMHA un très bon test car il permet de voir chaque FS
séparément ..et éventuellement de comparer les fichiers référencé
respectivement pas chacun d'eux.

--
@+
Ascadix
adresse @mail valide, mais ajoutez "sesame" dans l'objet pour que ça
arrive.