Benutzer mit den meisten Antworten
Erstelldatum - Änderungsdatum / Dateien / Ordner

Frage
-
Hallo,
kurze Verständnisfrage.
Das CreationTime ist ja gar nicht das erste Erstelldatum, sondern das aktuelle, wenn evtl. nur eine Datei verschoben wird. Viel mehr ist es das LastWriteTime Flag/Attribut.
Könnte ein Virenscanner so was auch manipulieren?
Wenn ja, gibt es da Erklärungen, Links im Netz.
Ordnerstruktur - erstellt in 2012, ich kopiere jetzt alle in ein anderes Verzeichnis.
Könnte ich dennoch das ursprüngliche Jahr 2012 erfragen, wenn ja, wie?
Danke für Tipps im Voraus.
Viele Grüße Sandra
- Bearbeitet Sandra Maier Freitag, 13. März 2015 12:10
Antworten
-
Hallo Sandra,
der BackgroundWorker verwendet den Threadpool und da sollte man an Prioritäten nicht rumfummeln. Auch wird das Problem damit vermutlich nicht lösen, vermutlich ist die das Dateisystem hier evtl. sogar die Verzeichniseinträge im NTFS "im Stress".
Zuerst würde ich versuchen, ob es mit etwas Pause zwischen den Löschungen - Thread.Sleep(einige 100ms) - zu beheben ist. Ob das Löschen länger dauert, sollte dabei weniger ausmachen.
Auch sollte man das Iterieren ressourcenschonender mittels DirectoryInfo.EnumerateFiles ausführen. Dabei kann man gleich den Vergleich auf das Datum (UTC) einbauen, wie es ein Beispiel dort vormacht (und auf eher überflüssiges protokollieren wie von "ich tue der Datei nichts" verzichten).
Bezüglich SATA vs SSD:
SSDs sind zwar bei wahlfreien Zugriffen weit überlegen. Beim Löschen wird aber i. a. ein TRIM (detaillierter ist der englische Artikel) ausgeführt, während bei magnetischen Datenträgern NTFS die Einträge als gelöscht markiert. Bei sehr vielen (hier anscheinend kleinen) Dateien könnte sich das aufstauen - ob es wirklich schneller wird, wäre abzuwarten (ich habe es nie getestet) - zumindest nicht zu viel Hoffnung auf die Hardware setzen.
Gruß Elmar
- Als Antwort markiert Sandra Maier Samstag, 14. März 2015 11:23
Alle Antworten
-
Hallo,
manche Frage wäre gar keine, wenn man die Antworten lesen würde, hier inbes. der MS KB Link.
Ansonsten kann jedes Datum durch anderen Programme verändert werden. Virenscanner werden das Erstell-/ Änderungsdatum i. a. nicht verändern, da sie die Datei beim Prüfen nur Lesen - und bei Befall in Quarantäne verschieben.
Gruß Elmar
-
Hallo Sandra,
prinzipiell kann jedes Programm mit Schreibrechten auf eine Datei das Erstell- oder Änderungsdatum einer Datei ändern.
In C# sieht das etwa so aus:
//datiert das Erstelldatum auf Heute vor zwanzig Tagen new FileInfo(pfadZurDatei).CreationTime = DateTime.Now - TimeSpan.FromDays(20);
Das geht auch mit LastWriteTime und LastAccessTime.
Mehr dazu findest du unter [1].
Es gibt auch Tools um diese Datumsangaben zu ändern.
Ich halte es für unwahrscheinlich, dass ein Virenscanner diese Datumsangaben ändert.Einmal überschrieben, können diese Datumsangaben nur aus einem Backup der Datei wiederhergestellt werden.
[1] FileSystemInfo.LastWriteTime-Eigenschaft
Viele Grüße
J. Oldoerp
Entwickler-Hotline für MSDN Online Deutschland
Disclaimer:
Bitte haben Sie Verständnis dafür, dass wir hier auf Rückfragen gar nicht oder nur sehr zeitverzögert antworten können.
Bitte nutzen Sie für Rückfragen oder neue Fragen den telefonischen Weg über die MSDN-Entwickler-Hotline: http://www.msdn-online.de/Hotline
Es gelten für die MSDN-Entwickler-Hotline und dieses Posting diese Nutzungsbedingungen, Hinweise zu Markenzeichen, Informationen zur Datensicherheit sowie die gesonderten Nutzungsbedingungen für die MSDN-Entwickler-Hotline.
- Bearbeitet J. Oldoerp Freitag, 13. März 2015 12:43
-
manche Frage wäre gar keine, wenn man die Antworten lesen würde, hier inbes. der MS KB Link.
Hallo Elmar,was soll ich sagen, keine Frage Du hast Recht! Man merkt Deine Erfahrung.D:\NTFS1 -
Erstellungsdatum und -zeit des Ordners bleiben gleich, während Änderungsdatum
und -zeit geändert werdenEs geht immer noch, um das Vorgängerthema.Ich lösche alle Dateien rekursiv, anschließend die Ordner, sofern diese wirklich leer sind.Das passt alles und funktioniert.
Lediglich wenn wirklich sehr viele Dateien drin sind, macht das ganze mit
dem BackgroundWorker Probleme, Anwendung hängt trotzdem.Idee vielleicht noch, dem BackgroundWorker eine sehr kleine Priorität zuzuweisen, wenn das geht? Vielleicht weißt Du das?Ansonsten habe ich das aus der Hauptanwendung genommen, eine kleine TestAPP erstellt, der Kunde sendet mir Ende Woche mal viele Dateien zu. (Hoffe ich)
Dann teste ich es mit SATA Festplatte und mit SDD.
Wenn SDD deutlich schneller ist, keine Probleme macht ist die Ursache
bestätigt.Ja so sind Kunden, die Windows Aufgabenplanung macht das wahrscheinlich ohne Probleme,Dann müßte ich das Script bereit stellen, wenn dann wieder was falsch ist.
Danke nochmals und liebe Grüße Sandra -
Hallo Sandra,
der BackgroundWorker verwendet den Threadpool und da sollte man an Prioritäten nicht rumfummeln. Auch wird das Problem damit vermutlich nicht lösen, vermutlich ist die das Dateisystem hier evtl. sogar die Verzeichniseinträge im NTFS "im Stress".
Zuerst würde ich versuchen, ob es mit etwas Pause zwischen den Löschungen - Thread.Sleep(einige 100ms) - zu beheben ist. Ob das Löschen länger dauert, sollte dabei weniger ausmachen.
Auch sollte man das Iterieren ressourcenschonender mittels DirectoryInfo.EnumerateFiles ausführen. Dabei kann man gleich den Vergleich auf das Datum (UTC) einbauen, wie es ein Beispiel dort vormacht (und auf eher überflüssiges protokollieren wie von "ich tue der Datei nichts" verzichten).
Bezüglich SATA vs SSD:
SSDs sind zwar bei wahlfreien Zugriffen weit überlegen. Beim Löschen wird aber i. a. ein TRIM (detaillierter ist der englische Artikel) ausgeführt, während bei magnetischen Datenträgern NTFS die Einträge als gelöscht markiert. Bei sehr vielen (hier anscheinend kleinen) Dateien könnte sich das aufstauen - ob es wirklich schneller wird, wäre abzuwarten (ich habe es nie getestet) - zumindest nicht zu viel Hoffnung auf die Hardware setzen.
Gruß Elmar
- Als Antwort markiert Sandra Maier Samstag, 14. März 2015 11:23