[1234] in UNC Pfad / os.path.getmtime

[cbesi]

Hallo,

ich habe ein Tool welches das Alter von Dateien in einem UNC Pfad prüft und wenn älter als x Sekunden eine Aktion ausführt.

Funktioniert super, aber ich habe einen UNC Pfad nach dem Muster \\pfad1\pfad2\test[1234]\*.txt (\\\\Pfad1\\pfad2\test[1234]\\*.txt)

Das os.path.getmtime scheint mit den [ ] ein Problem zu haben, findet den Pfad dann nicht. Mache ich einen Test mit einem Pfad ohne das [ ] geht es.

[Sirius3]

Hast Du ei Muster oder enthält der Pfad wirklich []? Mit Mustern kann os.path.getmtime nichts anfangen, das braucht einen konkreten Dateinamen, Dateien nach Muster suchen kann glob.glob, obwohl man heutzutage für das alles pathlib.Path verwenden würde.

[imonbln]

os.path.getmtime sollte nicht mehr benutzt werden, statt dessen sollte man die pathlib verwenden. Die kann angeblich teilweise UNC Pfade und gibt die mtime beim stat Aufruf zurück.

Abgesehen davon, als jemand der früher viel mit verteilten Daten zu tun hatte, weiß ich das stat auf Netzwerk Ressourcen zum Teil falsche Ergebnisse liefern kann, hierbei kommt es sehr auf das Transportprotokoll, was da zurückkommt. Dabei ist es unabhängig, ob du os.path.getmtime oder pathlib.stat() nimmst, beide nutzen den gleichen syscall intern. Sei also vorsichtig nicht das du aus Versehen die wichtigen Vertriebszahlen löscht, weil die Netzwerktransportschicht, da werte aus dünner Luft erzeugt.

[cbesi]

Ja der Pfad enthält wirklich die [1234] also die [], wenn ich einen Pfad ohne die [1234] also ohne diese Zeichen [] nutze funktioniert mein Script einwandfrei. Leider kann ich den blöden Pfad nicht ändern.

[__blackjack__]

@cbesi: Kannst Du mal ein *konkretes* Beispiel zeigen. Nicht das Du hier an der falschen Stelle suchst und eigentlich darüber stolperst, dass "\test" ein Tabulatorzeichen gefolgt von "est" ist und nicht ein Backslash gefolgt von "test".

[cbesi]

Hallo,

Danke für die Hilfen. Ich habe es nun gelöst in dem ich den Pfad separat freigegeben habe ohne die [1234] im Pfadnamen also aus \\Server\share\share[12134]\test\*.txt ist nun \\Server\share\share1234\test\*.txt geworden und alles funktioniert. Wieso es nicht ging keine Ahnung. Hatte zwischendurch auch versucht die Zeichen mit Hexzeichen zu ersetzen, ging aber trotzdem nicht \x5b \x5d ....

Danke trotzdem....

Keine Lösung, aber es lebe der workarround.....

[DeaD_EyE]

Bitte den Einwand von BlackJack berücksichtigen. Ein \t in einem String ist ein Tabulator-Zeichen.
Wenn man diese Interpretation unterbinden will, dann einen Raw String verwenden oder normale Schrägstriche oder mit backslash den anderen backslash escapen.
Probier es einfach mal aus, ob es so geht. Keine Lust jetzt eine VM mit Windows zu starten.