Dateidatum beim Entpacken auf Network Share mit internem ZIP

[Lufty]

Beim Entpacken auf ein Network Share mit dem internen ZIP-Packer wird das Datei-Datum am Ziel-Ort aktualisiert. Einem externer Packer belässt das Original-Datum.
Gibt es einen Workaround für den internen Packer, oder ist dies ein Wunsch für TC7 ?

Hinweis:
Beim normalen Kopieren von einer lokalen Festplatte auf das Network Share muss der Kompatibilität-Modus aktiviert werden, um das Datum zu erhalten.

[CoolWater]

Hallo,

ich kann das besagte Verhalten nicht bestätigen. Habe es allerdings auch mit einem Windows Share versucht.

OS: WinXP SP2, Share Host: WinXP SP2

Gruß
CoolWater

[Lufty]

Noch ein paar Hinweise:

Das Quell-OS ist WinXP SP2, das Ziel ist ein NAS-SoD File-Server unter Unix, der ein NTFS-Laufwerk bereitstellt.

WinZip 8.1 und der TC-Konkurrent SpeedCommander können Dateien ohne Datumsverlust/-Aktualisierung auf diesem Share aus dem Zip-Archiv entpacken.

Gruß an alle Wissenden

[ghisler(Author)]

Norton Antivirus?

[Lufty]

Es wird Symantec Antivirus 9.05 verwendet, der ja eine gewisse Verwandtschaft zun Norton Antivirus hat.

Der Effekt tritt auch auf, wenn der Real-Time Scanner deaktiviert ist.

Ich hoffe, Sie finden eine Lösung, denn das Problem ist ziemlich lästig in der Praxis. Ich verwende übrigens TC 6.55b2

[ghisler(Author)]

Es wird Symantec Antivirus 9.05 verwendet

Ja, das ist der Bösewicht: Ein User hat mir mal ein Log des filemon geschickt, da war klar zu sehen, dass bei laufendem Symantec/Norton die Schreibreihenfolge durcheinander kommt.

Zur Erklärung: Beim Schreiben in eine Datei geht Total Commander wie folgt vor:
1. Anlegen/Oeffnen der Datei
2. Schreiben der Daten
3. Setzen des Dateidatums (von der Originaldatei)
4. Schliessen der Datei

Wenn nun der Symantec/Norton läuft, wird nach Schritt drei noch in die Datei geschrieben! Dadurch meint das Dateisystem, die Datei sei nach dem Setzen des Datums nochmals verändert worden, und setzt das Datum auf das aktuelle Datum.

Beim Kopieren verwende ich nun folgende umständliche Lösung: Ich öffne die Datei nach Schritt 4 erneut, und teste, ob das Datum nun stimmt. Falls nicht, setze ich es erneut und schliesse die Datei. Weil bei diesem zweiten Oeffnen nicht mehr in die Datei geschrieben wurde, wird das Datum nun korrekt gesetzt. Leider bewirkt dieses erneute Oeffnen bei vielen Virenscannern, dass die Datei ein weiteres Mal gescannt wird, was zu einer starken Verlangsamung führt.

Ich hatte auch schon versucht, vor dem Setzen des Datums "FlushFileBuffers" aufzurufen, doch bremst das leider auch sehr stark.

Mich würde interessieren, wie das Winzip und der SC machen.

2Lufty
Bitte erzeugen Sie ein Log mit dem Programm filemon von www.sysinternals.com , während Sie eine Datei mit Winzip auf das Netzlaufwerk entpacken. Schicken Sie mir dieses mit ZIP gepackt per e-mail and support at ghisler dot com. Bitte möglichst bald, damit es noch für Total Commander 6.55 final reicht. Vielen Dank!

[Juergen]

Es wird Symantec Antivirus 9.05 verwendet

Ja, das ist der Bösewicht: Ein User hat mir mal ein Log des filemon geschickt, da war klar zu sehen, dass bei laufendem Symantec/Norton die Schreibreihenfolge durcheinander kommt.

Zur Erklärung: Beim Schreiben in eine Datei geht Total Commander wie folgt vor:
1. Anlegen/Oeffnen der Datei
2. Schreiben der Daten
3. Setzen des Dateidatums (von der Originaldatei)
4. Schliessen der Datei

Wenn nun der Symantec/Norton läuft, wird nach Schritt drei noch in die Datei geschrieben! Dadurch meint das Dateisystem, die Datei sei nach dem Setzen des Datums nochmals verändert worden, und setzt das Datum auf das aktuelle Datum.

Beim Kopieren verwende ich nun folgende umständliche Lösung: Ich öffne die Datei nach Schritt 4 erneut, und teste, ob das Datum nun stimmt. Falls nicht, setze ich es erneut und schliesse die Datei. Weil bei diesem zweiten Oeffnen nicht mehr in die Datei geschrieben wurde, wird das Datum nun korrekt gesetzt. Leider bewirkt dieses erneute Oeffnen bei vielen Virenscannern, dass die Datei ein weiteres Mal gescannt wird, was zu einer starken Verlangsamung führt.

Wie darf ich das verstehen?
Verwendet der TC diese Lösung grundsätzlich beim Kopieren? D.h. auch bei mir macht er das so umständlich, obwohl auf meinem PC gar nicht Symantec/Norton-Antivirus läuft???

Ich hatte auch schon versucht, vor dem Setzen des Datums "FlushFileBuffers" aufzurufen, doch bremst das leider auch sehr stark.

Mich würde interessieren, wie das Winzip und der SC machen.

Dokumentiweren Sie das Problenm an einer Stelle, die gut zu sehen ist. Wer dann immer noch an seinen Symantec/Norton-Programmen festhält, ist selbst schuld.
So ziemlich die schlechteste "Lösung" ist jedenfalls, wenn Leute die sich mit PCs auskennen und daher bewusst keine Symantec/Norton-Programme verwenden, trotzdem einen Nachteil haben, weil der TC absichtlich unnötige Dinge tut, "was zu einer starken Verlangsamung führt", bloß weil es Leute gibt die solche Schadprogramme benutzen.

Gruß, Jürgen

[icfu]

Da kann ich mich nur anschließen. Es kann doch wohl nicht angehen, daß der TC Workarounds für die Auswirkungen des Symantec-Virus implementiert, die den Betrieb des TC verlangsamen.

Auslöser ist Symantec – wie kommen die dazu, in Dateien zu schreiben? – daher sollten auch die die Ursache abstellen.

Icfu

[Lufty]

Um der Antivirus-Diskussion ein Ende zu setzen:

Ein Kreuztest auf einem PC ohne Antivirus-Programm ergibt denselben Effekt. D.h. das Zusammenspiel von TC mit dem File-Serve klappt nicht.

Gruß an Hr. Ghisler

[Juergen]

Ein Kreuztest auf einem PC ohne Antivirus-Programm ergibt denselben Effekt.

Das ist sicherlich eine hilfreiche Information in Bezug auf das von dir geschilderte Problem.

Der Antivirus-Diskussion wird dadurch jedoch keinesfalls ein Ende gesetzt, denn die von Herrn Ghisler deutlich dargestellte Problematik bleibt unabhängig davon bestehen.

Gruß, Jürgen

[ghisler(Author)]

Ein Kreuztest auf einem PC ohne Antivirus-Programm ergibt denselben Effekt. D.h. das Zusammenspiel von TC mit dem File-Serve klappt nicht.

Das konnte ich bisher mit keinem Netzwerklaufwerk reproduzieren - was für ein Gerät ist denn der Server? Eventuell ein Samba-Server oder ein NAS-Gerät?

Da würde mich auch ein Log vom Filemon interessieren...

[Juergen]

Über eine Antwort hätte ich mich natürlich gefreut ...

Herr Ghisler, ich möchte Sie hiermit bitten, diese unnötige Zwangsbremse beim Kopieren aus dem TC zu entfernen. Wenn Sie es für sinnvoll halten dass der TC Fehler der Symantec-Programmierer ausbügelt, können Sie ja in den TC einen "Symantec-Reparaturmodus" o. Ä. einbauen. Wenn dieser dann standardmäßig abgeschaltet ist, ist dagegen wohl nichts zu sagen. Aber momentan ist es ja so, dass weil einige TC-Anwender fehlerhafte Symantec-Programme benutzen, alle anderen TC-Benutzer dafür "bestraft" werden.

Seitdem wir vor längerer Zeit im Büro leidvolle Erfahrungen mit Symantec-Programmen gemacht hatten, habe ich einen großen Bogen darum gemacht. Und nun werde ich "hintenrum durch die kalte Küche" doch wieder durch Symandreck beeinträchtigt! Das kann doch wohl nicht wahr sein ...

Soweit ich weiß, sind Sandwege wohl für Pferde besser geeignet als asphaltierte Straßen. Was würden Sie sagen, wenn die Straßenbauverwaltung in der Schweiz von sämtlichen Autobahnen die Asphaltdecke entfernte und die Autobahnen in Sandwege umwandelte, damit die Minderheit der Reiter sich dort besser fortbewegen kann?

Gruß, Jürgen

[Juergen]

So zwei oder drei andere Ideen hätt ich noch, wie man das Problem beheben könnte. Zunächst hatte ich vor, mir dazu testweise Norton Antivirus zu installieren. Als ich dann jedoch las, dass "Eine vollständige Deinstallation [...] bei vielen Anwendern nicht möglich [ist]", habe ich davon wieder Abstand genommen.

Dass hier jemand nach einer Lösung gefragt hatte, hab ich anscheinend sowieso nur geträumt ...

[ghisler(Author)]

Keine Sorge, diese Funktion wird nur beim ersten Kopieren einer Datei auf ein bestimmtes Laufwerk angewandt. Wenn das Datum auch ohne diese Methode kopiert werden konnte, wird bei allen danach kopierten Dateien auf die Methode verzichtet.

[Juergen]

Andere Möglichkeiten, die ich aus den genannten Gründen nicht überprüft habe, wären z.B:

Enspr. obigem Nummerierungsschema

Code: Select all

1a. Anlegen/Oeffnen der Datei
1b. Sperren der Datei
2.  Schreiben der Daten
3.  Setzen des Dateidatums (von der Originaldatei)
4a. Entsperren der Datei
4b. Schliessen der Datei

oder

Code: Select all

Nach Schritt 4 Datum testen _ohne_ die Datei erneut zu öffnen.