Tach allerseits,

für eine kleine Backup Routine habe ich mir ein Skript gebaut, welches mir den Content eines Ordners mit den Windowseigenen Shellapplikationen verzippt. Das ganze funktioniert so auch wunderbar:

For each item in obj_app.NameSpace(str_lok_pfad).Items

	set obj_folder = obj_filesys.GetFolder(item.path)

	if obj_folder.Files.Count + obj_folder.Subfolders.Count > 0 then

		obj_app.NameSpace(str_svr_pfad).copyhere item, 16+256+1024

		sub_wait

	end if

	set obj_folder = nothing

next

sub_wait ist dabei eine Routine die vor der weiteren Bearbeitung darauf wartet, dass das entsprechende Zip-File nicht weiter größer wird und erst dann die nächsten Vorgänge zulässt (ansonsten geht das Skript einfach weiter und versucht in mehreren Instanzen auf das Zip-File zuzugreifen, was dann in einen Fehler läuft).

Wie gesagt, das funktioniert auch soweit. Mit einer Ausnahme, die aufkam, als ich das ganze Produktiv testen wollte:

In dem zu verzippendem Ordner befindet sich eine PDF Datei mit Namen blabla.....pdf . An dieser Stelle verschluckt sich der copyhere Befehl und macht, ohne den aktuellen Ordner fertigzustellen mit dem nächsten Item weiter bzw. wirft eine Fehlermeldung, dass er diese Datei aufgrund der 3 Punkte "....pdf" nicht kopieren könne. Selbiges tritt ebenfalls auf, wenn ich versuche die entsprechende Datei mit dem "Windowszipper" per "Rechtsklick => Senden an => Zip-Datei" zu verzippen. Es scheint aus meiner Sicht in der Tat ein "Fehler" des Builtin Zippers zu sein. (OS: Vista)

Nach meinem Verständnis sollten doch die 16+256+1024 Parameter eben verhindern, dass er abbricht und eine Fehlermeldung wirft, oder?

Meine Frage:

Liege ich mit dem Parameter Ansatz falsch oder müsste das so gehen und ich habe nur irgendwo eine Graupe drinnen?

Lässt es sich irgendwie anders organisieren, dass solche Dateien evtl übersprungen werden?

Da ich im Moment keinen weiteren Ansatz habe, werde ich zunächst versuchen das ganze über die 7-Zip Kommandozeile zu realisieren. Dennoch würde mich im Zweifelsfall interessieren, ob das Problem mit Boardmitteln lösbar ist.

Jemand eine Idee?

Gruß Eratum

...wirft eine Fehlermeldung, dass er diese Datei aufgrund der 3 Punkte "....pdf" nicht kopieren könne.

Wie lautet die Fehlermeldung genau?

Wenn's weiter hilft:

Die Flags für copywhere sind jedenfalls richtig. Unter Windows 7 tut es, also vermutlich wirklich ein Bug.

Ich fürchte, du wirst Dateien mit solchen Namen vorher herausfiltern müssen.

warum nicht powershell? Da tut das problemlos

So...ich hab's inzwischen mit der Commandline von 7zip gebaut (ist sowieso auf den CLients vorhanden).

Zum Fehler an sich:

Ich habe mir die Datei, bzw ihren Namen, mal etwas genauer angeschaut und mit verschiedenen "..." Kombinationen getestet. Nun ist mir etwas klarer warum das nicht geht. Es handelt sich dabei nicht um 3 hintereinander gesetzte Punkte sondern um einen "Tripple-Punkt" (nenne ich einfach mal so), also das Teil was bspw. Word erzeugt, wenn man 3 Punkte hintereinander schreibt. Danach werden die Punkte nicht als einzelne Punkte gesehen sondern als ein Zeichen, welches halt optisch aus diesen 3 Punkten besteht. Und mit diesem "Steuerzeichen" kommt die Zip Funktion von Windows scheinbar nicht klar.

Warum auch immer ein Unternehmen solche Dateinamen vergibt, bzw. wie man auf die irrige Idee kommen kann, dass solche Dateinamen sinnvoll sind...

Nichtsdestotrotz, gehe ich mittlerweile schlicht und ergreifend von der Tatsache aus, dass copyhere keinen entsprechenden Parameter besitzt um solche Dateien auszuschließen und lieber abbricht. Zumal ein Dateiausschluss wohl auch wenig sinnvoll wäre, wenn das verzippte Programm in irgendeiner Art und Weise auf dieses PDF zugreifen will...

Dennoch danke mfk

Silent: Das "große böse" Powershell ist nicht auf allen Clients bei uns verfügbar. Vlt. darf ich nach dem nächsten Rollout, bis dahin muss ich mit vbs und bat vorlieb nehmen.

Edit: Wäre auch noch zu prüfen, ob bei Powershell die 3-Punkt Problematik in diesem Sinne nicht auch auftritt...

Bearbeitet 12. Juni 201510 j von Eratum