bug: hintergrund verschiebefenster bleiben bestehen (zombis)

[versalzen]

tc: 654a

a)
ich gehe so vor:

settings:
config: operation->schnelle suche->mit suchdialog
wincmd.ini: [x] verschieben im hintergrund, immer

2 verzeichnisse auf der selben festplatte:

links(quelle): ein verzeichnis mit möglich großen (mb) unterverzeichnissen (z.b. C:\bla\fasel\), bzw. vielen dateien innerhalb. innerhalb des haupt-verz. (z.b. C:\bla\)muss sich noch eine datei befinden. (z.b. C:\bla\a.txt oder C:\bla\ä.txt) keine weitere datei die mit a beginnt, sollte im hauptverz. sein.

rechts(ziel): irgendein verz. in das eines der großen unterverzeichnisse verschoben wird.


nun verschiebt man mit F6 das verz. von links nach rechts.
je größer dabei das zu verschiebende verz. ist, desto länger dauert es und umso größer ist die chance, das ihr das reproduzieren könnt.
nehmt euch also zeit :) und probiert mehrmals.

sobald der verschiebeprozess im hintergrund läuft, drückt man die taste "a", (oder "ä") damit man zur oben erwähnten datei a.txt gelangt. (**)

(ggf. kann es auch sein, das es reicht, wenn man sich nur in dem schnellsuchedialog befindet, während ein prozess noch läuft oder gerade endet)

jetzt wartet man bis der verschiebeprozess beendet ist (und scrollt ggf. zu dem verzeichnis, welches verschoben wurde).
und siehe da, das verschobene verz. ist noch zu sehen.
sollte allerdings nicht, da es ja verschoben wurde.

b)
ein bug, der mir dabei zusätzlich (evtl. ist es aber auch derselbe und hängt mit ** zusammen) noch aufgefallen ist, den ich aber noch nicht reproduzieren konnte:

irgendwann, nachdem man viele verzeichnisse in der art wie oben erklärt verschoben hat, hat man in der taskleiste noch viel unbeendete verschiebefenster. dessen vorgang wurde zwar beendet, aber das hintergrundfenster wurde nicht beendet.

dieses verhalten zeigt sich sehr oft, wenn man viel und oft und gleichzeitig mehrere hintergrundverschiebeaktionen laufen hat und währen der ganzen prozesse z.b. verzeichnisse umbenennt, verzeichnisse welselt (auch, aber nicht ausschliesslich in beiden fenstern).

es ist nicht möglich auf den button X (zum schliessen) der zombie-hintergrundfenster zu klicken. es button reagiert nicht. (das verhalten ist in etwa so, als würde tc in einem anderen task auf eine eingabe warten und man versucht den ursprungstask mit dem button schliessen zu schliessen.)


es "könnte" sein, das tc bemerkt, das auf der anderen seite eine datei schon existiert und fragt, ob diese überschrieben werden soll. ich habe allerdings solch ein fenster noch nie gesehen, welches auf antwort wartet. wenn fragen kommen, erscheinen diese immer im vordergrung und werden von mir mit "alle (älteren) überschreiben" beantwortet.

wenn jedoch eine "überschreibe"-abfrage kommt und man drückt ESC zum abbrechen, bleibt das zombiefenster auch im hintergrund kleben und wird nicht wieder geschlossen.

manche zombiefenster stehen auf 100%, manche auf 0%.

während neue zombiefenster entstehen (neuen kurzen verschiebevorgang starten), arbeiten alte noch im hintergrund

um diese zombies loszuwerden, muss man Tc beenden. dabei sagt er, das die (angeblich) aktiven hintergrundprozesse dabei auch geschlossen werden.

dies ist, wie gesagt noch nicht so richtig reproduzierbar für mich, allerdings tritt das schon seit, ich würde sagen, mind. tc 6.53 auf.

[versalzen]

hallo,
lange zeit ist es her, das dieses phänomen nicht mehr aufgetaucht ist, doch plötzlich tritt es wieder auf.

vielleicht hilft diese zusätzliche info ja jmd.

was ich gerade tat:

ich kopiere (im hintergrund) verschiedene dateien von einer DVD-RW (X:\, ide-laufwerk) auf eine externe usb-festplatte (W:\bla\test) und der kopiervorgang "hängt",bzw. zieht sich sehr lange hin, weil die DVD-RW schon ziemlich verkratzt/strapaziert ist.

nun habe ich in der selben TC instanz einen weiteren verschiebe-vorgang gestartet. von einem verzeichnis einer internen scsi-platte in ein anderes verzeichnis (D:\blo\_test\blu => D:\blo\blu)

während die entsprechenden daten im verschiebe-vorgang schon längst verschoben und an der richtigen stelle gelandet sind, bleibt das verschiebe-fenster erhalten.
es zeigt nur noch:
umbenennen/verschieben:
blu->blu 0% Pause

und lässt sich via klick auf X nicht schliessen.

der kopier-vorgang der DVD-RW steht bei 86%. ob er noch zum ende kommt, weiss ich nicht, denn ich werde ihn abbrechen müssen. hab ja nicht ewig zeit :-)

[ghisler(Author)]

Mit hängenden Windows-Dateifunktionen habe ich leider auch schlechte Erfahrungen gemacht: Wenn eine solche richtig feststeckt, kann sie auch andere blockieren (z.B. in der Close-Funktion).

[versalzen]

(mittlerweile TC 7.56a)

Manchmal tritt das "hängenbleiben" auch auf, wenn man extrem* viele Dateien im Hintergrund löscht**.


*extrem: > 300.000
** wobei hier in der tat das Phänomen der parallelen Zugriffe auf die Festplatte hinzukommt, d.h. wenn die Festplatte mehr "belastet" wird, d.h. das System eh schon ruckelig läuft, kommt es öfter zu solchen Zombies.

[ghisler(Author)]

TC macht mittlerweile vieles in eigenen Threads, u.a. FindFirstFile (Einlesen von Verzeichnissen), Verbinden zu Netzwerklaufwerken etc. Wo höngt es denn bei Ihnen?

[versalzen]

TC macht mittlerweile vieles in eigenen Threads, u.a. FindFirstFile (Einlesen von Verzeichnissen), Verbinden zu Netzwerklaufwerken etc. Wo höngt es denn bei Ihnen?

Wie ich schrieb, meistens beim Verschieben/Kopieren von sehr vielen Ordnern/Dateien im Hintergrund.
Selten auch FTP, wobei ich vermute, das das Hängen bei FTP eher an dem Hängenbleiben der Verbindung liegt.

Ein lustiges (und ewig vorhandenes) Phänomen ist auch folgendes:

([x] kopieren im Hintergrund aktiv)

Links:
Eine Datei wird mit F6 zum Verschieben nach Rechts veranlasst.

Wenn das Windows (egal ob XP/W7) sehr langsam/ausgelastet ist,
hat man Zeit, bevor der Verschiebevorgang startet, das Verzeichnis Links zu wechseln (Ich nutze meistens BACKPSPACE). Z.B. ein zwei Verz. höher wechseln.
In einigen reproduzierbaren Fällen legt TC dann Rechts noch ein zusätzliches Verzeichnis an, welches exakt den Namen der zu kopierenden Datei hat und verschiebt die vorher ausgewählte Datei dann in dieses Verzeichnis, anstatt, wie vom User geklickt, in den eigentlichen Ordner.

Gut zu testen mit langsamen Netzlaufwerken und wenn der Rechner stark ausgelastet oder alt ist.

[ghisler(Author)]

Wenn das Windows (egal ob XP/W7) sehr langsam/ausgelastet ist, hat man Zeit, bevor der Verschiebevorgang startet, das Verzeichnis Links zu wechseln

Das ist keine gute Idee, weil sich der Hintergrund-Transfermanager das Verzeichnis erst holen kann, wenn er gestartet ist...