Question LastAccessTime "par qui"? (Résolu)

Le framework DotNet ( System.IO.FileSystemWatcher ) ainsi que WMI, un peu plus corsé à coder sous PowerShell, propose ce type de \"supervision\".

Si vous voulez un coup de main pour réaliser ce type de script n'hésitez pas à me solliciter, je trouve l'idée intéressante.

Un exemple WMI en Delphi
[code:1]
Query:='Select * from __InstanceOperationEvent within 1
where TargetInstance ISA ''CIM_DataFile'' and TargetInstance.name=''c:\\temp\\test.txt'''

procedure TForm1.SWbemSink1ObjectReady(ASender: TObject;
const objWbemObject: ISWbemObject;
const objWbemAsyncContext: ISWbemNamedValueSet);
// Déclenché lorsqu'un objet fourni par l'appel asynchrone est disponible.
// ObjWbemObject contient l'objet retourné

Const cstWMIEvent: Array[0..2] of String=('__InstanceCreationEvent','__InstanceDeletionEvent','__InstanceModificationEvent');

var WmiObjet: ISWbemObject;
WMIContext : TSWbemNamedValueSet;
Contexte : ISWbemNamedValue;
WMILastError: TSWbemLastError;
NomFichier : String;
ClassseEvenement : String;
begin
Try
If Not VarIsEmpty(objWbemAsyncContext)
then
begin
// On utilise un TOleServer que l'on connecte à l'interface reçue en paramètre
WMIContext:=TSWbemNamedValueSet.Create(Self);
With WMIContext do
begin
AutoConnect:=False;
ConnectKind :=ckAttachToInterface;
ConnectTo(IUnknown(objWbemAsyncContext) as ISWbemNamedValueSet);
end;
try
//retrouve la collection initialisée au démarrage de l'application
Contexte:= WMIContext.Item('SinkName',0); // IFlags tjr zéro
// Si l'item n'existe pas, renvoie=wbemErrNotFound
except
on E:Exception do
begin
if (E is EOleException) or (E is EOleSysError)
then
begin
if ExistWMIErreur(WMILastError,Self)
then ShowWMIErreur('Collecteur événement onReady : Méthode Item .',WMILastError,(E as EOleException));
Memo1.Lines.Add(#13#10+'Test d''item inexistant.');
Memo1.Lines.Add(StrOriginError((E as EOleException).ErrorCode));
Memo1.Lines.Add('Erreur '+E.Message);
end;
end;
end;

// L'objet retourné est un événement.
// Sa propriété TargetInstance, commune aux 3 classes, contient une copie de l'instance du fichier concerné. :
WmiObjet:=IUnknown(objWbemObject.Properties_.Item('TargetInstance',0).Get_Value) as ISWbemObject;

//Quelle requête gére-t-on ?
If Contexte.Get_Value = 'Fichier'
Then
begin
//On détermine le type de l'évent d'après son nom de classe
Case AnsiIndexStr(objWbemObject.Path_.Class_,cstWMIEvent) of
0 : Memo1.Lines.Add('Création');
1 : Memo1.Lines.Add('Suppression');
2 : Memo1.Lines.Add('Modification');
end;
//Affiche le nom du fichier, déjà connu dans cet exemple
NomFichier:=WMIVariantToStr(WmiObjet.Properties_.Item('Name',0).Get_Value);
Memo1.Lines.Add(#13#10+'Fichier concerné : '+WMIGetNomFichier(NomFichier)+#13#10);
end
else
begin
Memo1.Lines.Add('Contexte non géré.');
Exit;
end;
//Affiche le détail de 'l'objet fichier'
Memo1.Lines.Add(WmiObjet.Path_.path);
Memo1.Lines.Add(AdjustLineBreaks(WmiObjet.GetObjectText_(0)));
end;
// Else

Finally
// 'Contexte' est une interface ISWbemNamedValue local à cette procédure, Delphi
// se charge de décrémenter son compteur de référence.
FreeAndNil(WMIContext);
end;
end;
[/code:1]

Je ne vous cache pas que j'ai un faible pour son implémentation sous .NET
Ceci dit je ne sais si cette méthode .NET utilise en interne une API native ou si elle s'appuie sur WMI ?

Ca pour un exemple, c'est un exemple...

Plus sérieusement il s'agit clairement de WMI, car ceci est une requête WMI:
[code:1]Query:='Select * from __InstanceOperationEvent within 1
where TargetInstance ISA ''CIM_DataFile'' and TargetInstance.name=''c:\\temp\\test.txt'''
[/code:1]

Effectivement en PowerShell il faut ruser un peu pour y parvenir car la cmdlet Get-WmiObject ne supporte pas les évènements WMI. J'ai déjà fait un script en PowerShell qui monitore l'arrivée d'un fichier dans un répertoire. Je le posterai demain car je ne l'ai pas sous le coude...

@+++ et merci de ton aide BatchMan
PS: Au fait pas mal ton intro PowerShell sur developpez.com ( laurent-dardenne.developpez.com/articles...rShell/Introduction/ ). Tu es démasqué BatchMan...

Arnaud écrit:

Tu es démasqué BatchMan...

Fatalitas

J'ai regardé un peu plus le sujet, il semblerais que ce type de traitment sous PS v1 ne soit possible qu'en synchrone.

Pour de l'asynchrone ça s'annonce plus délicat à mettre en oeuvre car je n'ai pas vu de notion d'événement, hors WindowsForm, sous PS.

Pour le tuto je dois le mettre à jour, pour info j'en prépare un sur la signature de script.

Mais pour le moment je vais essayer de coder ça avec WMI.

Un début de solution :
[code:1]$RequeteWQL=\"Select * from __InstanceOperationEvent within 1 where TargetInstance ISA 'CIM_DataFile' and TargetInstance.name='c:\\temp\\test.txt'\"
$Requeteur= new-object Management.WQLEventQuery($RequeteWQL)

$Surveillant=new-object Management.ManagementEventWatcher $Requeteur
$Resultat=$Surveillant.WaitForNextEvent()
$Resultat.TargetInstance[/code:1]
Malheureusement je viens de me souvenir que WMI permet de trapper ce type d'événement mais pas l'utilisateur le déclenchant.
Et la classe FileSystemWatcher ne porte pas non plus cette infos.

J'ai regardé un peu plus le sujet, il semblerais que ce type de traitment sous PS v1 ne soit possible qu'en synchrone.

Pour de l'asynchrone ça s'annonce plus délicat à mettre en oeuvre car je n'ai pas vu de notion d'événement, hors WindowsForm, sous PS.

Effectivement les évènements WMI sont synchrones mais en regardant de plus près, il est possible de mettre un timeout sur l'attente d'évènements. Cela permet de faire un semblant d'asynchronisme. Cela donnerait si je reprends ton code:
[code:1]
$RequeteWQL=\"Select * from __InstanceOperationEvent within 1 where TargetInstance ISA 'CIM_DataFile' and
TargetInstance.name='c:\\temp\\test.txt'\"
$Requeteur= new-object Management.WQLEventQuery($RequeteWQL)

$Surveillant=new-object Management.ManagementEventWatcher $Requeteur
$options = new-object system.management.EventWatcherOptions
$options.TimeOut = [timespan]::FromSeconds(2)
$Surveillant.options = $options

$Resultat=$Surveillant.WaitForNextEvent()
$Resultat.TargetInstance
[/code:1]

Malheureusement je viens de me souvenir que WMI permet de trapper ce type d'événement mais pas l'utilisateur le déclenchant.
Et la classe FileSystemWatcher ne porte pas non plus cette infos.

C'est justement la raison pour laquelle je préconisais à Franconero d'activer l'audit NTFS des fichiers et à coder un script qui surveillerait (avec les evènements WMI) le journal d'audit sur un numéro d'event particulier.

Pour le tuto je dois le mettre à jour, pour info j'en prépare un sur la signature de script.

Si tu le souhaites, nous pourrons ajouter ton tuto sur la signature des scripts dans notre rubrique \"Tutoriaux\". C'est d'ailleurs l'ambition de ce site : que chacun puisse apporter sa pierre afin de faire gagner à tous un temps précieux dans les tâches quotidiennes.

Que la force soit avec toi...
Arnaud

Chose promise, chose due. Je viens de publier le script qui permet de monitorer la création de fichiers dans un répertoire.

Il s'agit juste d'un exemple pour illuster le monitoring WMI en PowerShell. Ca ne résouds pas le problème de Franconero mais ça va le mettre sur la voie pour détecter l'arrivée d'un évènement d'audit dans le journal.

L'exemple est ici : powershell-scripting.com/index.php?optio...id=129&Itemid=71

Allez Franck on compte sur toi...

@++

Arnaud<br><br>Message édité par: Arnaud, à: 17/04/07 22:52