[req] ungekürzte anzeige der dateinamen "\...\"/to

[versalzen]

hallo,

bei einer kopieraktion zeigt mir tc einen fehler an
Fehler: kann \\.host\shared folder\tc\portable\...\blafasel\foobar245.dbb nicht lesen!
ich würde zu gerne wissen, wo sich diese datei nun genau aufhält.
(allerdings mit einem blick, quasi "schnell und direkt" und nicht erst über das öffnen einer neuen tc-instanz und dem (meist langwierigen) durchsuchen der entsprechenden laufwerke und deren unterverzeichnisse)

wäre es wohl möglich/in erwähung zu ziehen, dem user hierbei etwas zu unterstützten, indem tc:

a)

einen tooltip aufpoppen lässt, der den vollen pfad anzeigt, wenn der user über den pfad mit der maus fährt?


b) (unabhängig vom tooltip) dem user die möglichkeit gibt, den entsprechenden pfad in die zwischenablage zu kopieren. (idee: am schönsten wäre ein einfacher rechtsklich auf den gekürzten namen mit entsprechendem kontextmenu, aber auch ein button wäre eine lösung.)

grüße,

[HolgerK]

Ist "Konfigurieren ->Einstellungen.. ->Log-Datei : [x] Log für Fehler" in diesem Fall nicht die einfachere Lösung?

Gruß,
Holger

[versalzen]

Ist "Konfigurieren ->Einstellungen.. ->Log-Datei : [x] Log für Fehler" in diesem Fall nicht die einfachere Lösung?

eine zweite programminstanz zu öffnen, hinhangeln zur logdatei und den lister anschmeissen, bloss um einen pfad komplett angezeigt zu bekommen? und beides dann wieder schliessen und wieder öffnen, wenns nochmal vorkommt und wieder schiessen.... da wird dann auch die wincmd.ini (teile von ihr) wieder aktualisiert. das ist nicht immer gewünscht (von mir).

ich weiss nicht. einfach ja, umständlich aber :-)

dennoch eine lösung.
ignorieren wäre allerdings auch eine lösung und genau dazu verleitet der tc den user, wenn er ihm daten vorenthält, die der user sich erst "mühsam" beschaffen muss um evtl. weitere schritte einzuleiten.

ich kann doch nicht bei jeder datei, die z.b. nicht kopiert werden kann, eine zweite instanz öffnen und in der logdatei nachgucken wo die datei nun liegt. das computerprogram soll ja arbeit abnehmen, nicht machen. ach was red ich :->

ich vermute zudem, das in der logdatei der pfad relativ unübersichtlich zu lesen ist, weil in einer zeile der quell und zielpfad mitsammt uhrzeit, etc. gespeichert ist. dafür könnte man tools bemühen, klar. doch in den meisten fällen geht es dem user darum, einfach und schnell (auf einem blick) zu erkennen, *wo* das problem liegt. (hier: tc kann bestimmte datei aus bestimmten pfad nicht kopieren, ergo user will nur den pfad wissen.)

also wäre eine mausfahrt auf den pfad und ein entsprechendes tooltip imho 'ne freundliche lösung.

[HolgerK]

eine zweite programminstanz zu öffnen, hinhangeln zur logdatei und den lister anschmeissen, bloss um einen pfad komplett angezeigt zu bekommen? und beides dann wieder schliessen und wieder öffnen, wenns nochmal vorkommt und wieder schiessen....

http://www.totalcmd.net/plugring/tc_log_viewer.html

Wenn's mehrmals vorkommt, kann man sich die Fehler in aller Ruhe ansehen, sobald die restlichen Kopieraktionen beendet sind.

ignorieren wäre allerdings auch eine lösung und genau dazu verleitet der tc den user, wenn er ihm daten vorenthält, die der user sich erst "mühsam" beschaffen muss um evtl. weitere schritte einzuleiten.

Normalerweise hat der User bestimmt, welche Datei von wo nach wo kopiert werden soll.
Bei einer einzelnen Kopieraktion stehen also Quell- und Zielort noch im Panel zu Verfügung (ausser man kopiert im Hintergrund).

ich kann doch nicht bei jeder datei, die z.b. nicht kopiert werden kann, eine zweite instanz öffnen und in der logdatei nachgucken wo die datei nun liegt.

Ein neuer Tab würde reichen.

das computerprogram soll ja arbeit abnehmen, nicht machen. ach was red ich :->

Nun solches Event getrieben Arbeiten ist auch nicht sonderlich effektiv.
Die Logdatei zeigt einem die benötigten Informationen auf einem Blick an einer Stelle.
Man kann sie in Ruhe auswerten und das Problem analysieren.

doch in den meisten fällen geht es dem user darum, einfach und schnell (auf einem blick) zu erkennen, *wo* das problem liegt. (hier: tc kann bestimmte datei aus bestimmten pfad nicht kopieren, ergo user will nur den pfad wissen.)

Auf einen Blick würdest du den Pfad sehen, und nicht unbedingt sofort das Problem erkennen.
- Fehlende Rechte auf _irgendeinem_ Teil des Pfads?
- Hostrechner zwischenzeitlich runtergefahren?
- Netzwerkverbindung unterbrochen?
...
Die Ursache des Problems kann vielfältig sein. Selbst die gekürzte Pfadangabe gibt einem bereits einige Hinweise.

also wäre eine mausfahrt auf den pfad und ein entsprechendes tooltip imho 'ne freundliche lösung.

Im speziellen Fall eines einzelnen Fehlers in einer Hintergrundkopieraktion ja, ansonsten nicht unbedingt.
Wenn du das Problem behoben hast, willst du doch sicher die fehlenden Daten kopieren.
Hast du ein fotografisches Gedächtnis für alle gelesenen Tooltips der letzten halben Stunde?

Gruß,
Holger

[versalzen]

ignorieren wäre allerdings auch eine lösung und genau dazu verleitet der tc den user, wenn er ihm daten vorenthält, die der user sich erst "mühsam" beschaffen muss um evtl. weitere schritte einzuleiten.

Normalerweise hat der User bestimmt, welche Datei von wo nach wo kopiert werden soll.
Bei einer einzelnen Kopieraktion stehen also Quell- und Zielort noch im Panel zu Verfügung (ausser man kopiert im Hintergrund).

bei mir sieht das folgendermaßen aus: normalerweise bestimme ich nicht dateien, die kopiert werden sollen, sondern verzeichnisse. und deren inhalt ist mir oft weder bekannt, noch will/brauche ich ihn wissen. (z.b. rechner bei kunden)

eine einzige kopieraktion starte ich auch höchst selten. ich benutze massiv F2, also die "warteschlange" :-)
auch laufen meine kopier-/verschiebe-/pack-aktionen allesammt automatisch (also bei start der jew. aktion) im hintergrund ab.
der grund ist einfach. ich benutze nicht gerne mehrere instanzen vom tc. das sorgt bei mir für verwirrung.

ich kann doch nicht bei jeder datei, die z.b. nicht kopiert werden kann, eine zweite instanz öffnen und in der logdatei nachgucken wo die datei nun liegt.

Ein neuer Tab würde reichen.

das computerprogram soll ja arbeit abnehmen, nicht machen. ach was red ich :->

Nun solches Event getrieben Arbeiten ist auch nicht sonderlich effektiv.
Die Logdatei zeigt einem die benötigten Informationen auf einem Blick an einer Stelle.
Man kann sie in Ruhe auswerten und das Problem analysieren.

das ist richtig, solange alles im hintergrund läuft und tc nichts blockiert.
was die effektivität angeht, ist es so, das hier garnichts auf einen blick an einer stelle zu ersehen ist. 8-)

logst du nur die fehler, kann es natürlich sein, das du nur wenige zeilen siehst und somit schnell die übersicht gewinnst.

ich logge auch (gezwungenermaßen) die erfolgreichen kopier-/verschiebe-aktionen um in gewissen fällen eine undo-möglichkeit zu haben, wenn eine datei falsch umbenannt wurde. das hat zur folge, das meine logfiles vollgepackt sind mit unnötigen informationen. und das nicht zu wenig. deswegen benutze ich das log eh sehr selten. doch ich verstehe dein argument.

nur ist es leider nicht immer so, das, wenn tc aufgrund eines fehlers stoppt, der letzte eintrag im log auch der ist, um den es sich handelt. (eine kopieraktion mit F2, eine andere ohne F2, beides im hintergrund)

doch in den meisten fällen geht es dem user darum, einfach und schnell (auf einem blick) zu erkennen, *wo* das problem liegt. (hier: tc kann bestimmte datei aus bestimmten pfad nicht kopieren, ergo user will nur den pfad wissen.)

Auf einen Blick würdest du den Pfad sehen, und nicht unbedingt sofort das Problem erkennen.
- Fehlende Rechte auf _irgendeinem_ Teil des Pfads?
- Hostrechner zwischenzeitlich runtergefahren?
- Netzwerkverbindung unterbrochen?
...
Die Ursache des Problems kann vielfältig sein. Selbst die gekürzte Pfadangabe gibt einem bereits einige Hinweise.

ich habe mich falsch ausgedrückt. du hast natürlich recht, wenn du mir auf meine aussage deine antwort bereitstellst.

ich meinte auch eher: ich möchte sehen, *wo* (also der pfad/ort) das problem liegt. anhand des wo kann ich schnell und leicht erkennen/schlussfolgern, was das *was* sein könnte.
heisst:
-ich sehe den kompletten pfad und weiss z.b. das die daten innerhalb dieses pfades nicht wichtig sind. ergo überspringe ich.

-ich sehe den kompletten pfad und vermute, das es ein netzwerk-zugriffsproblem ist. ich weiss, das ich nichts daran ändern kann, also überspringe ich (oder löse das zugrifsproblem, wenn es in meiner macht steht und gefordert ist)

kurz (naja, nicht wirklich): ich sehe den kompletten pfad und kann eindeutiger beurteilen/eingrenzen. ich "verschwende" keine zeit mit klicken oder neuen tabs erstellen und später wieder löschen und logfile lesen, weil ich eben anhand des kompletten pfadnamens die folgeaktion direkt im kopf habe.

wenn ich mich *dann* entschliesse(n muss), andere aktionen zu starten, ist das auch sinnig/angebracht. aber nicht vorher.
da ist das dialogfenster mein freund und es soll in dialog mit mir treten. dazu muss es mir aber sagen, was es will. und das tut es imho nicht, wenn es mir für mich wichtige informationen verschweigt oder kryptisch anzeigt.

die von dir oben gezeigte lösung ist natürlich ein workaround, aber um diesen geht es mir nicht. mittel zur lösung finden sich genügend. doch wie kann man die usability einfacher/freundlicher/aussagekräftiger gestalten. nicht damit, das man den user seine benötigten informationen selber sammeln lässt. (ich meine mit "benötigt" nur den kompletten pfad).

also wäre eine mausfahrt auf den pfad und ein entsprechendes tooltip imho 'ne freundliche lösung.

Im speziellen Fall eines einzelnen Fehlers in einer Hintergrundkopieraktion ja, ansonsten nicht unbedingt.
Wenn du das Problem behoben hast, willst du doch sicher die fehlenden Daten kopieren.
Hast du ein fotografisches Gedächtnis für alle gelesenen Tooltips der letzten halben Stunde?

:-) das gedächtnis würde ich mir wünschen hätte ich 3 wünsche frei, doch zuerst das tooltip, denn davon haben auch die anderen etwas. bleibt noch ein wunsch frei. den verschenk ich.

diese fehlenden dateien wollen/können nicht in jeder situation kopiert werden. die entscheidung darüber könnte schneller fallen, wenn der user sehen würde, um welche es sich handelt (sofern ein rückschluss aufgrund des kompletten pfades möglich ist)
auch will/kann/brauche/darf ich (manchmal) gar keine probleme beheben. da reicht es, wenn ich aussage, das bestimmte pfade nicht kopierbar waren.
hier hilft das log, sofern es existiert.

antivir ist hier gerade aufgepoppt und verweigert nun den zugriff auf eine verdächtige datei.
der angezeigte pfad ist auch mit "..." verkürzt. ich fahre mit der maus drüber und sehe den komletten pfad.
nun kann ich mich entscheiden, ob ich die datei lösche oder den zugriff gewähre. weil ich weiss, wo sie sich befindet, weiss ich, aus welcher quelle sie stammt. kein unnötiges logdatei lesen oder starten von aktionen.
ein schönes beispiel.

[HolgerK]

Danke für die Erläuterung deiner Arbeitsweise.

...hätte ich 3 wünsche frei, doch zuerst das tooltip, denn davon haben auch die anderen etwas. bleibt noch ein wunsch frei. den verschenk ich.

Mit den Wünschen ist es so eine Sache.
Wenn sie zu leichtfertig geäußert werden, dann erhält man vielleicht genau das was man momentan meint gebrauchen zu können, aber nicht unbedingt das was man in Zukunft besser benötigen würde.

- Auf die Idee mit der Maus über einem Label zu hovern um einen tooltip zu erhalten, muss man erst mal kommen (Tastaturbediener sind da außen vor).
Anders wäre die Sache wenn der Filename in einer anderen Farbe hervorgehoben wird (z.B. linkcolor)

- Der Dialog ist in der Breite begrenzt
Eine etwas andere Verteilung:

Fehler: kann <CR>
\\.host\shared folder\tc\portable\...\blafasel\foobar245.dbb <CR>
nicht lesen!

würde bereits mehr Platz zu Verfügung stellen, und ist imho einfacher zu lesen.

- Wenn der Pfadname gekürzt wird (\..\), wird der Dialog breiter dargestellt.
Allerdings eine feste Breite, die nur geringfügig größer als die normale Dialoggröße ist.
Da bestünde natürlich auch die Möglichkeit den Dialog bis zu Breite des Bildschirms aufzuziehen,
bzw. soweit wie es zu Darstellung des ungekürzten Pfades notwendig ist.
Die Frage sei erlaubt ob hier ästhetische Gründe nicht zurückstehen sollten gegenüber einer eindeutigen Information.

- Falls man etwas gegen die Leseverweigerung aktiv unternehmen will, wäre es nützlich, das Kontextmenu des Files öffnen zu können (im Eigenschaftsdialog ist dann übrigens auch der komplette Pfad abgreifbar).
Dann besteht die Möglichkeit die Zugriffsrechte zu ändern, oder per Unlocker den sperrenden Zugriff aufzuheben.
Mit einem entsprechenden Registry-Eintrag (Kontextmenu "Öffnen in TC") könnte man die Datei auch in einer zweiten TC Instanz direkt anzeigen lassen.

Huch, das waren jetzt glaube ich mehr als drei Wünsche.

Mit freundlichem Gruß,
Holger

[versalzen]

hallo HolgerK, danke für deine wünsche/ideen.

Mit den Wünschen ist es so eine Sache.
Wenn sie zu leichtfertig geäußert werden, dann erhält man vielleicht genau das was man momentan meint gebrauchen zu können, aber nicht unbedingt das was man in Zukunft besser benötigen würde.

weder du noch ich, wissen, was die zukunft bringt. :-) wünsche, vermutungen, bestrebungen, zielsetzungen, anstrengungen jeglicher art sind vorhanden, doch was schlussendlich geschehen wird, muss nicht unbedingt etwas mit dem zu tun haben, was man glaubte, einsetzen zu müssen :-)

- :!: Auf die Idee mit der Maus über einem Label zu hovern um einen tooltip zu erhalten, muss man erst mal kommen (Tastaturbediener sind da außen vor).
Anders wäre die Sache wenn der Filename in einer anderen Farbe hervorgehoben wird (z.B. linkcolor)

die farbe ist ein gute idee. allerdings hakt das kontra (sollte es überhaupt eins sein), denn auch auf einen tastatur-shortcut muss man erstmal kommen.
da hilf nur ausprobieren und/oder nachlesen. in beiden fällen (hoverlink/shortcut) bleibt dem user nichts anderes übrig, als es zu probieren.
in zeiten, wo dutzende an popups/informationsfensterchen aufpoppen, wenn ich mit der maus über eine webseite manövriere, liegt die möglichkeit nahe, das eine gekürzte anzeige als langtext dargestellt wird, wenn man auf sie zeigt. genauso, wie eine (abschaltbare) unterstreichung eines menu-namens auf einen shortcut mit ALT-kombination hinweist. jeder menueintrag ist mit dem drücken des ersten buchstaben des eintrages zu erreichen. aber halt auch nicht immer. :-)

- :!: Der Dialog ist in der Breite begrenzt
Eine etwas andere Verteilung:

Fehler: kann <CR>
\\.host\shared folder\tc\portable\...\blafasel\foobar245.dbb <CR>
nicht lesen!

würde bereits mehr Platz zu Verfügung stellen, und ist imho einfacher zu lesen.

nicht der dialog, sondern das dialogfenster ist zu kurz, könnte man auch sagen. ja.

seit jahren wünsche ich mir, bei jeglicher verschiebe-/kopieraktion (vorder-/hintergrund) in die breite vergrößerbare dialoge/fenster.

dein vorschlag wäre sehr einfach einzubinden, deswegen wäre es eine schnelle lösung. dennoch bringt es höchstens ein paar buchstaben mehr.
besser als nichts, doch langfristig keine verbesserung der eigentlichen situation.

- :!: Wenn der Pfadname gekürzt wird (\..\), wird der Dialog breiter dargestellt.
Allerdings eine feste Breite, die nur geringfügig größer als die normale Dialoggröße ist.
Da bestünde natürlich auch die Möglichkeit den Dialog bis zu Breite des Bildschirms aufzuziehen,
bzw. soweit wie es zu Darstellung des ungekürzten Pfades notwendig ist.
Die Frage sei erlaubt ob hier ästhetische Gründe nicht zurückstehen sollten gegenüber einer eindeutigen Information.

dein erster satz hier macht mir keinen sinn.

der ästhetische zustand wird ja durch die default-einstellung vom programmierer bestimmt. sagen wir, die breite, die der tc-kopier-dialog standardmäßig hat.

nun baut der programmierer eine routine, die es gestattet, die dialog-fensterbreite zu errechnen, damit ggf. die anzeige gekürzt werden kann, je nach breite des fensters, welches zur laufzeit vom user variable verbreitert werden kann.
das macht die anzeige und die kopieraktion langsamer, wäre jetzt ein gültiges argument. aber das interessiert niemanden, der rechner benutzt, die dem heutigen standard entsprechen. ausserdem bleibt ja immernoch die möglichkeit, das eben erwähnte verhalten auszuschalten, mittels option in der wincmd.ini.

- :!: Falls man etwas gegen die Leseverweigerung aktiv unternehmen will, wäre es nützlich, das Kontextmenu des Files öffnen zu können (im Eigenschaftsdialog ist dann übrigens auch der komplette Pfad abgreifbar).
Dann besteht die Möglichkeit die Zugriffsrechte zu ändern, oder per Unlocker den sperrenden Zugriff aufzuheben.
Mit einem entsprechenden Registry-Eintrag (Kontextmenu "Öffnen in TC") könnte man die Datei auch in einer zweiten TC Instanz direkt anzeigen lassen.

auch eine schöne idee mit dem kontextmenu, aber hast du dir schonmal die eigenschaften angeguckt? der pfadname, der bei "Ort:" in den explorer-eigenschaften einer datei angezeigt wird, ist auch gekürzt. zwar nur abgeschnitten und -wunderschön- auch selektier- und kopierbar. auch hier sehe ich nicht auf einem blick, wo sich die datei befindet, aber immerhin komme ich relativ einfach dran. relativ = ein rechtsklick, eigenschaften wählen, doppelklick auf den pfadnamen, STRG+C, editor öffnen (ganz viele klicks nebenbei) und pfad einfügen. lesen. ich denke, da kann ich auch die von dir zuerst vorgeschlagene log-datei durchforsten :-)
dennoch würde ich es sehr begrüßen, wenn es möglich wäre. warum nicht gleich ein content-plugin einbinden können, das direkt alle interessanten informationen anzeigt, wenn der user auf ein bestimmtes symbol klickt oder mit der maus über den dateinamen fährt? doch nun wird es utopisch. :-)

ok,
mein fazit:

das auflösen des gekürzten pfadnamens ist durch mitlesen im log zu erreichen.

danke für deine ideen!

btw: im dialogfenster "überschreiben", (wenn tc merkt, das die zieldatei schon vorhanden ist und nachfragt, was getan werden soll) ist ein mouseover möglich.
der komplette pfad wird via tooltip angezeigt. zwar nur sehr kurz und ich muss 7 mal drüber gehen um ihn komplett im kopf zu haben, aber immerhin.

das würde doch bedeuten, das eine solche möglichkeit in tc schon implementiert ist und diese nur noch an die "richtigen" stellen gesetzt werden braucht, oder?
ich wäre gern bereit, all diese stellen zu nennen. falls interesse besteht :-)