[SOLUTION] Problème des fichiers temporaires non supprimés

[Pat91]

Bonjour à tous,

DOP version 6 Windows maintient bien vivant le bug concernant les fichiers temporaires non supprimés en fin de session. On pourrait même dire qu'il empire vu que ces fichiers semblent plus nombreux. Au fur et à mesure des sessions, ils continuent donc de s'empiler allègrement, consommant petit à petit votre espace disque et contribuant à la fragmentation. Le problème a été signalé il y a plus de 2 ans mais aucun progrès n'a été fait.

J'ai une solution à proposer à ce problème. Elle n'est pas très universelle car elle requiert un processeur de commandes plus puissant que CMD.EXE. Je fournis des exemples pour 4NT (le processeur que j'utilise) et Windows PowerShell

Solution 4NT

1. Créez le fichier batch suivant (dxo.btm):

[at] echo off
"C:\Program Files\DxO Labs\DxO Optics Pro v6\DxOOpticsPro6.exe"
delay 30
del %temp%\pil*.tmp
del %temp%\ptm*.tmp
del %temp%\t*.tmp
del /sxyz %temp%\AjBTBe18\
del /sxyz %temp%\sQCbDSIce\

(les chemins et noms de dossiers peuvent être différents pour vous - dxo.btm peut être sauvegardé où vous voulez)

2. Au lieu de lancer DxO directement, créez un raccourci qui lance ce batch (rappel: il ne fonctionenra pas avec CMD.EXE). DOP sera lancé et en fin de session, les fichiers temporaires seront nettoyés. Le délai de 30 secondes est nécessaire car DOP maintient ces fichiers verrouillés pendant un certain temps.

Solution Windows PowerShell

1. Créez le fichier batch suivant (dxo.ps1):

c:
cd "C:\Program Files\DxO Labs\DxO Optics Pro v6\"
Invoke-Item "DxOOpticsPro6.exe"
sleep 30
del $env:temp\pil*.tmp
del $env:temp\ptm*.tmp
del $env:temp\t*.tmp
del -force -recurse $env:temp\AjBTBe18\
del -force -recurse $env:temp\sQCbDSIce\

(les chemins et noms de dossiers peuvent être différents pour vous - dxo.ps1 peut être sauvegardé où vous voulez)

2. Créez un raccourci pour la commande suivante:

powershell.exe & 'C:\Program Files\DxO Labs\DxO Optics Pro v6\dxo.ps1'

Ceci suppose que vous avez installé Windows PowerShell (gratuit) sur votre système.

Les 2 solutions fonctionnent correctement pour moi.

Il y a un petit risque à supprimer tous les fichiers temporaires de nom t*.tmp mais le risque est faible. En général, les fichiers temporaires en cours d'utilisation sont verrouillés et il faudrait être très aventureux pour stocker ses propres données dans son dossier TEMP.

Si je peux régler le problème de cette manière, DxO peut le régler encore plus proprement, même si PACE refuse de fournir une solution à ce bug.

Le meilleur choix serait bien sûr d'abandonner ce système de protection complètement catastrophique.

[Pat91]

les chemins et noms de dossiers peuvent être différents pour vous

Notez que non seulement les noms des sous-dossiers seront différents pour vous mais également leur nombre.

[gerarto]

Petite question :
Les sous-répertoires au nom exotique sont bien sous Temp ?

Parce que j'ai bien de tels sous-répertoires, mais désespérément vides (y compris quand DxO tourne) : quel est alors l'intérêt de les suppimer ?

[Pat91]

Petite question :
Les sous-répertoires au nom exotique sont bien sous Temp ?

Bonjour,

Oui, ils sont bien sous TEMP, comme l'indique le contenu des scripts. Parfois ils sont vides, parfois ils ne le sont pas. Cela dépend de ce que l'on a fait pendant la session.

[Pat91]

À noter également que DxO Film Pack doit être lancé avec le même genre de batch. Il génère des fichiers temporaires similaires.

[Pat91]

Parce que j'ai bien de tels sous-répertoires, mais désespérément vides (y compris quand DxO tourne) : quel est alors l'intérêt de les suppimer ?

Attention également: les fichiers générés ont l'attribut "hidden". Selon les options de Windows Explorer, ils ne sont donc pas forcément visibles.

[gerarto]

Bonjour,

Oui, ils sont bien sous TEMP, comme l'indique le contenu des scripts. Parfois ils sont vides, parfois ils ne le sont pas. Cela dépend de ce que l'on a fait pendant la session.

C'est bien ce que j'avais cru comprendre de la lecture des scripts, mais comme je ne suis pas familier de ce type de script...

Sinon, j'ai bien deux sous-répertoires, un vide, l'autre avec seulement 4 fichiers anciens de 2 ko chacun (fichiers et dossiers cachés visibles).

Par contre les fichiers **.tmp sont bel et bien là sous temp et c'est vrai que ça fait pas mal de fichiers : environ 400Mo depuis la dernière purge de temp début juillet.

Donc merci.

[Pat91]

Il y a un petit risque à supprimer tous les fichiers temporaires de nom t*.tmp

Chez moi, j'ai noté que le préfixe pour ces fichiers était toujours t15 (t15*.tmp). On peut donc réduire le risque à epsilon en remplaçant t*.tmp par t15*.tmp dans les batches (ou par le préfixe correspondant pour vous).

Il n'est pas impossible non plus que les noms de sous-dossiers et les préfixes changent après l'enregistrement de la clé. Je vérifierai ça quand j'aurai acheté la licence.

[gerarto]

Je confirme les préfixes pil* ptm* et t* dans mon cas : versions activées V5 et V6

Je pense que t15* est valide : dans mon cas, j'ai 727 occurences de pil*, 722 de ptm* et722 de t15* (contre 737 de t*)

[titroy]

Bonjour,

Oui, ils sont bien sous TEMP, comme l'indique le contenu des scripts. Parfois ils sont vides, parfois ils ne le sont pas. Cela dépend de ce que l'on a fait pendant la session.

+1
Je confirme également : je les supprime régulièrement (inclus dans le run de ccleaner...).
Curieusement la taille des fichiers et leur nombre sont quasi invariants.

[mediator]

+1
Je confirme également : je les supprime régulièrement (inclus dans le run de ccleaner...).
Curieusement la taille des fichiers et leur nombre sont quasi invariants.

+1 Même méthode  : suppression des fichiers avec CCleaner. Et ensuite avec l'outil Quickclean de Mc Afee. Après un batch des plusieurs centaines de photos, on récupère pas mal de gigas 

[John Lloyd]

Merci beaucoup Pat91 pour cette info et la solution que tu proposes  Franchement impressionnant !

Au fait, tu veux pas postuler chez DXO 

Cordialement 

[barbozaure]

... Au fait, tu veux pas postuler chez DXO  ...

si je ne m'abuse, ça a failli se faire fin 2007 ...
mais l'équipe DxO était n'avait déjà pas besoin de béta-testeur   
pour mieux comprendre : http://www.chassimages.com/forum/index.php/topic,26153.msg403973.html#msg403973

pour ce qui est du volume de fichiers résiduels après traitement DxO
il est passé de 1.7Mo (v5) à 12Mo voir 20Mo (v6) selon le nombre et les photos traitées
par habitude, je nettoie également avec ccleaner ...

[Pat91]

Voir variante dans ce fil.

[titroy]

Merci Pat.

En extrapolant, si on traite 50 fichiers (seulement), DxO laisse derrière lui entre..100 et 150
fichiers !!!!!!!! (entre 3 et 4 par image).

Ce n'est pas qu'un "simple" problème de suppression des fichiers 'temp' : c'est un problème de conception !!!!!!!!! et quelle incidence sur la performance !

Quand je pense que la limite recommandée dans les pref est de ne pas dépasser...500 images !

----> 2000 à 2500 fichiers temp, du jamais vu !!!! du n'importe quoi !

J'imagine l'état du disque (fragmentation) avec une utilisation intensive et professionnelle sans del entre chaque run de DxO.

Pour ma part, j'ai ouvert un incident auprés de DxO et j'invite les utilisateurs de la V6 à le faire.
Peut être que DxO réagira...
.
En attendant, j'exploite la V5, et tant pis pour les 39 € : je n'ai noté aucune différence dans la
qualité produite.
Un seul regret : l'ergonomie, c'est certain. (et mes 39 €, pour le principe et que je n'aime pas gacher)

A chaque version, ce qui marchait bien, ne fonctionne plus mais on a des plus qui à leur tout ne fonctionneront plus.
Grognon ? oui.....
Monsieur DxO, ce n'est pas professionnel du tout. 
 

[titroy]

Pat, pourrais tu expliquer les 2 dernières commandes du script ?
del /sxyz %temp%\AjBTBe18\
del /sxyz %temp%\sQCbDSIce\

merci

[Pat91]

Pat, pourrais tu expliquer les 2 dernières commandes du script ?
del /sxyz %temp%\AjBTBe18\
del /sxyz %temp%\sQCbDSIce\

Les switches utilisés avec la commande del ne fonctionnent qu'avec le processeur 4NT, pas avec CMD.

/sxyz signifie "supprimer tous les fichiers et les sous-répertoires à partir du répertoire indiqué, en incluant les fichiers cachés et en lecture seule et sans demander de confirmation". On n'a pas l'équivalent avec CMD.EXE (console Windows). Il se plante sur les fichiers et les répertoires cachés ou système. 4NT est un vieux processeur de ligne de commande mais il fonctionne toujours bien. Je l'utilise depuis des lustres mais il n'est pas gratuit (http://www.jpsoft.com/). C'est pourquoi j'ai proposé en seconde solution Windows PowerShell car il est disponible pour tout le monde (http://www.microsoft.com/windowsserver2003/technologies/management/powershell/download.mspx)

%temp% renvoie le contenu de la variable d'environnement "temp", soit dans le cas général "c:\Documents and Settings\<utilisateur>\Local Settings\Temp" auquel on accole le nom des répertoires créés par DOP.

Est-ce plus clair?

[Phoebe]

Les switches utilisés avec la commande del ne fonctionnent qu'avec le processeur 4NT, pas avec CMD.

/sxyz signifie "supprimer tous les fichiers et les sous-répertoires à partir du répertoire indiqué, en incluant les fichiers cachés et en lecture seule et sans demander de confirmation". On n'a pas l'équivalent avec CMD.EXE (console Windows). Il se plante sur les fichiers et les répertoires cachés ou système. .

Avec CMD.EXE, tu ne peux pas utiliser "attrib -r -s" avant ?

[Pat91]

Avec CMD.EXE, tu ne peux pas utiliser "attrib -r -s" avant ?

Normalement si. Avec -h également. J'ai fait quelques tentatives. Ça fonctionne pour les fichiers mais j'avais systématiquement le prompt de confirmation au moment de la suppression des dossiers.

[gerarto]

Question : est-on sûr que les sous répertoires "AjBTBe18" et "sQCbDSIce" sont bien d'origine DxO ou Pace ?

En ce qui me concerne, je n'ai pas de tels noms, bien que j'aie effectivement deux sous répertoires dont les noms sont composés de suites de caractères.
Mais je "surveille" ces deux sous répertoires depuis quelque temps, et ça n'a pas l'air de bouger beaucoup.
Qui plus est leur taille est négligeable : 16 Ko pour l'un, 0 octets pour l'autre...

Donc, faut-il s'acharner à vouloir les supprimer à tout prix ?

Surtout si ça peut simplifier le batch

Pour voir, j'ai fait un simple .bat comme suit :

c:
cd %temp%
del %temp%\pil*.tmp
del %temp%\ptm*.tmp
del %temp%\t*.tmp

Et ça marche fort bien dans mon cas.

Il me semble qu'il suffirait ensuite de chaîner avec l'appel de l'exe de DxO : dans ce cas les fichiers seraient nettoyés avant l'appel de DxO et non à la fin de session, mais est-ce vraiment si grave, à défaut d'être élégant ?

Cela étant, il me reste quand même des scories d'origine DxO dans temp, du type :

DxOOpticsPro6_2009111519042966.dmp
DXOBC85.tmp

Mais qui semblent non systématiques : peut-être suite à plantage ?

Et ça n'enlève rien au « bug » de DxO, mais je me suis rendu compte que bien d'autre softs laissaient des paquets de m*rd* dans temp... 

[Pat91]

Question : est-on sûr que les sous répertoires "AjBTBe18" et "sQCbDSIce" sont bien d'origine DxO ou Pace ?

Bonjour,

J'ai bien précisé que les noms de sous-dossiers changeaient avec chaque système. J'ai également indiqué que selon les sessions, ils restaient vides ou contenaient des fichiers plus ou moins nombreux et plus ou moins importants. Cela dépend de ce que l'on a fait pendant la session.

Par ailleurs, le batch proposé pour CMD fonctionne ou non selon l'état de ses sous-répertoires. C'est ce que j'avais constaté lors de mes essais. En outre, je n'ai pas de commande Delay ou Sleep avec CMD. Toutefois, on peut toujours invoquer un utilitaire qui fait la même chose, ça doit se trouver. Ce délai de 30 sec. est nécessaire parce que les fichiers sont verrouillés bien longtemps après que la fenêtre DOP ait été fermée.

On peut effectivement choisir de supprimer ces fichiers au lancement plutôt qu'après la session mais l'inconvénient est qu'ils restent là entre 2 sessions et vu leur nombre et leur taille, ils contribuent de manière non négligeable à la fragmentation du disque.

DxOOpticsPro6_200911151904296 6.dmp
DXOBC85.tmp

Oui, ce sont des résidus de plantage.

[Pat91]

Et ça n'enlève rien au « bug » de DxO, mais je me suis rendu compte que bien d'autre softs laissaient des paquets de m*rd* dans temp... 

Oui mais dans ces quantités et tailles là et en cumulant systématiquement à chaque session, c'est plutôt rare.

[titroy]

Oui mais dans ces quantités et tailles là et en cumulant systématiquement à chaque session, c'est plutôt rare.

Vouiiii ! 20 photos traitées, reprise de la sortie sur 2 ou 3 photos...et 140 fichiers à la clé !
Du jamais encore vu. Ce n'est pas tant de les supprimer, on peut s'interroger sur le nombre ?
Ma V5 n'est pas encore à la retraite....