Speichern der RecordInfo-.txt Datei

Begonnen von tsduser, Juli 26, 2018, 14:08:26

« vorheriges - nächstes »

tsduser

Hallo,
es gibt da ein ziemlich kleines Problemchen, das schon seit etlichen Versionen besteht, mich aber bisher nicht wirklich stoerte:

Wenn eine Aufnahme aus den Tiefen des Verzeichnisbaumes "Nur geprüft" wird, dann wird die .txt-Datei mit den Aufnahmeninfos nicht notwendigerweise in diesem tiefen Ordner mit den anderen Log-Dateien abgelegt, sondern meist im Wurzelverzeichnis des Datentraegers; ich meine aber, sie auch schon einfach in oberen Verzeichnisebenen gesehen zu haben.

Wenn der Datentraeger nicht (Win10-)Laufwerk C: ist, dann geht das ja meist auch, und braucht nur noch ein manuelles Verschieben. Aber bei meinem Notebook, das nur LW C: hat, verhindert Windows, dass im Root von C: geschrieben wird, wenn man nicht der "Administrator" ist.

Siehe dazu angehaengte Log-Datei:

Opening file C:\MyData\CR6_PE\00002\record.ts

OS: Windows 10 Build 17134 x64
OS language    : DE
Appl. language : German
TSDoctor.exe V 2.1.31 (Build 04BE85)
Instance     : 0
System memory: 7,75 GB / Free: 5,58 GB
[...]
WARNINGS : 7

Speed: 105,6 MBytes/sec
Duration: 00:00:37
Error while saving info file 0 : Datei "C:\Feuer & Eis_ Islands (Südwesten im Winter).txt" kann nicht erstellt werden. Zugriff verweigert
Areas assigned: 1


Meiner persoenlichen Ansicht nach waere die txt-Datei im Verzeichnis der untersuchten Aufnahmendatei besser untergebracht, bzw. beim Arbeiten mit Ausgabedatei im Zielverzeichnis.

Und wenn kein Sendungstitel ausgemacht werden kann (schlechter Receiver ohne EIT und VT), dann heissen die Log-Dateien auch schon mal einfach _check.log usw., und liegen auch in unerwarteten Verzeichnissen. Dazu habe ich aber momentan kein aktuelles Beispiel. Deshalb dies hier nur so als Anmerkung; vielleicht liegt's ja im selben Code-Bereich ;-)

Cypheros

OK, check ich. Könnte an den Leerzeichen im Dateinamen liegen. Die _check.log und die .txt gehören natürlich ins Ausgangsverzeichnis.

tsduser

Sorry, dass ich diesen alten Thread noch einmal wieder hervorhole. Auch, weil die Funktion zum Speichern von Infos beim Check ab der 2.1.45 sowieso deaktiviert ist, und wir in einigen anderen Threads mit demselben "Problemchen" auch schon weiter diskutiert hatten. Diese Threads wollte ich jetzt aber nicht alle wieder zusammensuchen (duerfte auch sowieso nichts helfen).

Eigentlich fand ich (bzw. finde ich, weil ich jetzt bei der .44 stehenbleibe) die Info-Datei ja ganz hilfreich...

Und ich denke, dass ich die Ursache des Problems mit dem Nicht- oder Am-falschen-Platz-Speichern gefunden habe:

Der Doctor (bis .44, s.o.) speichert beim "Nur überprüfen" die .txt-Datei nicht im Quell-Verzeichnis der Eingabedatei (wie immer behauptet), sondern im Zielverzeichnis der letzten Speicheroperation. Und wenn dieses Verzeichnis nicht mehr existiert, dann wird offenbar versucht, im Wurzelverzeichnis des Laufwerks, auf dem sich das Verzeichnis befand, zu speichern. Das erzeugt bei Zielen auf Laufwerk C: dann eben wegen der Windows-Einschraenkung die bekannte Meldung, dass in C:\ wg. Zugriff verweigert nicht gespeichert werden koenne. Ich habe bei meinen heutigen Versuchen aber auch tatsaechlich 1x die Meldung vom Doc erhalten, dass im Pfad (den ich einfach umbenannt habe) nicht gespeichert werden koenne.

Vielleicht hilft das ja, die Funktion (entwanzt) doch wieder reaktivieren zu lassen. Wenn nicht, ist's auch nicht weiter schlimm. Die .44 geht ja noch (und kann so "getrimmt" werden, dass es mir passt bzw. dass ich die gesuchten Dateien finde), und die wirklich aller-allermeisten Erweiterungen und Problembehebungen sind fuer mich eh' belanglos (ausser zum Belegen, dass am Doc weiter aktiv gearbeitet wird, was an sich ja schon etwas Positives ist), weil ich keinen der "beliebten" Receiver verwende.

Mam

Zitat von: tsduser am Dezember 15, 2018, 14:21:46
Sorry, dass ich diesen alten Thread noch einmal wieder hervorhole. Auch, weil die Funktion zum Speichern von Infos beim Check ab der 2.1.45 sowieso deaktiviert ist, und wir in einigen anderen Threads mit demselben "Problemchen" auch schon weiter diskutiert hatten. Diese Threads wollte ich jetzt aber nicht alle wieder zusammensuchen (duerfte auch sowieso nichts

Du hast bei den ganzen Threads den eigentlichen Grund überlesen  ;D

Es liegt an Microsoft! bzw, an deren Wankelmütigkeit. Das "Merken des letzten Verzeichnisses" wurde den Anwendungen entzogen ab einer gewissen Windowsversion (bzw. Win10-Update-Stand).
Da kann Scheffe auch 10 mal den Parameter "C:\Irgendwas..." übergeben, Windows ignoriert den Pfad einfach und nimmt seinen intern gespeicherten.

Da das Verhalten je nach Version variiert, sieht hier jeder andere Fata Morganen. Also, das, was bei Dir zu funktionieren scheint, geht woanders überhaupt nicht.

Da ist nicht dran zu rütteln und man kann sich auch nicht drumrumlügen.
???

tsduser

#4
Stimmt; den Grund, dass es an Winzigweich liegt, habe ich in der Tat in keinem der Threads gefunden.
Allerdings auch nicht, warum das "Merken des letzten Verzeichnisses" (was ja offenbar verwendet wird) etwas mit dem "Kommt in den Pfad der Eingabedatei" (was immer wieder genannt wurde) zu tun haben sollte beim Programmieren, wenn man absolut diesen Quellpfad verwendet, und nicht "den zuletzt verwendeten".

So what.

Dann bleibe ich, wie bereits erwaehnt, einfach bei dem, was mir selber am besten hilft.

Mam

Zitat von: tsduser am Dezember 15, 2018, 18:35:53
Allerdings auch nicht, warum das "Merken des letzten Verzeichnisses" (was ja offenbar verwendet wird) etwas mit dem "Kommt in den Pfad der Eingabedatei" (was immer wieder genannt wurde) zu tun haben sollte beim Programmieren, wenn man absolut diesen Quellpfad verwendet, und nicht "den zuletzt verwendeten".

Das ist etwas kompliziert und für Nicht-Programmierhansels schwer verständlich  ;D

Aber ich versuchs mal grob:

Seit Urzeiten (ca Windows 3.1) gibt es bei Windows eine Bibliothek "common dialogs". Sie enthält vorgefertigte Dialoge für z.B. "Datei öffnen" oder "Speichern unter" usw.
Anfangs waren das wirklich nur Dialogfenster, aber später kamen auch "unsichtbare" Funktionen hinzu.
Der Sinn der Bibliothek ist, dass möglichst alle Anwendungen sie benutzen und somit dem Anwender ein vertrautes Look&Feel präsentierten.
Nebenbei konnte Microsoft damit auch grössere Designänderungen mit einfliessen lassen, also ob die Bonbonfarben von XP, die scharfen Kanten von Windows 10 usw, das alles steckt in Wahrheit da mit drin.
Der Programmierer hat den Vorteil, NICHTS tun zu müssen, wechselt die Anwendung von W7 auf W10 so sieht sie auf einmal anders aus, ohne dass eine einzige Zeile geändert wurde (manche kostenpflichtigen "Updates" profitierten davon).
Allerdings baut Microsoft auch manchmal neue Features ein, oder aus, oder anders. Auch davon bekommt die Anwendung und deren Ersteller nix mit. Auf einmal sieht irgendwas anders aus oder funktioniert etwas anders. Das gab schon öfters laute Flüche und Protestwellen, aber sie machen es immer wieder.
Eins dieser Features ist "merke Dir das letzte Verzeichnis".
Das hatten irgendwelche Anwendungen mal selber implementiert, Microsoft fand das irgendwann toll und hat es dann einfach mit in diese Dialoge eingebaut.
Klingt erstmal nett, aber hat unter Umständen echt fiese Auswirkungen.
Normalerweise kann der Programmierer beim Aufruf ein Startverzeichnis vorgeben, das klappt nun nur noch beim allerersten Male. Nach dem ersten Aufruf speichert die Bibliothek den aktuellen Pfad an eine private Stelle (in der Registry, Scheffe hat schon mal probiert, den Eintrag brutal zu löschen, aber mit jeder Version bastelt M$ da wieder dran rum und alles ist gaaanz anders...) und von da an wird der Aufrufparameter einfach ignoriert und stattdessen immer der gespeicherte Wert genommen.
Wie gesagt, das Verhalten ändert sich von Windows zu Windows und selbst von Update zu Update. Das ist einer der Lieblingsspielplätze der M$ Programmierhansels. Damit können sie am meisten Leute auf einmal ärgern.
Bis heute ist nicht wirklich dokumentiert, was , wo, wann, wofür gespeichert und wiederverwendet wird. Die Welt rätselt also, man ist sich nur in sofern sicher: es lohnt nicht, dahinterherzusuchen. Kaum hat man endlich kapiert, was gerade abgeht, schon kommt das nächste "kumulative Update" und alles ist vielleicht gaaanz anders...

Kiraly-Cutter

Zitat von: tsduser am Dezember 15, 2018, 18:35:53
Stimmt; den Grund, dass es an Winzigweich liegt, habe ich in der Tat in keinem der Threads gefunden.
Allerdings auch nicht, warum das "Merken des letzten Verzeichnisses" (was ja offenbar verwendet wird) etwas mit dem "Kommt in den Pfad der Eingabedatei" (was immer wieder genannt wurde) zu tun haben sollte beim Programmieren, wenn man absolut diesen Quellpfad verwendet, und nicht "den zuletzt verwendeten".

So what.

Dann bleibe ich, wie bereits erwaehnt, einfach bei dem, was mir selber am besten hilft.

Wegen einem unglücklichen "Zeichen" ist manchmal schon eine Textdatei leer oder eine Variable im Programm mit dem Pfad der Eingabedatei. Dann wird die Datei in einen anderen vordefinierten Pfad der Anwendung oder Systems geschrieben.
Dies erlebe ich öfters am Arbeitsplatz.
Dreambox DM920 UHD 4K
VU+ Duo 4K SE

Snipstream

Zitat von: Mam am Dezember 15, 2018, 22:34:45
Seit Urzeiten (ca Windows 3.1) gibt es bei Windows eine Bibliothek "common dialogs"....
Bis heute ist nicht wirklich dokumentiert, was , wo, wann, wofür gespeichert und wiederverwendet wird.
Ganz so scheint es wohl nicht zu sein: https://docs.microsoft.com/en-us/windows/desktop/dlgbox/common-dialog-box-library.

Mam

Zitat von: Snipstream am Dezember 19, 2018, 12:43:23
Ganz so scheint es wohl nicht zu sein: https://docs.microsoft.com/en-us/windows/desktop/dlgbox/common-dialog-box-library.
Ok, Teil 1 (Suche) hast Du schon mal verstanden  8)

Du must aber noch an Teil 2 (Lesen) und besonders an Teil 3 (VERSTEHEN) feilen, dann hättest Du gemerkt, dass Dein Link voll meine Aussage unterstützt, da er eben "obsolete" und "superseeded" ist  ;D
Du wirst bei weitere Suche noch mehr Versionen finden und es wird extrem schwierig zu erkennen, welche denn bis heute die Gültigste ist (bzw, welche Doku für welches Betriebssystem ist).
Deine geht nur "bis Vista", danach gibts noch einige Updates und Änderungen.

Und damit die Sache nicht zu einfach wird, der Programmierhansel ruft diesen Kram heute (natürlich?) nicht mehr direkt auf, sondern benutzt irgendwelche "Frameworks". Die kapseln die eigentliche Funktion und bastlen u.U. noch eigenen Kram hinzu. Natürlich haben die auch noch irgendeine Doku, auch die sind öfters obsolete und superseeded, auch die erwähnen nicht, welche unterliegende Funktion sie letztendlich dann benutzen.

Mit genügend Abstraktionsebenen kann der Anwendungsprogrammierer heute nicht mehr nachvollziehen, WAS sein Programm aufruft und WAS dann passiert. Es ist mehr oder minder eine Sache des Glaubens.  :'(

tsduser

Der immer laenger (vereinzelt sogar esoterischer) werdenden Rede doch eigentlich kurzer Sinn:
Wenn ich (als Programmierer) WEISS, dass eine Funktion (oder zumindest einzelne ihrer Rueckgabewerte) unzuverlaessig arbeitet, dann verwende ich sie nicht. Und schon 3x nicht, wenn die durch "Frameworks" noch unberechenbarer werden sollte.

Entweder verwende ich nur unzweifelhafte Daten (schliesslich klappt das mit der Liste der "zuletzt geöffneten" und "zuletzt erzeugten" Dateien und den dort verwendeten Pfaden ja tadellos), oder es wird (wie in diesem Fall) die Funktion (leider) einfach deaktiviert. Kann/muss man auch verstehen...

Mam

Zitat von: tsduser am Dezember 20, 2018, 18:22:14
Der immer laenger (vereinzelt sogar esoterischer) werdenden Rede doch eigentlich kurzer Sinn:
Wenn ich (als Programmierer) WEISS, dass eine Funktion (oder zumindest einzelne ihrer Rueckgabewerte) unzuverlaessig arbeitet, dann verwende ich sie nicht. Und schon 3x nicht, wenn die durch "Frameworks" noch unberechenbarer werden sollte.
Dann musst Du Dich von Windows komplett verabschieden, Microsoft hat überall da die Finger drauf und kein Programmierer kann darauf hoffen, dass sein Kram über Jahre lang unverändert weiterfunktionieren wird, wie ursprünglich geplant. Und sie machen immer mehr "alte" API Zugriffe dicht, so dass dem Programmierhansel keine Auswahl mehr bleibt.

(aber mach Dir keine Hoffnungen in Richtung Linux usw, die sind da keinen Deut besser, meist sogar noch schlimmer. Allerdings gehen sich brutaler vor (gibts nicht mehr!), so dass das Fehlverhalten meist deutlich hervortritt. Microsoft versucht den Kram immer heimlich unterzujubeln und so schleppen sich Fehler manchmal über Jahre hinweg)


Cypheros

Jepp, Mam hat Recht. Microsoft ist eine echte Plage für Software-Entwickler aber Linux folgt dicht auf. Diese militant mausfeindlichen Linux-Leute, die der Meinung sind, dass jeder Anwender in der Lage sein muss, den Kernel mal eben schnell nach eigenen Bedürfnissen selbst zu kompilieren, gestalten jede Linux-Version immer benutzerunfreundlicher und machen den Umstieg von Windows zu Linux nahezu unmöglich. Dank GPL, ist es fast unmöglich kommerzielle Software für Linux zu entwickeln und kommerzielle Software wird unter Linux auch nicht gerne gesehen.

Doch welche Firma sollte Zeit und Geld investieren in Softwareprodukte, wenn man damit kein Geld verdienen kann?

Egal, zur Zeit versucht Microsoft offenbar alle Software-Hersteller und auch alle Kunden zu vergraulen. Da wird nichts mehr dokumentiert, Updates werden erzwungen, Updates führen zu Datenverlusten, was bisher funktionierte, geht plötzlich nicht mehr aus unerfindlichen Gründen aber irgendwann dann doch wieder oder auch nicht.

Sowohl Windows als auch Linux gleichen immer mehr große Wundertüten, bei denen man nicht weiß, was drin ist. und wie es weiter geht.


www.cypheros.de