Question Comp. d'objets : différences de résultats (Résolu)

Le mieux, enfin à prioris, est d'utiliser Compare-object.

Ensuite de déterminer les nouveaux fichiers et ceux supprimés cela semble relativement aisé, bien que...
Quant aux fichiers renommés cela s'avère un peu plus délicat, car la \"clé primaire\" se trouve être le nom du fichier, compare-objet, qui travaille sur des ensembles, ne peut pas nous 'dire' si c'est un nouveau fichier ou un fichier renommé, il y voit seulement une diffèrence.

Je regarde ça de plus près.

Salut,
voici un début de solution. Comme le Cmdlet Compare-Object est un opérateur ensembliste on ne peut retrouver que des informations du type \"existe\" \"n'existe pas\".
Les limites :
1)Une partie des modifications peuvent ne pas être vues, ex
date1 ->Photo 1
Date1+5mn opération create dir, create file 1 , create file 2
Date2 opération delete file 2
Date3 Photo 2: les opérations sur file 2 n'apparaissent pas.
Normal puisque NFTS n'assure pas ce service de versionning/historique
2)Une opération de renommage est vue comme une suppression+une création, on a donc 2 informations au lieu d'une.
Comme il n'y a pas de notion d'identifiant persistent, difficile de limiter ce 'bruit'. Sauf si l'on est certain que la date de céation d'un fichier est unique pour chaque entrée NTFS.

Donc on récupére les données d'origine dans $ancien et les nouvelles dans $new
[code:1]
$Ancien=get-childitem -r
$New=get-childitem -r
[/code:1]
On compare les 2 collections
[code:1]
compare-object $new $ancien -prop name -includeequal
[/code:1]
que l'on ventile dans 3 tableaux à l'aide de la fonction Répartir
[code:1]
Function Répartir ($list)
{
$global:Egaux =@()
$global:«»Supprime =@()
$global:Nouveaux =@()
foreach ($Item in $List)
{
switch ($Item.SideIndicator)
{
'==' {$global:Egaux +=$item}
'<=' {$global:Nouveaux +=$item}
'=>' {$global:«»Supprime +=$item}
}
}
}
[/code:1]
Ensuite on visualise le résultat à l'aide de la fonction visu
[code:1]
function visu
{
Write-host \"Ancien :\" -f Yellow
$ancien|ft fullname,CreationTime,lastwritetime,lastaccesstime
Write-host \"Nouveau :\" -f Yellow
$new|ft fullname,CreationTime,lastwritetime,lastaccesstime
Write-host \"Egaux :\" -f Green
$Egaux
Write-host \"Nouveaux :\" -f Green
$Nouveaux
Write-host \"Supprimé :\" -f Green
$Supprime
}
[/code:1]
On a donc
[code:1]
$Ancien=get-childitem -r
$New=get-childitem -r
répartir(compare-object $new $ancien -prop name -includeequal)
Visu
[/code:1]
Sur qq tests simples autour d'un répertoire et de 5 fichiers le résultat est correcte.Je te laisse effectuer des tests + importants.

Ensuite pour éviter les 2 informations lors d'un renommage de fichier, j'ai essayé cette piste :
[code:1]
#rename sans autre modification.
ren t3.txt t5.txt
#Nouvelle photo
$New=get-childitem -r
# Pour une opération de renommage on a 2 informations : un fichier supprimé(t3.txt) et un nouveau fichier(t5.txt)
Répartir (compare-object $new $ancien -prop name -includeequal)
visu

# on interroge sur la date de création et pas sur le nom
#DANS CE CAS, le résultat est ok mais on ne connait plus le nom
#Si on passe l'objet dans le pipe, l'information \"SideIndicator\" n'est pas propagée/ajoutée. A revérifier...
Répartir (compare-object $new $ancien -prop creationtime -includeequal)
visu
# Si on interroge sur les 2 propriétés on revient au premier cas, à savoir une interrogation uniquement sur le nom
Répartir (compare-object $new $ancien -prop creationtime,name -includeequal)
visu

#On essaie de retrouver les informations(creationtime,name,SideIndicator) au sein d'un objet
$A=compare-object $ancien $ancien -prop creationtime,name -includeequal
$n=compare-object $new $new -prop creationtime,name -includeequal
#On récupére une seule information (le fichier renommé se retrouve dans le tableau Egaux) mais on ne connait plus le nom d'origine du fichier (pas d'historique)
Répartir(compare-object $n $a -prop creationtime -includeequal -passthru)
visu
[/code:1]
Je ne suis pas certain que PS soit adapté à ce besoin. De plus la volumétrie à traiter jouera bien évidemment un rôle important.

Une autre approche serais d'utiliser un SGBD ou d'interroger le référentiel de sauvegarde (s'il le permet) ou encore le gestionnaire de source Subversion mais au prix d'une duplication de données, là tu as le versionning et l'historique.

Ce sera peut être une des évolutions de NTFS...

Salut,
sonic31 écrit:

Merci beaucoup .

De rien
sonic31 écrit:

Puisque qu'il me semblait qu'un objet importé était identique (mais mort) pourquoi cela ne fonctionne pas si $ancien est importé de l'itération précédente ?

Je ne suis pas sûr que les termes \"identique (mais mort)\"soient les bons dans ce contexte.
Je dirais \"Un objet valide à un instant T\"(cf. photo). Sans rentrer dans les détails car sous .NET il existe une notion de résurrection...
Ce que tu recharges est bien un objet mais c'est plutôt la représentation d'un objet, le fichier du disque.

Je suppose que l'erreur que tu avais
[code:1]
where-object {((get-childitem $rep -r $_) -eq $null
[/code:1]
est du au fait que $_ est lié à l'option -Filter, et n'a rien avoir avec un pb de persistance.
sonic31 écrit:

A noter que comme cela la charge devient vite problèmatique. Sur un serveur correct c'est + de 5 minute de traitement pour environ 1000 fichiers .

Là je pense que tu as un pb d'écriture des instructions du pipe
[code:1]
..| where-object {(($ancien | foreach {$_.name}) -notcontains $_.name)-and
($_.creationtime -lt $derniercheck)}`
[/code:1]
L'imbrication de boucle dans le pipe doit y être pour beaucoup et je ne suis pas certain, là faut étudier le code dans le détails, que ce pipe soit fluide.

Je ne sais pas si le parseur réorganise ni comment il fait mais essaie de placer ce test en premier
[code:1]
$_.creationtime -lt $derniercheck
[/code:1]
et ici il me semble qu'il y ait une redondance
[code:1]
($ancien | foreach {$_.name}) -notcontains $_.name
[/code:1]
je verrais plutot ceci
[code:1]
($ancien -notcontains $_.name)
[/code:1]