Verbesserungsvorschlag: Handling des TC v. Such-/Dateilisten

German support forum

Moderators: white, Hacker, Stefan2

Post Reply
Dennis_Stevens
Senior Member
Senior Member
Posts: 215
Joined: 2013-06-08, 16:16 UTC
Location: NRW, Germany

Verbesserungsvorschlag: Handling des TC v. Such-/Dateilisten

Post by *Dennis_Stevens »

Guten Morgen,

gestern hatte ich dieses Anliegen, bei dem mir auch super geholfen wurde. Trotzdem kommt mir das Verhalten des TC beim Umgang mit einer (zB fehlerhaften) Dateiliste im Suchvorgang komisch vor.

Im Grunde war Folgendes gegeben. In einer Dateiliste standen 134 Einträge für JPGs quer über eine Festplatte verteilt:

Code: Select all

y:\Multimedia\Fotos\Jahr\Monat\Ereignis\bildxxx.jpg
Über den Suchdialog habe ich TC nun diese Liste übergeben, um daraus am Ende einen Kopiervorgang zu machen.
In "Suchen in" stand also

Code: Select all

@Y:\Dateiliste.txt
Nun waren in der Dateiliste von 134 Einträgen 30 falsch, weil die Kodierung der Textdatei nicht korrekt war.

TC zeigte also 104 Suchergebnisse an. Mehr nicht. Keine Meldung, dass es Einträge gab, die nicht gefunden wurden.

Lässt man TC auf die konventionelle Art etwas suchen das es nicht gibt, dann meldet er "Datei nicht gefunden".
In gestrigen Fall liest er 134 Zeilen ein, findet davon 30 nicht und meldet nichts.

Verbesserungsvorschlag: Entweder TC schreibt in ein LOG-File, welche Zeilen fehlerhaft waren / Dateien nicht gefunden wurden oder er meldet wenigstens, dass nicht alle Dateien gefunden wurden.
#230412 Single User Licence
Commanding Win10 64bit totally with version 11
User avatar
Dalai
Power Member
Power Member
Posts: 9364
Joined: 2005-01-28, 22:17 UTC
Location: Meiningen (Südthüringen)

Post by *Dalai »

Ich bin mir ziemlich sicher, dass TC "Datei nicht gefunden" melden wird, wenn er gar keine der in der Listendatei definierten Objekte findet (so wie bei einer Suche ohne Listendatei). Aus der Anzahl der gefundenen Objekte sowie der Zeilenzahl in der Listendatei kann man ableiten, wieviele Objekte nicht gefunden wurden. Insofern sehe ich das so: brauchen tut man eine Anzahl der nicht-gefundenen Objekte nicht, es wäre aber "nice to have".

Grüße
Dalai
#101164 Personal licence
Ryzen 5 2600, 16 GiB RAM, ASUS Prime X370-A, Win7 x64

Plugins: Services2, Startups, CertificateInfo, SignatureInfo, LineBreakInfo - Download-Mirror
JOUBE
Power Member
Power Member
Posts: 1447
Joined: 2004-07-08, 08:58 UTC

Re: Verbesserungsvorschlag: Handling des TC v. Such-/Dateili

Post by *JOUBE »

Dennis_Stevens wrote:In gestrigen Fall liest er 134 Zeilen ein, findet davon 30 nicht und meldet nichts.

Verbesserungsvorschlag: Entweder TC schreibt in ein LOG-File, welche Zeilen fehlerhaft waren / Dateien nicht gefunden wurden oder er meldet wenigstens, dass nicht alle Dateien gefunden wurden.
Nein, wieso das denn? Die 30 nicht gefundenen von 134 gesuchten Dateinamen gibt es eben nicht, fertig! Die Kontrolle der Zusammenhänge bei der Suche liegt ausschliesslich beim Benutzer und nur da gehört sie hin.

JOUBE
User avatar
Stefan2
Power Member
Power Member
Posts: 4132
Joined: 2007-09-13, 22:20 UTC
Location: Europa

Post by *Stefan2 »

Na ja, soweit ich die Zusammenhänge beim querlesen richtig verstanden habe,

könnte der TC schon mitteilen, wie erfolgreich er war.


zB in der Statusleiste: Gefunden 104 / 134



Dann kann der Anwender aktiv werden und nachschauen was da nicht stimmt.

Einfach nur eine kurze Rückmeldung, "he pass auf! da stimmt 'was nicht"





 
JOUBE
Power Member
Power Member
Posts: 1447
Joined: 2004-07-08, 08:58 UTC

Post by *JOUBE »

Stefan2 wrote:he pass auf! da stimmt 'was nicht"
Ich gebe zu, dass ich auf diese Reaktion gewartet habe ;-) Wer sagt denn, dass 'da etwas nicht stimmt'? Es gibt doch zig Fälle - und das werden die überwiegende Anzahl der Fälle, also die Normalfälle sein - in denen die Suchdatei Elemente enthält, die nicht vorhanden sind. Dass - wie in diesem besonderen Spezialfall - alle Elemente gefunden werden sollen, ist doch bei einer Suche eher selten. Es ist ja keine Finde sondern eine Suche. Die Themen-Starter hat sich doch letztlich völlig korrekt im Sinne des TC verhalten, indem er die gefundenen Elemente überprüft hat.

JOUBE
Dennis_Stevens
Senior Member
Senior Member
Posts: 215
Joined: 2013-06-08, 16:16 UTC
Location: NRW, Germany

Post by *Dennis_Stevens »

Mahlzeit,

sorry für die Verzögerung.
JOUBE wrote:Dass - wie in diesem besonderen Spezialfall - alle Elemente gefunden werden sollen, ist doch bei einer Suche eher selten. Es ist ja keine Finde sondern eine Suche.
JOUBE
Bei einer normalen Suche will ich wissen, WO etwas ist und nicht OB es da ist. Ist etwas nicht da, meldet TC das mit "Datei nicht gefunden".
Jetzt könnte man dieser Argumentation folgend auch einfach behaupten, dass TC selbst bei einer normalen Suche nichts melden muss, denn da die Liste der Suchergebnisse leer bleibt, ist wohl nichts gefunden worden.
Außerdem sollte man ja nichts finden, weil man gesucht hat. Dann hätte man finden sollen. Hä?

Sucht man in diesem Forum nach der Möglichkeit, TC eine Kopierliste zu übergeben, so findet man die Vorgehensweise, die ich hier gewählt habe.
TC stellt also über einen Umweg (sehe ich so. Wenn man eine Dateiliste importieren kann um Objekte zu selektieren, warum kann man dann dem Hintergrundtransfermanager oder was weiß ich wem keine Kopierliste direkt übergeben?) eine solche Funktion zur Verfügung. Nun stellt TC da auch bestimmte Anforderungen (Beispiel Kodierung) über die man stolpern kann (wie ich). Hat man nun eine solche Liste zu diesem Zweck mit tausenden anstatt 130 Einträgen, dann ist diese Funktion schon wertlos, weil eine Fehlersuche dann zur Suche nach der Nadel im Heuhaufen wird. Dann ist man vermutlich schneller, wenn es man es zu Fuß über den Explorer macht :D
Dalai wrote:Ich bin mir ziemlich sicher, dass TC "Datei nicht gefunden" melden wird, wenn er gar keine der in der Listendatei definierten Objekte findet (so wie bei einer Suche ohne Listendatei).
Das macht er nicht. In einer Testdatei stand gerade "pafjgofvj". Er meldet nix.
#230412 Single User Licence
Commanding Win10 64bit totally with version 11
Post Reply