je cherche un script VBS / WSF qui m'afficherait les informations d'acces en
cours d'un fichier "local" ; un peux comme le permet le fameux programme
UnLock qui permet de visualiser les processus qui vérouille un fichier et
permet même de le libérer.
Pour supprimer un verrou, c'est NET FILE numéro_affiche /CLOSE
Jacques Barathon [MS]
"Méta-MCI (MVP)" wrote in message news:46ea60b8$0$27366$
Pardon, la commande, c'est NET FILE
(LOCKS, c'était le nom de mon batch)
Pour supprimer un verrou, c'est NET FILE numéro_affiche /CLOSE
Sous les versions les plus récentes de Windows (XP, Vista et Server 2003) on peut également utiliser la commande openfiles. Par défaut, openfiles ne traite que les fichiers ouverts par des clients réseau, mais il est possible de lui demander de traiter également les fichiers ouverts localement (de mémoire, il faut redémarrer le système pour que la modification soit prise en compte).
Sinon, on peut utiliser l'excellent freeware handle.exe (dispo sur www.microsoft.com/technet/sysinternals).
Jacques
"Méta-MCI (MVP)" <enleverlesX.XmcX@XmclaveauX.com> wrote in message
news:46ea60b8$0$27366$ba4acef3@news.orange.fr...
Pardon, la commande, c'est NET FILE
(LOCKS, c'était le nom de mon batch)
Pour supprimer un verrou, c'est NET FILE numéro_affiche /CLOSE
Sous les versions les plus récentes de Windows (XP, Vista et Server 2003) on
peut également utiliser la commande openfiles. Par défaut, openfiles ne
traite que les fichiers ouverts par des clients réseau, mais il est possible
de lui demander de traiter également les fichiers ouverts localement (de
mémoire, il faut redémarrer le système pour que la modification soit prise
en compte).
Sinon, on peut utiliser l'excellent freeware handle.exe (dispo sur
www.microsoft.com/technet/sysinternals).
"Méta-MCI (MVP)" wrote in message news:46ea60b8$0$27366$
Pardon, la commande, c'est NET FILE
(LOCKS, c'était le nom de mon batch)
Pour supprimer un verrou, c'est NET FILE numéro_affiche /CLOSE
Sous les versions les plus récentes de Windows (XP, Vista et Server 2003) on peut également utiliser la commande openfiles. Par défaut, openfiles ne traite que les fichiers ouverts par des clients réseau, mais il est possible de lui demander de traiter également les fichiers ouverts localement (de mémoire, il faut redémarrer le système pour que la modification soit prise en compte).
Sinon, on peut utiliser l'excellent freeware handle.exe (dispo sur www.microsoft.com/technet/sysinternals).
Jacques
GOWAP
Je le redis : en local
Savoir si un fichier est ouvert par un ordinateur distant et directement visible dans la gestion de l'ordinateur (manager / gérer). Aucun besoin de poser cette question !
Savoir qu'elle est le programme / service local, en mémoire, qui est a ouvert et verrouillé un fichier local, c'est ça la question.
Donc, comment, avec du VBS, en WMI peut-être, savoir si un fichier est actuellement verrouillé, sans pour cela cherche a l'ouvrir en écriture quand même, sinon, risque de changement de date et d'attribut (CACLS). C'est pour ca que j'ai fais référence à UnLock. Pourquoi du script ? pas d'installation, pas d'exe, et en plus, peut être intégré dans un script plus global, comme une attente de libération pour un backup, par exemple.
Merci de me donner des informations "orienté script" si vous en trouvé. Et je vous promets de mettre en ligne mes scripts qui en découlerons.
A++, GOWAP
"GOWAP" <gowap@@fr.fm> a écrit dans le message de news: 46ea52c6$0$13897$
Bonjour,
je cherche un script VBS / WSF qui m'afficherait les informations d'acces en cours d'un fichier "local" ; un peux comme le permet le fameux programme UnLock qui permet de visualiser les processus qui vérouille un fichier et permet même de le libérer.
Aurriez-vous ça quelque part ?
Merci, GOWAP
Je le redis : en local
Savoir si un fichier est ouvert par un ordinateur distant et directement
visible dans la gestion de l'ordinateur (manager / gérer). Aucun besoin de
poser cette question !
Savoir qu'elle est le programme / service local, en mémoire, qui est a
ouvert et verrouillé un fichier local, c'est ça la question.
Donc, comment, avec du VBS, en WMI peut-être, savoir si un fichier est
actuellement verrouillé, sans pour cela cherche a l'ouvrir en écriture quand
même, sinon, risque de changement de date et d'attribut (CACLS).
C'est pour ca que j'ai fais référence à UnLock.
Pourquoi du script ? pas d'installation, pas d'exe, et en plus, peut être
intégré dans un script plus global, comme une attente de libération pour un
backup, par exemple.
Merci de me donner des informations "orienté script" si vous en trouvé.
Et je vous promets de mettre en ligne mes scripts qui en découlerons.
A++,
GOWAP
"GOWAP" <gowap@@fr.fm> a écrit dans le message de news:
46ea52c6$0$13897$426a74cc@news.free.fr...
Bonjour,
je cherche un script VBS / WSF qui m'afficherait les informations d'acces
en cours d'un fichier "local" ; un peux comme le permet le fameux
programme UnLock qui permet de visualiser les processus qui vérouille un
fichier et permet même de le libérer.
Savoir si un fichier est ouvert par un ordinateur distant et directement visible dans la gestion de l'ordinateur (manager / gérer). Aucun besoin de poser cette question !
Savoir qu'elle est le programme / service local, en mémoire, qui est a ouvert et verrouillé un fichier local, c'est ça la question.
Donc, comment, avec du VBS, en WMI peut-être, savoir si un fichier est actuellement verrouillé, sans pour cela cherche a l'ouvrir en écriture quand même, sinon, risque de changement de date et d'attribut (CACLS). C'est pour ca que j'ai fais référence à UnLock. Pourquoi du script ? pas d'installation, pas d'exe, et en plus, peut être intégré dans un script plus global, comme une attente de libération pour un backup, par exemple.
Merci de me donner des informations "orienté script" si vous en trouvé. Et je vous promets de mettre en ligne mes scripts qui en découlerons.
A++, GOWAP
"GOWAP" <gowap@@fr.fm> a écrit dans le message de news: 46ea52c6$0$13897$
Bonjour,
je cherche un script VBS / WSF qui m'afficherait les informations d'acces en cours d'un fichier "local" ; un peux comme le permet le fameux programme UnLock qui permet de visualiser les processus qui vérouille un fichier et permet même de le libérer.
Aurriez-vous ça quelque part ?
Merci, GOWAP
Jacques Barathon [MS]
"GOWAP" wrote in message news:46eeecce$0$18259$ ...
Donc, comment, avec du VBS, en WMI peut-être, savoir si un fichier est actuellement verrouillé, sans pour cela cherche a l'ouvrir en écriture quand même, sinon, risque de changement de date et d'attribut (CACLS).
A ma connaissance, aucune classe WMI n'expose cette info, et sans doute pas plus en VBS. Il faudrait attaquer des API Win32, donc sortir de ton cahier des charges (à moins que PowerShell soit une solution de scripting possible, en considérant qu'on peut invoquer des API Win32 à partir de PowerShell avec un peu d'huile de coude - et même là, je n'ai pas gratté le sujet mais ça n'est pas forcément gagné).
C'est pour ca que j'ai fais référence à UnLock. Pourquoi du script ? pas d'installation, pas d'exe, et en plus, peut être intégré dans un script plus global, comme une attente de libération pour un backup, par exemple.
Si ton système est XP, Vista ou 2003 et que tu acceptes de redémarrer le système au moins une fois, openfiles reste une solution standard qui ne demande l'installation d'aucun exe. Cela dit, l'accès à un exe extérieur (handle, unlock ou autre) à partir d'un partage réseau pourrait aussi être une solution viable, vue la taille très légère de ce genre d'utilitaire.
Merci de me donner des informations "orienté script" si vous en trouvé. Et je vous promets de mettre en ligne mes scripts qui en découlerons.
Si tu trouves, je suis preneur!
Jacques
"GOWAP" <gowap@fr.fm> wrote in message
news:46eeecce$0$18259$426a74cc@news.free.fr...
...
Donc, comment, avec du VBS, en WMI peut-être, savoir si un fichier est
actuellement verrouillé, sans pour cela cherche a l'ouvrir en écriture
quand même, sinon, risque de changement de date et d'attribut (CACLS).
A ma connaissance, aucune classe WMI n'expose cette info, et sans doute pas
plus en VBS. Il faudrait attaquer des API Win32, donc sortir de ton cahier
des charges (à moins que PowerShell soit une solution de scripting possible,
en considérant qu'on peut invoquer des API Win32 à partir de PowerShell avec
un peu d'huile de coude - et même là, je n'ai pas gratté le sujet mais ça
n'est pas forcément gagné).
C'est pour ca que j'ai fais référence à UnLock.
Pourquoi du script ? pas d'installation, pas d'exe, et en plus, peut être
intégré dans un script plus global, comme une attente de libération pour
un backup, par exemple.
Si ton système est XP, Vista ou 2003 et que tu acceptes de redémarrer le
système au moins une fois, openfiles reste une solution standard qui ne
demande l'installation d'aucun exe. Cela dit, l'accès à un exe extérieur
(handle, unlock ou autre) à partir d'un partage réseau pourrait aussi être
une solution viable, vue la taille très légère de ce genre d'utilitaire.
Merci de me donner des informations "orienté script" si vous en trouvé.
Et je vous promets de mettre en ligne mes scripts qui en découlerons.
"GOWAP" wrote in message news:46eeecce$0$18259$ ...
Donc, comment, avec du VBS, en WMI peut-être, savoir si un fichier est actuellement verrouillé, sans pour cela cherche a l'ouvrir en écriture quand même, sinon, risque de changement de date et d'attribut (CACLS).
A ma connaissance, aucune classe WMI n'expose cette info, et sans doute pas plus en VBS. Il faudrait attaquer des API Win32, donc sortir de ton cahier des charges (à moins que PowerShell soit une solution de scripting possible, en considérant qu'on peut invoquer des API Win32 à partir de PowerShell avec un peu d'huile de coude - et même là, je n'ai pas gratté le sujet mais ça n'est pas forcément gagné).
C'est pour ca que j'ai fais référence à UnLock. Pourquoi du script ? pas d'installation, pas d'exe, et en plus, peut être intégré dans un script plus global, comme une attente de libération pour un backup, par exemple.
Si ton système est XP, Vista ou 2003 et que tu acceptes de redémarrer le système au moins une fois, openfiles reste une solution standard qui ne demande l'installation d'aucun exe. Cela dit, l'accès à un exe extérieur (handle, unlock ou autre) à partir d'un partage réseau pourrait aussi être une solution viable, vue la taille très légère de ce genre d'utilitaire.
Merci de me donner des informations "orienté script" si vous en trouvé. Et je vous promets de mettre en ligne mes scripts qui en découlerons.
Si tu trouves, je suis preneur!
Jacques
Do Ré Mi Chel La Si Do \(MVP\)
Salut !
Je le redis : en local
Je le redis : une ressource, même (et surtout) locale, peux être partagée ou non.
@+
MCI
Salut !
Je le redis : en local
Je le redis : une ressource, même (et surtout) locale, peux être partagée ou non.
Je le redis : une ressource, même (et surtout) locale, peux être partagée ou non.
@+
MCI
Do Ré Mi Chel La Si Do \(MVP\)
Salut, Jacques !
Perso, Openfiles fonctionne très bien sur des ressources partagées (comme Net Files), mais, lorsque je lance Openfiles /local ON ça n'a aucun effet. Redémarrage ou non ne change rien. Peut-être ai-je désactivé un service de trop...
@+
Michel Claveau
Salut, Jacques !
Perso, Openfiles fonctionne très bien sur des ressources partagées (comme Net Files), mais, lorsque
je lance
Openfiles /local ON
ça n'a aucun effet. Redémarrage ou non ne change rien. Peut-être ai-je désactivé un service de
trop...
Perso, Openfiles fonctionne très bien sur des ressources partagées (comme Net Files), mais, lorsque je lance Openfiles /local ON ça n'a aucun effet. Redémarrage ou non ne change rien. Peut-être ai-je désactivé un service de trop...
@+
Michel Claveau
GOWAP
Mais qu'est-ce que cette histoire de partage vient faire la ?
Fait la chose suivante : - ouvre un fenetre dos - créés un dossier "toto" avec "md toto" - et rentre dedans avec "cd toto" - ouvre un explorateur sur le dossier parent de toto avec "start .." - sélection le dossier et essais de le supprimer.
Alors, est-ce que ce dossier est partagé en réseau ? Ou tu vois du partage là ? Le dossier toto est vérouillé par la ressource "cmd.exe" ce qui affiche l'erreur standard :
Impossible de suppprimer toto : Cette ressource est utilisée par une autre personne ou un autre programme. Fermez les programmes susceptibles d'utiliser le fichier et essayez à nouveau.
Vous aurriez pas les sources de UnLock que l'on regarde ce qu'il va cherché pour connaitre la programme qui accede a un fichier ?
"Do Ré Mi Chel La Si Do (MVP)" a écrit dans le message de news: ObbI57b%
Salut !
Je le redis : en local
Je le redis : une ressource, même (et surtout) locale, peux être partagée ou non.
@+
MCI
Mais qu'est-ce que cette histoire de partage vient faire la ?
Fait la chose suivante :
- ouvre un fenetre dos
- créés un dossier "toto" avec "md toto"
- et rentre dedans avec "cd toto"
- ouvre un explorateur sur le dossier parent de toto avec "start .."
- sélection le dossier et essais de le supprimer.
Alors, est-ce que ce dossier est partagé en réseau ? Ou tu vois du partage
là ?
Le dossier toto est vérouillé par la ressource "cmd.exe" ce qui affiche
l'erreur standard :
Impossible de suppprimer toto : Cette ressource est utilisée par une autre
personne ou un autre programme.
Fermez les programmes susceptibles d'utiliser le fichier et essayez à
nouveau.
Vous aurriez pas les sources de UnLock que l'on regarde ce qu'il va cherché
pour connaitre la programme qui accede a un fichier ?
"Do Ré Mi Chel La Si Do (MVP)" <enleverlesOmcO@OmclaveauO.com> a écrit dans
le message de news: ObbI57b%23HHA.4460@TK2MSFTNGP02.phx.gbl...
Salut !
Je le redis : en local
Je le redis : une ressource, même (et surtout) locale, peux être partagée
ou non.
Mais qu'est-ce que cette histoire de partage vient faire la ?
Fait la chose suivante : - ouvre un fenetre dos - créés un dossier "toto" avec "md toto" - et rentre dedans avec "cd toto" - ouvre un explorateur sur le dossier parent de toto avec "start .." - sélection le dossier et essais de le supprimer.
Alors, est-ce que ce dossier est partagé en réseau ? Ou tu vois du partage là ? Le dossier toto est vérouillé par la ressource "cmd.exe" ce qui affiche l'erreur standard :
Impossible de suppprimer toto : Cette ressource est utilisée par une autre personne ou un autre programme. Fermez les programmes susceptibles d'utiliser le fichier et essayez à nouveau.
Vous aurriez pas les sources de UnLock que l'on regarde ce qu'il va cherché pour connaitre la programme qui accede a un fichier ?
"Do Ré Mi Chel La Si Do (MVP)" a écrit dans le message de news: ObbI57b%
Salut !
Je le redis : en local
Je le redis : une ressource, même (et surtout) locale, peux être partagée ou non.
@+
MCI
Jacques Barathon [MS]
"GOWAP" wrote in message news:471d13fa$0$1135$ ...
Vous aurriez pas les sources de UnLock que l'on regarde ce qu'il va cherché pour connaitre la programme qui accede a un fichier ?
Ca te servira à quoi? A compiler ton propre programme? UnLock va très probablement chercher les infos en utilisant les API Win32 qui ne sont pas utilisables directement avec les outils de scripting inclus à l'heure actuelle dans Windows.
Donc, tu as le choix entre:
- utiliser openfiles.exe comme je te le suggérais déjà il y a un mois, - copier localement (ou lancer depuis un partage) handle.exe ou tout autre logiciel comme unlock.exe, - compiler ton propre programme si ça t'amuse, - installer un outil de scripting qui supporte l'appel aux API Win32 (je pense que Python et Perl peuvent le faire via des modules additionnels, on doit également pouvoir trouver des add-ons pour VBScript, et PowerShell peut le faire avec un peu d'huile de coude), - continuer à faire ce que tu fais depuis le 14/09...
Jacques
"GOWAP" <gowap@fr.fm> wrote in message
news:471d13fa$0$1135$426a74cc@news.free.fr...
...
Vous aurriez pas les sources de UnLock que l'on regarde ce qu'il va
cherché pour connaitre la programme qui accede a un fichier ?
Ca te servira à quoi? A compiler ton propre programme? UnLock va très
probablement chercher les infos en utilisant les API Win32 qui ne sont pas
utilisables directement avec les outils de scripting inclus à l'heure
actuelle dans Windows.
Donc, tu as le choix entre:
- utiliser openfiles.exe comme je te le suggérais déjà il y a un mois,
- copier localement (ou lancer depuis un partage) handle.exe ou tout autre
logiciel comme unlock.exe,
- compiler ton propre programme si ça t'amuse,
- installer un outil de scripting qui supporte l'appel aux API Win32 (je
pense que Python et Perl peuvent le faire via des modules additionnels, on
doit également pouvoir trouver des add-ons pour VBScript, et PowerShell peut
le faire avec un peu d'huile de coude),
- continuer à faire ce que tu fais depuis le 14/09...
"GOWAP" wrote in message news:471d13fa$0$1135$ ...
Vous aurriez pas les sources de UnLock que l'on regarde ce qu'il va cherché pour connaitre la programme qui accede a un fichier ?
Ca te servira à quoi? A compiler ton propre programme? UnLock va très probablement chercher les infos en utilisant les API Win32 qui ne sont pas utilisables directement avec les outils de scripting inclus à l'heure actuelle dans Windows.
Donc, tu as le choix entre:
- utiliser openfiles.exe comme je te le suggérais déjà il y a un mois, - copier localement (ou lancer depuis un partage) handle.exe ou tout autre logiciel comme unlock.exe, - compiler ton propre programme si ça t'amuse, - installer un outil de scripting qui supporte l'appel aux API Win32 (je pense que Python et Perl peuvent le faire via des modules additionnels, on doit également pouvoir trouver des add-ons pour VBScript, et PowerShell peut le faire avec un peu d'huile de coude), - continuer à faire ce que tu fais depuis le 14/09...
Jacques
Gilles LAURENT [MVP]
"GOWAP" a écrit dans le message de news:471d13fa$0$1135$ | Vous aurriez pas les sources de UnLock que l'on regarde ce qu'il va | cherché pour connaitre la programme qui accede a un fichier ?
Dans les grandes lignes : - les API Win32 exposées ci-dessous sont nécessaires - les API Win32 natives ne sont pas ou peu documentées - la commutation en mode Kernel est indispensable
- Exécution en mode User :
AdjustTokenPrivilege () => SE_DEBUG_NAME ZwQuerySystemInformation => SystemHandleInformation OpenProcess () GetModuleBaseName () ZwDuplicateObject () ZwQueryObject () => Hangs sur certains processus / handles / ObjectType !! => La commutation en mode Kernel est indispensable => Installation du driver OpenSCManager () CreateService () StartService () => Communication avec le driver DeviceIoControl ()
- Exécution en mode Kernel (driver) => DDK => ceci implique le développement du driver ! IoCreateDevice () IoCreateSymbolicLink () Dispatcher (...) ... ObQueryNameString ()
Vous avez maitenant toutes les clés en main ;-) A vous de jouez !
-- Gilles LAURENT MVP Windows Server - Admin Frameworks http://glsft.free.fr
"GOWAP" <gowap@fr.fm> a écrit dans le message de
news:471d13fa$0$1135$426a74cc@news.free.fr
| Vous aurriez pas les sources de UnLock que l'on regarde ce qu'il va
| cherché pour connaitre la programme qui accede a un fichier ?
Dans les grandes lignes :
- les API Win32 exposées ci-dessous sont nécessaires
- les API Win32 natives ne sont pas ou peu documentées
- la commutation en mode Kernel est indispensable
- Exécution en mode User :
AdjustTokenPrivilege () => SE_DEBUG_NAME
ZwQuerySystemInformation => SystemHandleInformation
OpenProcess ()
GetModuleBaseName ()
ZwDuplicateObject ()
ZwQueryObject ()
=> Hangs sur certains processus / handles / ObjectType !!
=> La commutation en mode Kernel est indispensable
=> Installation du driver
OpenSCManager ()
CreateService ()
StartService ()
=> Communication avec le driver
DeviceIoControl ()
- Exécution en mode Kernel (driver) => DDK
=> ceci implique le développement du driver !
IoCreateDevice ()
IoCreateSymbolicLink ()
Dispatcher (...)
...
ObQueryNameString ()
Vous avez maitenant toutes les clés en main ;-)
A vous de jouez !
--
Gilles LAURENT
MVP Windows Server - Admin Frameworks
http://glsft.free.fr
"GOWAP" a écrit dans le message de news:471d13fa$0$1135$ | Vous aurriez pas les sources de UnLock que l'on regarde ce qu'il va | cherché pour connaitre la programme qui accede a un fichier ?
Dans les grandes lignes : - les API Win32 exposées ci-dessous sont nécessaires - les API Win32 natives ne sont pas ou peu documentées - la commutation en mode Kernel est indispensable
- Exécution en mode User :
AdjustTokenPrivilege () => SE_DEBUG_NAME ZwQuerySystemInformation => SystemHandleInformation OpenProcess () GetModuleBaseName () ZwDuplicateObject () ZwQueryObject () => Hangs sur certains processus / handles / ObjectType !! => La commutation en mode Kernel est indispensable => Installation du driver OpenSCManager () CreateService () StartService () => Communication avec le driver DeviceIoControl ()
- Exécution en mode Kernel (driver) => DDK => ceci implique le développement du driver ! IoCreateDevice () IoCreateSymbolicLink () Dispatcher (...) ... ObQueryNameString ()
Vous avez maitenant toutes les clés en main ;-) A vous de jouez !
-- Gilles LAURENT MVP Windows Server - Admin Frameworks http://glsft.free.fr
