KMail/ Kontact mag nicht mehr starten

KMail bzw. KMail als Komponente von Kontact friert schon beim Starten ein

KMail bzw. KMail als Komponente von Kontact friert schon beim Starten ein: Genau das ist einem Freund letztens widerfahren.

Zuvor war KMail schon beim Verfassen einer eMail eingefroren und hat sich beendet bzw. musste beendet werden.

Weitermachen… auch wenn’s weh tut!

Scheinbar schien KMail dann beim erneuten Öffnen die Bearbeitung der “unverdaulichen” eMail fortzusetzen bzw. fortsetzen zu wollen. Damit frohr KMail natürlich wieder ein und und musste wieder beendet werden. :0)

Und täglich grüßt das Murmeltier.

Die Sache würde sich sicherlich weiter so fortsetzen, wenn man nicht manuell etwas unternähme. – z.B. die “unverdauliche” eMail wegräumte.

Weg mit dem Störenfried

Im Unterverzeichnis

.kde/share/apps/kmail/autosave/cur

bzw.

.kde4/share/apps/kmail/autosave/cur

bei openSUSE in des Users Home-Verzeichnis befinden sich die noch nicht fertig gestellten eMails.

In meinem Falle habe ich die dort liegende Datei von dort weg verschoben und konnte dann KMail wieder erfolgreich starten.

 

Zugriff verweigert oder wer hat meine Datei geöffnet: handle.exe zeigt offene Datei-Handles unter Windows

Zugriff verweigert/ Access denied beim Datei-Löschen

Letztens unter Windows 2003 Server: Da lässt sich eine Datei nicht löschen oder umbenennen. – Man bekommt immer nur ein “Zugriff verweigert” (oder in englisch “Access denied”). Nicht irgendwie noch eine Zusatzinformation, dass sie noch von einem anderen User oder Programm geöffnet ist. “Administrator” ist man ja selbstredend; daran liegt’s auch nicht.

Der “Eigenschaften”-Dialog im Windows Explorer zeigt auch nur die “Allgemein” Seite an, keine anderen Reiter sind da. cacls.exe bringt auch nur Zugriff verweigert. Seltsam.

Ein delete on reboot ist auch nicht drin, ist ja ein (Terminal-)Server. Spontaner Reboot ist eher mit Stress verbunden.

Unter Linux…

…wär das nicht passiert. Naja, bis auf die Tatsache, dass das File-Locking unter Windows und Linux völlig verschiedene Paar Schuh sind, ist unter Linux das Tool “lsof” (List Open Files) dabei. In dessen Ausgabe hätte ich schnell den schuldigen Prozess ausgemacht, der die Datei sperrt. Aber Windows bringt da leider meines Wissens nichts mit.

Da gibt’s ja noch (ex-)Sysinternals

Sysinternals.com – Die einzige Firma, die gerüchteweise mehr Knowhow über Windows hatte als Microsoft selber. Vor einiger Zeit hat MS die ja dann auch (deswegen?) geschluckt. – Wenn die jetzt noch Sernet kaufen, haben sie endlich den größten Teil des weltweiten Windows Knohows vereint. ;->

Mark Russinovich hat das schöne, kleine Tools handle.exe geschrieben, dass ganz einfach auf der Kommandozeile die File-Handles und Prozesse ausgibt, die eine Datei geöffnet haben:

C:\temp>c:\handle.exe wurst.jpg                                                                                                                
                                                                                                                                               
Handle v3.46                                                                                                                                   
Copyright (C) 1997-2011 Mark Russinovich                                                                                                       
Sysinternals - www.sysinternals.com                                                                                                            
                                                                                                                                               
gzip.exe           pid: 4711  type: File           698: C:\temp\wurst.jpg

Und weg…

Damit war der Schuldige gefunden: gzip.exe unter der PID 4711. – Kurz im Taskmanager den Prozess beendet und die böse Datei doch noch gelöscht.