Rechercher tous les fichiers d'un SID donné ?

Le
Jacques Perrocheau
Bonjour à tous,

J'ai une question, je ne suis pas un spécialiste de Windows. ;-)


Est-ce qu'il est possible de faire un script VBS pour rechercher et
lister sur un volume tous les fichiers et dossiers d'un SID donné (le
"truc" en S-1-5-21-1454471165-1004336348-1606980848-xxxx), si oui cela
a-t-il été déjà fait ?

Le but recherché est de "nettoyer" les ACL d'une installation "curieuse"
qui a laissé des fichiers ayant comme possesseur un utilisateur qui
n'existe plus sur la machine. Une partie ayant été fait "à la main" le
but en fait de rechercher les "fichiers oubliés".

Je n'ai pas trouvé là
<http://www.microsoft.com/technet/scriptcenter/default.mspx>, un peu
touffu pour moi, ni dans la cassette du sieur JC Bellamy
<http://www.bellamyjc.org/fr/vbsdownload.html>

D'avance merci.

P.S. suivi en fr.comp.os.ms-windows plus facile d'accès pour moi.

--
Jacques PERROCHEAU
CNRS UMR 6226
Université de Rennes 1, Campus de Beaulieu, 35042 RENNES Cedex, France
Vos réponses Page 2 / 4
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Pierre TORRIS
Le #16360341
Jacques Perrocheau message

In article Pierre TORRIS
Comme toute commande, il faut qu'elle soit présente dans un dossier du
PATH afin que le système puisse la retrouver et l'exécuter depuis
n'importe quel dossier.



??? Qu'est-ce "un dossier du PATH" ? C'est pour moi une étrange façon de
désigner la variable d'environnement, "PATH".



Ca ne désigne pas la variable en elle-même, mais son contenu !

La variable d'environnement "PATH" contient des noms de dossiers
(chemins complets). Chacun des chemins étant séparés par un point
virgule. Donc, un dossier du PATH est un dossier (chemin complet) qui
figure dans la variable d'environnement "PATH".

En invite de commandes, tapez (pour lister la contenu de la variable) :
path

Cela ne me dit pas où se trouve cet "icacls" qui si j'ai bien compris
existe quelque part sur le disque... et quel est la valeur de ce fameux
"PATH" à mettre.



Je parlais de commandes (exécutables) ajoutées.

"icacls" figure, dans mon Vista Ultimate, dans le dossier "system32".

Hors, ce dossier figure par défaut dans la variable "PATH". Si donc, le
fichier "icacls.exe" existe bien sur votre système dans le dossier
"system32", et que le chemin "%SystemRoot%system32" existe bien dans
la variable "PATH", c'est qu'il est fort probable que votre soucis
provienne du fait que le type de la variable "PATH" soit erroné dans le
Registre. Chose que cmdPATH peut résoudre au passage (voir ci-dessous).

Pourquoi donc des trucs existant dans une installation Windows ne sont
pas directement utilisables avec un minimum d'information comme la
lecture du help que bien évidemment je n'arrive pas aussi à faire
apparaître ?



Il faut aussi préciser qu'il y a différentes versions de Windows.
Toutes ne possèdent pas forcément les mêmes commandes de base.

Pourquoi diable faut-il mettre les mains dans le cambouis, avant
utilisation dès qu'on sort un peu de l'ordinaire ?



Il y a le système seul après son installation.
Et puis le système après moults installations tiers.

Vous pourriez par exemple utiliser cmdPATH qui permet de créer un
nouveau dossier et d'ajouter ce dossier à la variable PATH.



Je n'ai toujours pas bien saisi la finalité de ce que vous me proposez..
Visiblement le vocabulaire n'est pas le même dans les "autres mondes" ;-)



Z'êtes de quel monde sinon... lol

Ensuite, il ne vous restera qu'à déplacer toutes vos commandes



??? Que désignez-vous par "commandes" ?



Une commande est un exécutable. Il y a les commandes d'origine, mais il
a aussi toutes les commandes que l'on peut ajouter. Si les commandes
d'origine se trouve dans les dossiers de Windows (qui se trouvent par
défaut dans la variable PATH), on préférera ajouter et centraliser les
nouvelles commandes dans un dossier créé pour l'occasion. Dossier que
l'on rajoutera à la variable PATH afin que ces nouvelles commandes
soient accessibles de partout, tout comme une commande d'origine.

Chose que réalise donc cmdPATH en 1 coup. ;-)

dans ce dossier pour les rendre accessible depuis n'importe quel
dossier.



Franchement je ne suis pas votre pensée, la commande icals (qui doit
être un exécutable planqué quelque part) doit bien accepter un chemin
pour désigner un répertoire ou un fichier et je me fous de savoir où
j'exécute icalcs.



Dans le cas présent, c'est le système qui se fout royalement de ce que
vous pouvez bien saisir, puisque (au choix) :

1) l'exécutable n'est pas présent
2) le chemin dans lequel il se trouve n'est pas présent dans le PATH
3) Le chemin est composé d'une variable d'environnement ne pouvant pas
être interprétée (expandée) - voir ci-bas.

Donc, si vous le voulez bien :

1) Vérifiez que "icacls.exe" figure dans "%SystemRoot%system32"
2) Vérifiez que la variable "PATH" contienne ce chemin.
Tapez dans Exécuter (ou Rechercher) :
cmd /k path
3) Si oui, le type de la variable PATH doit être erroné (voir ci-bas)
En attendant, vous pouvez très bien exécuter "icacls.exe" ou
n'importe quelle autre commande en spéficiant son chemin d'accès :

%systemroot%system32icacls

http://www.ptorris.com/console.php#cmdpath

Exemple (depuis le dossier de cmdPATH) :
cmdpath c:cmdpath

* crée le dossier "cmdpath" et l'ajoute au PATH utilisateur



Quand j'aurais compris ce que cela fait exactement, peut-être...



Si ce n'est pas le cas, j'abandonne. :-)
Et si vous ne voulez pas rajouter de commandes, ce n'est pas la peine.

Lors de son usage, cmdPATH indique toutefois si le type de la variable
PATH est erroné dans le Registre (REG_SZ au lieu de REG_EXPAND_SZ).
Pour le vérifier et le corriger directement, il suffit d'utiliser la
syntaxe suivante :

cmdpath /r
cmdpath /k /r

Et oui, il y 2 syntaxes, car il y a en vérité 2 variables PATH ! Une
pour l'utilisateur (HKCU) et une pour la machine (HKLM) situées dans le
Registre sous les clés :

HKCUEnvironment
HKLMSYSTEMCurrentControlSetControlSession ManagerEnvironment

Dans votre cas, la seconde syntaxe serait essentielle puisqu'on trouve
"%SystemRoot%system32" dans HKLM, qui ne peut être interprété qu'avec
le type "REG_EXPAND_SZ".

NB : à noter que ces syntaxes ne créent ni de dossier, ni ne modifie
les variables. Elles contrôlent le type des variables en permettant de
les corriger (réécrire) le cas échéant.

NB : bien entendu, si la commande n'est pas accessible via le PATH (tel
cmdPath la première fois), il convient de l'exécuter à partir de son
propre dossier.



Pourquoi ne pas faire un minimum de help qui explique les fonctionnalité
et la mise en oeuvre...

SiteWeb.url
cmdPATH.exe

c'est court ;-(



Ce n'est pas une spécification qui concerne cmdPATH, mais Windows !!!!

Concernant le help de cmdPATH :
cmdpath /?

En complément : pour ajouter l'option "Invite de commandes" dans le
menu contextuel des dossiers (clic droit), vous pouvez utiliser RegDos
(compatible XP-Vista). Cela fait, 2 clics depuis l'Explorateur et vous
vous retrouvez sous l'invite de commandes dans le dossier souhaité :
http://www.ptorris.com/rapido.php#regdos



Là je saisis mieux l'objet et le but de votre "offre". j'ai compris que
cela permet d'ouvrir "Invite de commande" en faisant un "cd" qui amène
dans le répertoire désigné par la souris...

Comme j'utilise l'équivalent sur l'unix où je suis, je comprends mieux...



On va dire que pour la compréhension, ce serait ça. ;-)

En vérité, ça exécute depuis le menu contextuel de l'Explorateur
"cmd.exe" (l'interpréteur de commandes) avec le chemin dans lequel on
se trouve en paramètre. Exemple manuel depuis Exécuter :
cmd %systemroot%system32

--
Bien à vous. Pierre TORRIS
www.ptorris.com
Répondre en citant
Pierre TORRIS
Le #16360331
Alain Naigeon
Par conséquent, si je crée un dossier où je loge des commandes que j'ai
de bonnes raisons de ne pas mélanger à d'autres, je dois ensuite ajouter
ce dossier à la variable PATH.
La commande de Pierre Torris fait les deux à la fois : elle crée le dossier
*et* ajoute son chemin dans le PATH.

J'espère avoir contribué un peu à éclaircir les choses, surmontant le
découragement qui peut poindre en lisant quelqu'un qui affirme s'en
<citation>
foutre
</citation>



Merci Alain. :-)

--
Bien à vous. Pierre TORRIS
www.ptorris.com
Répondre en citant
Fred
Le #16360551
Dans : news:,
Pierre TORRIS écrivait :

"icacls" figure, dans mon Vista Ultimate, dans le dossier "system32".



Hélas, c'est là qu'est l'os Pierre. Je crains que icacls ne soit pas
disponible pour XP. En tous cas, je n'ai rien trouvé en téléchargement
chez MS.

--
Fred

Répondre en citant
jackr13
Le #16360671
Bonjour,

Pierre TORRIS wrote:
Jacques Perrocheau ce message

In article Pierre TORRIS
Comme toute commande, il faut qu'elle soit présente dans un dossier
du PATH afin que le système puisse la retrouver et l'exécuter depuis
n'importe quel dossier.



??? Qu'est-ce "un dossier du PATH" ? C'est pour moi une étrange
façon de désigner la variable d'environnement, "PATH".



Ca ne désigne pas la variable en elle-même, mais son contenu !

La variable d'environnement "PATH" contient des noms de dossiers
(chemins complets). Chacun des chemins étant séparés par un point
virgule. Donc, un dossier du PATH est un dossier (chemin complet) qui
figure dans la variable d'environnement "PATH".

En invite de commandes, tapez (pour lister la contenu de la variable)
: path

Cela ne me dit pas où se trouve cet "icacls" qui si j'ai bien compris
existe quelque part sur le disque... et quel est la valeur de ce
fameux "PATH" à mettre.



Je parlais de commandes (exécutables) ajoutées.

"icacls" figure, dans mon Vista Ultimate, dans le dossier "system32".

Hors, ce dossier figure par défaut dans la variable "PATH". Si donc,
le fichier "icacls.exe" existe bien sur votre système dans le dossier
"system32", et que le chemin "%SystemRoot%system32" existe bien dans
la variable "PATH", c'est qu'il est fort probable que votre soucis
provienne du fait que le type de la variable "PATH" soit erroné dans
le Registre. Chose que cmdPATH peut résoudre au passage (voir
ci-dessous).

Pourquoi donc des trucs existant dans une installation Windows ne
sont pas directement utilisables avec un minimum d'information comme
la lecture du help que bien évidemment je n'arrive pas aussi à faire
apparaître ?



Il faut aussi préciser qu'il y a différentes versions de Windows.
Toutes ne possèdent pas forcément les mêmes commandes de base.

Pourquoi diable faut-il mettre les mains dans le cambouis, avant
utilisation dès qu'on sort un peu de l'ordinaire ?



Il y a le système seul après son installation.
Et puis le système après moults installations tiers.

Vous pourriez par exemple utiliser cmdPATH qui permet de créer un
nouveau dossier et d'ajouter ce dossier à la variable PATH.



Je n'ai toujours pas bien saisi la finalité de ce que vous me
proposez.. Visiblement le vocabulaire n'est pas le même dans les
"autres mondes" ;-)



Z'êtes de quel monde sinon... lol

Ensuite, il ne vous restera qu'à déplacer toutes vos commandes



??? Que désignez-vous par "commandes" ?



Une commande est un exécutable. Il y a les commandes d'origine, mais
il a aussi toutes les commandes que l'on peut ajouter. Si les
commandes d'origine se trouve dans les dossiers de Windows (qui se
trouvent par défaut dans la variable PATH), on préférera ajouter et
centraliser les nouvelles commandes dans un dossier créé pour
l'occasion. Dossier que l'on rajoutera à la variable PATH afin que
ces nouvelles commandes soient accessibles de partout, tout comme une
commande d'origine.

Chose que réalise donc cmdPATH en 1 coup. ;-)

dans ce dossier pour les rendre accessible depuis n'importe quel
dossier.



Franchement je ne suis pas votre pensée, la commande icals (qui doit
être un exécutable planqué quelque part) doit bien accepter un chemin
pour désigner un répertoire ou un fichier et je me fous de savoir où
j'exécute icalcs.



Dans le cas présent, c'est le système qui se fout royalement de ce que
vous pouvez bien saisir, puisque (au choix) :

1) l'exécutable n'est pas présent
2) le chemin dans lequel il se trouve n'est pas présent dans le PATH
3) Le chemin est composé d'une variable d'environnement ne pouvant pas
être interprétée (expandée) - voir ci-bas.

Donc, si vous le voulez bien :

1) Vérifiez que "icacls.exe" figure dans "%SystemRoot%system32"
2) Vérifiez que la variable "PATH" contienne ce chemin.
Tapez dans Exécuter (ou Rechercher) :
cmd /k path
3) Si oui, le type de la variable PATH doit être erroné (voir ci-bas)
En attendant, vous pouvez très bien exécuter "icacls.exe" ou
n'importe quelle autre commande en spéficiant son chemin d'accès :

%systemroot%system32icacls

http://www.ptorris.com/console.php#cmdpath

Exemple (depuis le dossier de cmdPATH) :
cmdpath c:cmdpath

* crée le dossier "cmdpath" et l'ajoute au PATH utilisateur



Quand j'aurais compris ce que cela fait exactement, peut-être...



Si ce n'est pas le cas, j'abandonne. :-)
Et si vous ne voulez pas rajouter de commandes, ce n'est pas la peine.

Lors de son usage, cmdPATH indique toutefois si le type de la variable
PATH est erroné dans le Registre (REG_SZ au lieu de REG_EXPAND_SZ).
Pour le vérifier et le corriger directement, il suffit d'utiliser la
syntaxe suivante :

cmdpath /r
cmdpath /k /r

Et oui, il y 2 syntaxes, car il y a en vérité 2 variables PATH ! Une
pour l'utilisateur (HKCU) et une pour la machine (HKLM) situées dans
le Registre sous les clés :

HKCUEnvironment
HKLMSYSTEMCurrentControlSetControlSession ManagerEnvironment

Dans votre cas, la seconde syntaxe serait essentielle puisqu'on trouve
"%SystemRoot%system32" dans HKLM, qui ne peut être interprété qu'avec
le type "REG_EXPAND_SZ".

NB : à noter que ces syntaxes ne créent ni de dossier, ni ne modifie
les variables. Elles contrôlent le type des variables en permettant de
les corriger (réécrire) le cas échéant.

NB : bien entendu, si la commande n'est pas accessible via le PATH
(tel cmdPath la première fois), il convient de l'exécuter à partir
de son propre dossier.



Pourquoi ne pas faire un minimum de help qui explique les
fonctionnalité et la mise en oeuvre...

SiteWeb.url
cmdPATH.exe

c'est court ;-(



Ce n'est pas une spécification qui concerne cmdPATH, mais Windows !!!!

Concernant le help de cmdPATH :
cmdpath /?

En complément : pour ajouter l'option "Invite de commandes" dans le
menu contextuel des dossiers (clic droit), vous pouvez utiliser
RegDos (compatible XP-Vista). Cela fait, 2 clics depuis
l'Explorateur et vous vous retrouvez sous l'invite de commandes
dans le dossier souhaité : http://www.ptorris.com/rapido.php#regdos



Là je saisis mieux l'objet et le but de votre "offre". j'ai compris
que cela permet d'ouvrir "Invite de commande" en faisant un "cd" qui
amène dans le répertoire désigné par la souris...

Comme j'utilise l'équivalent sur l'unix où je suis, je comprends
mieux...



On va dire que pour la compréhension, ce serait ça. ;-)

En vérité, ça exécute depuis le menu contextuel de l'Explorateur
"cmd.exe" (l'interpréteur de commandes) avec le chemin dans lequel on
se trouve en paramètre. Exemple manuel depuis Exécuter :
cmd %systemroot%system32



Je m'excuse d'intervenir dans votre discussion pour une petite remarque
. Votre interlocuteur est peut-être équipé de XP et icacls.exe bien que
fonctionnant sous XP n'est pas livré de base avec ce système.
Icacls.exe est livré avec Vista ou 2003 Serveur.
Cordialement,
jackr13
Répondre en citant
Pierre TORRIS
Le #16360851
jackr13
Je m'excuse d'intervenir dans votre discussion pour une petite remarque
. Votre interlocuteur est peut-être équipé de XP et icacls.exe bien que
fonctionnant sous XP n'est pas livré de base avec ce système.
Icacls.exe est livré avec Vista ou 2003 Serveur.



Merci Fred et jackr13, mais le Monsieur a posté (sous PPC Mac OS X
d'ailleurs) dans le groupe Vista à partir duquel je réponds !

Ne sachant pas s'il dispose ou non de l'exécutable, je pense qu'il
pourra faire face à toute éventualité, présente ou à venir. ;-)

--
Bien à vous. Pierre TORRIS
www.ptorris.com
Répondre en citant
Méta-MCI \(MVP\)
Le #16365111
Bonsoir !

J'hésite...
Est-il demandé :
- la liste de tous les fichiers dont un utilisateur précis, identifié
par son SID, est propriétaire ?
ou
- la liste de tous les fichiers d'un répertoire spécial, identifié pas
son clSID ?

Dans le premier cas, je pense que l'utilitaire SUBINACL.exe pourrait
donner l'information. Dans le second, ça dépend de quel répertoire
spécial il s'agit.

@+
--
Michel Claveau
Répondre en citant
jperrocheau
Le #16370231
Pierre TORRIS
> ??? Qu'est-ce "un dossier du PATH" ? C'est pour moi une étrange façon de
> désigner la variable d'environnement, "PATH".

Ca ne désigne pas la variable en elle-même, mais son contenu !



OK

La variable d'environnement "PATH" contient des noms de dossiers
(chemins complets). Chacun des chemins étant séparés par un point
virgule. Donc, un dossier du PATH est un dossier (chemin complet) qui
figure dans la variable d'environnement "PATH".



OK, j'ai mieux compris en regardant la copie d'écran qui est sous

En invite de commandes, tapez (pour lister la contenu de la variable) :
path.



OK, on revient dans des trucs "plus standard". ;-)


> Cela ne me dit pas où se trouve cet "icacls" qui si j'ai bien compris
> existe quelque part sur le disque... et quel est la valeur de ce fameux
> "PATH" à mettre.

Je parlais de commandes (exécutables) ajoutées.

"icacls" figure, dans mon Vista Ultimate, dans le dossier "system32".



OK, c'est ce que j'attendais, d'un spécialiste ;), mais d'après ce que
dit Fred Message-ID: ----
Hélas, c'est là qu'est l'os Pierre. Je crains que icacls ne soit pas
disponible pour XP. En tous cas, je n'ai rien trouvé en téléchargement
chez MS.


---
il faut que je fasse cela sur une machine sous WinXP ;-(.


Hors, ce dossier figure par défaut dans la variable "PATH". Si donc, le
fichier "icacls.exe" existe bien sur votre système dans le dossier
"system32", et que le chemin "%SystemRoot%system32" existe bien dans
la variable "PATH", c'est qu'il est fort probable que votre soucis
provienne du fait que le type de la variable "PATH" soit erroné dans le
Registre. Chose que cmdPATH peut résoudre au passage (voir ci-dessous).



OK, j'ai compris, merci de t'être mis à mon niveau.

> Pourquoi donc des trucs existant dans une installation Windows ne sont
> pas directement utilisables avec un minimum d'information comme la
> lecture du help que bien évidemment je n'arrive pas aussi à faire
> apparaître ?

Il faut aussi préciser qu'il y a différentes versions de Windows.
Toutes ne possèdent pas forcément les mêmes commandes de base.



Aïe!

> Pourquoi diable faut-il mettre les mains dans le cambouis, avant
> utilisation dès qu'on sort un peu de l'ordinaire ?

Il y a le système seul après son installation.
Et puis le système après moults installations tiers.



Je suis d'accord.

>> Vous pourriez par exemple utiliser cmdPATH qui permet de créer un
>> nouveau dossier et d'ajouter ce dossier à la variable PATH.
>
> Je n'ai toujours pas bien saisi la finalité de ce que vous me proposez..
> Visiblement le vocabulaire n'est pas le même dans les "autres mondes" ;-)

Z'êtes de quel monde sinon... lol



C'est visible dans mon en-tête ;-).

>> [snip]



Encore merci pour cette longue réponse. J'archive pour usage ultérieur.

--
Jacques PERROCHEAU
________________________________________________________________________
e-mail: mailto:
Répondre en citant
jperrocheau
Le #16370211
Fred
Hélas, c'est là qu'est l'os Pierre. Je crains que icacls ne soit pas
disponible pour XP. En tous cas, je n'ai rien trouvé en téléchargement
chez MS.



;-(

Tu es sûr ? Il me souvient que le sieur JC Bellamy en avait parlé, de
mémoire avant la sortie de Vista...

Toute info est la bienvenue.

--
Jacques PERROCHEAU
________________________________________________________________________
e-mail: mailto:
Répondre en citant
jperrocheau
Le #16370221
Alain Naigeon
De deux choses l'une :

Ou bien toutes les commandes (programmes exécutables) sont regroupées
en un seul endroit fixe, ce qui est inimaginable pour des tas de raison
(dont
j'ai bien peur que vous vous foutiez également).

Ou bien, si on peut, pour des raisons d'organisation et de souplesse
(l'autre
monde, quoi), les mettre où l'on veut, alors il faut bien dire au système où
elles sont. Croyez-vous vraiment qu'une recherche sur tous vos disques
est lancée à chaque fois que vous lancez une commande ?
(euh, si ma femme lisait ça, elle mettrait moins de temps à trouver ses clés
à chaque fois, mais elle a l'excuse, elle, de ne pas être au CNRS).

La variable (chaîne textuelle) PATH énumère donc les quelques endroits
(chemin complet) où peuvent être trouvées des commandes.

Par conséquent, si je crée un dossier où je loge des commandes que j'ai
de bonnes raisons de ne pas mélanger à d'autres, je dois ensuite ajouter
ce dossier à la variable PATH.
La commande de Pierre Torris fait les deux à la fois : elle crée le dossier
*et* ajoute son chemin dans le PATH.

J'espère avoir contribué un peu à éclaircir les choses, surmontant le
découragement qui peut poindre en lisant quelqu'un qui affirme s'en
<citation>
foutre
</citation>



Là vous tronquez un peu ma phrase ;-)

C'est l'expression un peu trop racourcie "dossier du PATH" que je ne
comprennais pas. L'expression "variable PATH" est bien mieux comprise
par les newbies... et votre phrase:

---
La commande de Pierre Torris fait les deux à la fois : elle crée le
dossier *et* ajoute son chemin dans le PATH.


---
explique tout très simplement.

Bon comme je dois faire cela sur un WinXP, je ne suis pas sorti de
l'auberge, j'apprends dans le post Message-ID:
pour WinXP... ;-(.

--
Jacques PERROCHEAU
________________________________________________________________________
e-mail: mailto:
Répondre en citant
Michel__D
Le #16370761
Bonjour,

Jacques Perrocheau a écrit :
Fred
Hélas, c'est là qu'est l'os Pierre. Je crains que icacls ne soit pas
disponible pour XP. En tous cas, je n'ai rien trouvé en téléchargement
chez MS.



;-(

Tu es sûr ? Il me souvient que le sieur JC Bellamy en avait parlé, de
mémoire avant la sortie de Vista...

Toute info est la bienvenue.




Regarde ceci :
http://support.microsoft.com/kb/318754/
Répondre en citant
Publicité
Poster une réponse
Anonyme