Wie gehe ich mit meinen temporären Daten um?

[Der schöne Günther]

Eine Anwendung erstellt munter Dateien in

Delphi-Quellcode:

TPath.GetTempPath()

(%userprofile%\AppData\Local\Temp). Bislang ist anscheinend jeder davon ausgegangen dass Windows diese Dateien irgendwann wohl von alleine löschen wird.

Ich stelle gerade etwas schockiert fest, dass dem wohl nicht so ist. Wie kommen wir aus dieser Nummer wieder heraus? Die temporären Dateien werden teilweise mit externen Programmen wie bspw. einem PDF-Betrachter geöffnet. Ich weiß also nicht wann sie nicht mehr in Gebrauch sind.

Meine Idee wäre nun folgende:

• Die Daten gehen ab sofort in ein Unterverzeichnis des Temp-Ordners
• Immer wenn man eine Datei in den Temp-Ordner werfen will wird vorher geprüft ob sich Dateien darin befinden die gelöscht werden dürfen (bspw. älter als 5 Tage)
• Diese werden entfernt, erst dann geht es weiter

Das sollte relativ sicher sein, oder? Ich will nicht die ganze Zeit erstelle Dateien im Hintergrund tracken. Es kann auch sein dass die Anwendung wochen- und monatelang am Stück durchläuft, die Systeme haben auch nur eine relativ kleine SSD: Prüfen bei Anwendungsstart und -Ende reicht nicht.

Hat noch jemand eine bessere Idee? Ich weiß noch dass man in der Registry eine Liste von Dateien anlegen kann die beim nächsten Reboot gelöscht werden sollen, aber das ist uU zu spät und man braucht dafür Admin-Rechte.

[Zacherl]

Vielleicht zu umständlich, aber mit NtQuerySystemInformation kannst du alle offenen Handles enumerieren. Die kannst du dann mit deinen temporären Dateien abgleichen und wüsstest so zumindest schonmal, welche Datei noch irgendwo geöffnet ist.

Anderer Ansatz wäre das Starten der externen Programme in einem extra Thread, den du mit WaitForSingleObject auf Beendigung des Prozesses warten lässt.

[nahpets]

Hallo,

habe mir mal vor längerer Zeit ein Progrämmelke dafür geschrieben, dass auf den Servern alte Log-Dateien wegwerfen sollte.

Man kann die Verzeichnisse per Dialog auswählen, und angeben, wie alt (oder älter) Dateien sein müssen, die gelöscht werden sollen.

Per Button wird das dann gemacht.

Da das für den Serverbetrieb nicht sehr clever ist, kann man das Programm auch mit einem beliebigen Parameter aufrufen.
Dann räumt es auf und beendet sich wieder.

Das dann in den Taskplaner gepackt und schon muss man sich nicht mehr kümmern.

Schau mal, vielleicht kannste damit ja was anfangen.

(Nutzt 'nen Dialog aus der JVCL.)

[Luckie]

Zitat:

Zitat von Der schöne Günther (Beitrag 1314602)

Eine Anwendung erstellt munter Dateien in

Delphi-Quellcode:

TPath.GetTempPath()

(%userprofile%\AppData\Local\Temp). Bislang ist anscheinend jeder davon ausgegangen dass Windows diese Dateien irgendwann wohl von alleine löschen wird.

Woher soll Windows wissen, ob die Dateien noch gebraucht werden?

Du weißt doch welche Dateien du erstellt hast. Lösche sie beim Beenden deines Programms. Fertig. Nix mit offenen Handles suchen oder so.

[Daniel]

Er schreibt, dass die Anwendung ggf. zu lang läuft, so dass zwischen Programmstart und -Ende zusätzlich geprüft und bei Bedarf gehandelt werden muss.

[jfheins]

Zitat:

Zitat von Der schöne Günther (Beitrag 1314602)

Hat noch jemand eine bessere Idee? Ich weiß noch dass man in der Registry eine Liste von Dateien anlegen kann die beim nächsten Reboot gelöscht werden sollen, aber das ist uU zu spät und man braucht dafür Admin-Rechte.

Das sollte auch ohne Adminrechte gehen. Die Doku zu MoveFileEx sagt:

Zitat:

If dwFlags specifies MOVEFILE_DELAY_UNTIL_REBOOT and lpNewFileName is NULL, MoveFileEx registers the lpExistingFileName file to be deleted when the system restarts.

Ansonsten(die Sache mit dem externen PDF-Viewer) würde ich sagen: Merke dir alle temporären Dateien in ner Liste und versuche einmal am Tag jede Datei zu löschen. Was nicht klappt, wird wohl noch verwendet.

[Luckie]

Zitat:

Zitat von Daniel (Beitrag 1314613)

Er schreibt, dass die Anwendung ggf. zu lang läuft, so dass zwischen Programmstart und -Ende zusätzlich geprüft und bei Bedarf gehandelt werden muss.

Aber den Bedarf kennt nur er. Windows ist nicht hellsichtig.

[Headbucket]

Wenn ich dich richtig verstanden habe, dann kopierst du Dateien in den Temp-Ordner um sie dann zu öffnen. Danach können sie wieder gelöscht werden, richtig?

Was spricht dann dagegen, per StartAndWait darauf zu warten? Oder wie hier bereits geschrieben in einen extra Thread auslagern. Die ganze Geschichte mit den 5 Tagen usw. finde ich fast etwas umständlich. Außer du startest die Datei mehrmals hintereinander und willst sie nicht jedes mal wieder in den Temp-Ordner kopieren.

Ich hatte schonmal den Fall, dass ich eine Datei aus der Datenbank öffnen wollte. Hier habe ich einfach folgende Funktion benutzt, die den Exitcode auswertet:

Delphi-Quellcode:

function StartAndWait(const ExecuteFile: string; ParamString: string = ''): boolean;
var
  SEInfo: TShellExecuteInfo;
  ExitCode: DWORD;
begin
  Result := False;
  if not FileExists(ExecuteFile) then Exit;
  FillChar(SEInfo, SizeOf(SEInfo), 0);
  SEInfo.cbSize := SizeOf(TShellExecuteInfo);
  with SEInfo do
    begin
      fMask := SEE_MASK_NOCLOSEPROCESS;
      Wnd := Application.Handle;
      lpFile := PChar(ExecuteFile);
      lpParameters := PChar(ParamString);
      nShow := SW_SHOWNORMAL;
    end;
  if ShellExecuteEx(@SEInfo) then
    begin
      repeat
        Application.ProcessMessages;
        Sleep(100);
        GetExitCodeProcess(SEInfo.hProcess, ExitCode);
      until (ExitCode <> STILL_ACTIVE) OR Application.Terminated;
      Result := True;
    end;
end;

begin
  [...]                     //Aus Datenbank in Temp-Order kopieren
  StartAndWait(ExecuteFile);//Starten und auf Beenden warten
  DeleteFile(ExecuteFile);  //Löschen
end;

Aber ich denke ja mal fast, dass du diese Methode schon ausgeschlossen hast. Wieso?

Grüße

[Daniel]

Wie viel kannst Du Deinen Anwendern zutrauen?
Ich hatte hier mal mit Office-Dokumenten zutun, die in einer Datenbank gespeichert wurden. Via Doppelklick hatte ich sie auch in den Temp-Ordner gelegt und dann per ShellExecute geöffnet. Zuerst war der Anwender glücklich, denn er sah das Dokument. Dann fing er ungnädigerweise an, das Dokument zu bearbeiten und auch zu speichern - auch das ging. Und über die Liste der letzten Dokumente hat er es jenseits unserer Anwendung in Excel wieder aufgerufen und weiter bearbeitet - unwissentlich, dass die Datei im Temp-Ordner nur "bedingt gut" aufgehoben war.
Bis dann irgendeine System-Reinigung zuschlug und die Datei ins Aus beförderte.

[Dejan Vu]

Soweit ich mich erinnere, kann man auch die Namen der Temp-Dateien vorgeben, zumindest den Präfix.
Wenn das noch stimmt, lösche beim Programmstart einfach alle 'Deine' (alten) Tempdateien. Die, die gesperrt sind, sind offenbar noch in Verwendung.

Oder ist das ein Service? Na dann, einfach regelmäßig (dann kannst Du dir die auch merken).

[Sherlock]

1/2 OT: Sehr löbliches Vorhaben, daß viel zu wenig Nachahmer findet. Ich hatte neulich 4GB an temporären Dateien und Ordnern aus meinem ein Jahr altem System gelöscht, da meine Programme sowas nicht verwenden, weiss ich daß das Müll von den paar anderen Programmen sein muss, die sonst noch auf meinem Rechner werkeln.

Sherlock

[Rollo62]

Löblich finde ich das auch, aber ...

War das nicht genau der Sinn des Temp-Ordners, das er von Zeit zu Zeit mal gelöscht werden soll ?
Ich denke nicht das MS hier unbedingt gelöscht haben möchte, zumindest macht das aus meiner Erfahrung kaum ein Programm.

Ich bin immer ganz froh wenn die Platte mal wieder eng wird das ich da noch ein paar GB wieder freischaufeln kann.

Edit:
Wenn ich Temp Daten verwende, dann in eigenen Unterverzeichnissen, da habe ich dann die volle Kontrolle drüber.

Rollo

[baumina]

Solche Dateien bräuchten ein Selbstzerstörungsflag, so Mission-impossible-mäßig, die Datei zerstört sich in 3 Stunden selbst.

[nahpets]

Zitat:

Zitat von Sherlock (Beitrag 1314639)

1/2 OT: Sehr löbliches Vorhaben, daß viel zu wenig Nachahmer findet.

Dem genau ist leider so. Eigene Dateien kann man (mit etwas Disziplin) verwalten und dort für Ordnung sorgen (z. B. eigenes Verzeichnis unterhalb von Temp und beim Programmende alles wegwerfen, was da noch übrig ist). Soll der Anwender da nicht ausversehen (wie Daniel beschrieb) mit den Dateien arbeiten, dann kommt auf die Dateien das Schreibschutzattribut drauf, damit können Excel und Co. da nicht mehr Schreiben und der Anwender wird drauf hingewiesen. Er kann ja dann "speichern unter"-wählen und hat ab da die Verantwortung für die veränderte Datei.

Zitat:

Zitat von Sherlock (Beitrag 1314639)

Ich hatte neulich 4GB an temporären Dateien und Ordnern aus meinem ein Jahr altem System gelöscht, da meine Programme sowas nicht verwenden, weiss ich daß das Müll von den paar anderen Programmen sein muss, die sonst noch auf meinem Rechner werkeln.

Sherlock

Darin siehe ich das Hauptptoblem. Um dem abzuhelfen, gibt es bei mir im Autostart eine Batchdatei mit dem schönen Namen

Delphi-Quellcode:

DelTemp.bat

und so sieht sie aus:

Delphi-Quellcode:

@echo temporaere Dateien loeschen
if exist o:\~$PVRTmp0$\*.* rd /s /q o:\~$PVRTmp0$
if exist e:\~$PVRTmp0$\*.* rd /s /q e:\~$PVRTmp0$
if exist c:\temp\acrord32_sbx\*.* rd /s /q c:\temp\acrord32_sbx
if exist "c:\Dokumente und Einstellungen\stephan\Lokale Einstellungen\Temporary Internet Files\Content.IE5\*.*" rd /s /q "c:\Dokumente und Einstellungen\stephan\Lokale Einstellungen\Temporary Internet Files\Content.IE5"
if exist "c:\Dokumente und Einstellungen\stephan\Cookies\*.*" rd /s /q "c:\Dokumente und Einstellungen\stephan\Cookies"
if exist "c:\wincmd5\$wc\*.*" del /q c:\wincmd5\$wc\*.*"
if exist "c:\temp\*.*" del /q c:\temp\*.*"
if exist "c:\Dokumente und Einstellungen\All Users\Anwendungsdaten\Avira\AntiVirus\LogFiles\*.*" rd /s /q "c:\Dokumente und Einstellungen\All Users\Anwendungsdaten\Avira\AntiVirus\LogFiles"
if exist "c:\Dokumente und Einstellungen\All Users\Anwendungsdaten\Avira\AntiVirus\Reports\*.*" rd /s /q "c:\Dokumente und Einstellungen\All Users\Anwendungsdaten\Avira\AntiVirus\Reports"

Das sind die mit bekannten Stellen, an denen diverse andere ihren Müll hinterlassen und dort wird dann beim Rechnerstart aufgeräumt. Was noch in Benutzung ist, kann von der Batchdatei nicht gelöscht werden und ist dann ggfls. beim nächsten Mal dran.

Seit dem wird die Festplatte nicht mehr so schnell voll.

[Der schöne Günther]

Danke für die vielen Antworten bisher!

Ich will es an dieser einen Anwendung gar nicht zu sehr festmachen. Dem Anwender kann ich (im negativen Sinne) alles zutrauen. Auch dass er 500 mal den PDF-Betrachter offen lässt und wieder ins Hauptprogramm wechselt.

Ich hätte gedacht dass Windows mit der Zeit automatisch das macht, wenn ich im Explorer auf Bereinigen gehe. Da es da wohl nichts gibt muss man periodisch wohl alles rauswerfen. Ich dachte dann an so etwas in der Art. Würdet ihr das so absegnen oder übersehen ich noch etwas?

Delphi-Quellcode:

unit App.TempFileManager;

interface uses System.TimeSpan, System.Classes, System.Types;

type
   TTempFileManager = class(TObject)
      protected const
         guid =  '{255AC97A-A42E-44F3-86E1-DF00B7C67FD5}';
      protected var
         maxFileAge: TTimeSpan;
      protected
         function getPath(): String;
         function findFiles(const olderThan: TDateTime): TStringDynArray;
      public var
         cleanupOnEveryRequest: Boolean;
      public
         constructor Create(const maxFileAge: TTimeSpan); overload;
         constructor Create(const maxFileAgeHours: Integer); overload;

         procedure doCleanup(const recursive: Boolean = False);
         /// <summary>
         ///     Liefert einen neuen Dateinamen im <see cref="Path" />-Verzeichnis
         /// </summary>
         /// <param name="extension">
         ///      Optionale Dateinamenerweiterung. Beispiel: <c>.pdf</c> oder
         ///    <c>txt</c>. Das Trennzeichen-Prefix ist optional
         /// </param>
         function getTempFileName(const extension: String = ''): String;
         /// <summary>
         ///     Liefert einen <c>TFileStream</c> auf eine neue, im
         ///    <see cref="Path"/>-Verzeichnis erstellte Datei
         /// </summary>
         /// <param name="extension">
         ///      Optionale Dateinamenerweiterung. Beispiel: <c>.pdf</c> oder
         ///    <c>txt</c>. Das Trennzeichen-Prefix ist optional
         /// </param>
         function getTempFile(const extension: String = ''): TFileStream;
      public //properties
         property Path: String read getPath;
   end;

implementation uses System.IoUtils, System.SysUtils, System.DateUtils;

type
   TDateTimeHelper = record helper for TDateTime
      function IncSpan(const timeSpan: TTimeSpan): TDateTime;
      function DecSpan(const timeSpan: TTimeSpan): TDateTime;
   end;

   TFileHelper = record helper for TFile
      class procedure TryDelete(const Path: String); static;
   end;

{ TTempFileManager }

constructor TTempFileManager.Create(const maxFileAgeHours: Integer);
var
   asTimeSpan: TTimeSpan;
begin
   asTimeSpan := TTimeSpan.FromHours(maxFileAgeHours);
   self.Create(asTimeSpan);
end;

constructor TTempFileManager.Create(const maxFileAge: TTimeSpan);
begin
   inherited Create();
   self.maxFileAge := maxFileAge;
end;

procedure TTempFileManager.doCleanup(const recursive: Boolean = False);
var
   mustBeOlderThan:   TDateTime;
   foundFiles:         TStringDynArray;
   filePath:         String;
begin
   mustBeOlderThan := Now().DecSpan(maxFileAge);
   foundFiles := findFiles(mustBeOlderThan);

   for filePath in foundFiles do TFile.TryDelete(filePath);
end;

function TTempFileManager.findFiles(const olderThan: TDatetime): TStringDynArray;
var
   predicate: TDirectory.TFilterPredicate;
begin
   if not TDirectory.Exists(Path) then Exit(nil);

   predicate :=
      function(const Path: string; const SearchRec: TSearchRec): Boolean
      begin
         // SearchRec.TimeStamp bezeichnet das "Geändert am"
         Result := CompareDateTime(SearchRec.TimeStamp, olderThan) = LessThanValue;
      end;

   Result := TDirectory.GetFiles(Path, TSearchOption.soTopDirectoryOnly, predicate);
end;

function TTempFileManager.getTempFileName(const extension: String): String;
var
   filename: TFileName;
begin
   if cleanupOnEveryRequest then doCleanup();

   filename := TPath.GetGUIDFileName();
   if not extension.IsEmpty() then begin
      if not extension.StartsWith(TPath.ExtensionSeparatorChar) then
         filename := filename + TPath.ExtensionSeparatorChar;
      filename := filename + extension;
   end;

   Result := TPath.Combine(Path, filename)
end;

function TTempFileManager.getPath(): String;
begin
   Result := TPath.GetTempPath();
   Result := TPath.Combine(Result, guid);
end;

function TTempFileManager.getTempFile(const extension: String): TFileStream;
var
   path: String;
begin
   path := getTempFileName(extension);
   if TFile.Exists(path) then TFile.Delete(path);
   Result := TFile.Create(path);
end;

{ TDateTimeHelper }

function TDateTimeHelper.IncSpan(const timeSpan: TTimeSpan): TDateTime;
begin
   Result := System.DateUtils.IncMilliSecond(self, Round(timeSpan.TotalMilliseconds));
end;

function TDateTimeHelper.DecSpan(const timeSpan: TTimeSpan): TDateTime;
begin
   Result := System.DateUtils.IncMilliSecond(self, Round(-timeSpan.TotalMilliseconds));
end;

{ TFileHelper }

class procedure TFileHelper.TryDelete(const Path: String);
begin
   try
      Delete(Path);
   except
      on EDirectoryNotFoundException do;
      on EFileNotFoundException do;
      on EInOutError do;
   end;
end;

end.

[samso]

Wenn man möchte kann man die o.g. Batchdatei dann noch mit "delage32.exe" (Download unter: Horst Schaeffer's Software Pages) anreichern.

[SMO]

Zitat:

Zitat von Der schöne Günther (Beitrag 1314602)

Bislang ist anscheinend jeder davon ausgegangen dass Windows diese Dateien irgendwann wohl von alleine löschen wird.

Nö, das ist mir schon länger bekannt. Dafür gibt es in Windows die "Datenträgerbereinigung" (cleanmgr.exe). Oder eben von Zeit zu Zeit %tmp% in die Adressleiste des Windows-Explorers eingeben und dann manuell löschen.

Zitat:

Zitat von baumina (Beitrag 1314652)

Solche Dateien bräuchten ein Selbstzerstörungsflag, so Mission-impossible-mäßig, die Datei zerstört sich in 3 Stunden selbst.

So etwas ähnliches gibt es. Nennt sich FILE_FLAG_DELETE_ON_CLOSE. Habe ich schon erfolgreich für temporäre Dateien benutzt. Erklärung siehe MSDN CreateFile. Man beachte auch FILE_ATTRIBUTE_TEMPORARY, damit wird eine Datei so lange wie möglich im Arbeitsspeicher gehalten, bevor sie auf Platte geschrieben wird.

[Der schöne Günther]

Ja, das Flag benutzt wahrscheinlich 7-Zip, weshalb man fast keine einzige Datei in Archiven mit einem Doppelklick öffnen kann da er immer die temporären Dateien schon löscht bevor das Anzeige-Programm überhaupt die Chance hatte es zu öffnen.

[SMO]

Das wäre dann ein Bug von 7-Zip. Wenn man das Flag korrekt benutzt, kann es sehr hilfreich sein.

Ich habe auch gerade mal nachgeschaut: Windows führt die Datenträgerbereinigung automatisch aus, aber wohl erst wenn der Speicherplatz knapp wird. Ein entsprechender Task ist in der "Aufgabenplanung" definiert. Man könnte sich leicht einen eigenen anlegen, der die Datenträgerbereinigung öfter ausführt, z.B. einmal wöchentlich.

[Der schöne Günther]

Tatsächlich. "Aufgaben planen" -> [...] -> Vom System verwendete Wartungsaufgabe zum Starten einer unbeaufsichtigten automatischen Datenträgerbereinigung, sobald der freie Speicherplatz zur Neige geht.

Das schaue ich mir mal näher an...

[SMO]

Man kann sich per "cleanmgr.exe /sageset:#" (# = Zahl von 0 bis 65535) ein Profil definieren, das dann per "cleanmgr.exe /sagerun:#" ausgeführt wird. So könnte man z.B. nur das Löschen der temporären Dateien auswählen und den Befehl per Autostart oder Aufgabenplanung aufrufen. Mehr zu den Parametern hier.

[p80286]

Warum so ein Eiertanz?

Code:

del %temp%\*.tmp

und es ist wieder Platz. Schön wäre auch wenn ein Programm seinen Mist selbst wegräumen würde....

Gruß
K-H

[Luckie]

GetTempFilename in Kombination mit CreateFile und dem Flag FILE_FLAG_DELETE_ON_CLOSE und man muss sich um nichts mehr kümmern. Wahrscheinlich wird die Datei sogar gelöscht, wenn man selber vergisst beim Beenden seines Programms das Datei-Handle zu schließen und es dann beim Beenden des Prozesses von Windows geschlossen wird.

[Dejan Vu]

Der nach dem Schließen der eigenen Anwendung noch geöffnete PDF-Viewer, der eine derart getaggte Datei geöffnet hat, lässt das zu? Das Problem ist hier, das Temp-Dateien nach dem Schließen der eigenen Anwendung noch in Gebrauch sind.

[Luckie]

Das ist ein anderer Fall.

[Dejan Vu]

Äh, eigentlich hatte ich diesen Fall hier (also den Thread) genauso verstanden.

[Sir Rufo]

Weder noch, es geht um temporäre Dateien im Allgemeinen.

Dies kann man aber nicht pauschal behandeln, da es eben unterschiedliche Beweggründe für diese temp. Dateien gibt (Anzeige/Bearbeitung in externer Anwendung, Zwischenspeicher, etc.). Abhängig davon gibt es dann Strategien diese Dateien aufzuräumen (von automatisch über eine Batch-Datei beim Start bis zu "Lass das mal den Vatti (Windows) machen").

[Dejan Vu]

Zitat:

Zitat von Sir Rufo (Beitrag 1314845)

Weder noch, es geht um temporäre Dateien im Allgemeinen.

Zitat:

Zitat von Der schöne Günther (Beitrag 1314602)

Eine Anwendung erstellt munter Dateien in

Delphi-Quellcode:

TPath.GetTempPath()

... Die temporären Dateien werden teilweise mit externen Programmen wie bspw. einem PDF-Betrachter geöffnet. Ich weiß also nicht wann sie nicht mehr in Gebrauch sind.

Das ist Ansichtssache einerseits und Wochenende andererseits.

[Luckie]

Das Thema steht in der "Sparte "Programmieren allgemein" und nicht in der Sparte "Betriebssysteme", daher bin ich davon ausgegangen, dass es um das eigene Programm geht und wie wir Programmierer damit umgehen.

[Dejan Vu]

Stimmt ja auch alles.
Und nach drei Seiten driftet eh so ziemlich jedes Thema ins Allgemeine.

[jobo]

Apropos Wochenende:

Neben dem Speicherplatzverbrauch- der m.E. heutzutage nicht so sehr schmerzt- scheint mir die Arbeit mit temporären Dateien, die später übschrieben oder gelöscht werden am übelsten.
Das gilt natürlich nicht primär für PDF, aber das Beispiel von Daniel (Excel & Co) ist ganz plastisch.
Welchen Mechanismus ich also auch immer für die Bereinigung nutze. Toll wäre, der User kommt nie in die Verlegenheit mit "falschen" Dateien zu arbeiten.

Dazu würde ich primär darauf setzen, keine Spuren zu hinterlassen (besonders bei registrierten Dateiendungen), also keine Recent Einträge unter Verlauf und innerhalb der Programme, wenn möglich auch die "Speichern unter" Location nicht achtlos auf ..\temp\.. "liegen lassen".

Außerdem die Temp Dateien einfach verstecken, evtl auch den Temp Ordner.