Created attachment 87162 [details] .xsession-errors from login to executing above copy/paste operation Whilst looking at .xsession-errors on a completely unrelated (to Dolphin) issue I found numerous pairs of entries such as this: dolphin(3454)/nepomuk (library): Could not find virtuoso backend dolphin(3454)/nepomuk (library): Could not find virtuoso to connect to. Aborting These steps will cause the entries to be written: Start Dolphin Navigate to 'Home' directory Enable 'Show Hidden Files' Select / Copy a file (it was in fact .xsession-errors-:0 that I was copying) Navigate to a different directory Paste file Attached screen-shot and .xsession-errors-:0 file.
Created attachment 87163 [details] screen-shot showing same, plus process list and date/time
Thanks for the report. This is definitely not a Dolphin issue. Dolphin's source code does not contain any reference to Nepomuk or Virtuoso. Some questions, which might help to find out where to reassign this report, or if it is valid at all: 1. Does the issue persist if you disable the Information Panel and tool tips? 2. Has Dophin been built with Baloo support? 3. Was a dialog like "File exists already" shown? Does the issue persist if you copy a file, and that dialog is not shown? Does it persist if you do not copy anything at all? 4. Maybe you could start Dolphin from a Konsole and watch exactly when that output appears? (like when you change the directory, or when you paste the file...) 5. What about FolderView? Does it also print that kind of output when copying files?
(In reply to comment #2) > This is definitely not a Dolphin issue. Dolphin's source code does not > contain any reference to Nepomuk or Virtuoso. > Mark as invalid (with regard to Dolphin), sorry. Beginning to doubt my own sanity... > 1. Does the issue persist if you disable the Information Panel and tool tips? With the Info Panel disabled, no. Tool tips were already disabled. When I re-enabled the Info Panel to attempt to 'prove' that was the cause... Earlier, I was able to consistently reproduce this using the steps I outlined. Now I can not... (There has also been a re-boot since then... Maybe relevant.) > 2. Has Dophin been built with Baloo support? Standard openSUSE build, so yes. > 3. Was a dialog like "File exists already" shown? Does the issue persist if > you copy a file, and that dialog is not shown? Does it persist if you do not > copy anything at all? No, the destination was not being overwritten. Thanks for your suggestions, if I notice it happening again I'll try 1,4, and 5. I guess the Info Panel widget is the most probable candidate... Apologies once more. Have a good weekend :)
Since the initial report the KDE Platform version has gone to 4.13.2, I'm still seeing a few instances of: dolphin(PID)/nepomuk (library): Could not find virtuoso backend dolphin(PID)/nepomuk (library): Could not find virtuoso to connect to. Aborting in xsession-errors, but am totally unable to link it to a specific cause/action. I accept this is not, as you pointed out, directly caused by Dolphin, and as such this bug report could be closed as invalid. However, if I may ask your further advice/opinion on narrowing down the 'culprit', or indeed, if I would be better of just accepting it as 'one of those things'. Possibly 'too many variables' here... I appreciate you probably have more productive things to use your time for - a 'sorry, can't help you' would be fully understood and accepted. The latest instance occurred as follows: I was working with gimp... Opened Dolphin - navigated to required directory - selected file, right click context menu 'extract to...' - left Dolphin open. Continued working with gimp... Returned to Dolphin - as before, different file ... 'extract to...' Dolphin crashed. Ark finished extraction and closed. I then closed gimp. Useless crash report as no debug symbols installed. (Will install those shortly...) Looking through xsession-errors: Multiple instances of a variation on these from gimp ('normal' behaviour) (gimp-2.8:4659): Gtk-WARNING **: ... then: (gimp-2.8:4659): GLib-GObject-WARNING **: g_object_get_valist: object class 'GtkToggleButton' has no property named 'has-frame' ark(4159)/kdeui (kdelibs) KXMLGUIClient::~KXMLGUIClient: 0x219e518 deleted without having been removed from the factory first. This will leak standalone popupmenus and could lead to crashes. X Error: BadWindow (invalid Window parameter) 3 Major opcode: 20 (X_GetProperty) Resource id: 0x3400025 QSqlDatabasePrivate::database: unable to open database: "unable to open database file Error opening database" QSqlQuery::prepare: database not open dolphin(4033)/nepomuk (library): Could not find virtuoso backend dolphin(4033)/nepomuk (library): Could not find virtuoso to connect to. Aborting ... repeated approx 25 times ... dolphin(4033)/nepomuk (library): Could not find virtuoso backend dolphin(4033)/nepomuk (library): Could not find virtuoso to connect to. Aborting QSqlDatabasePrivate::database: unable to open database: "unable to open database file Error opening database" QSqlQuery::prepare: database not open ... followed by nothing of obvious relevance, to me anyway :( until ... KCrash: Application 'dolphin' crashing... KCrash: Attempting to start /usr/lib64/kde4/libexec/drkonqi from kdeinit Something is clearly amiss somewhere, with something... Multiple issues appearing as 'one' ??
I don't know what is responsible for the Nepomuk access on your system, sorry. And I don't think that investigating .xsession-errors helps much. I think I said earlier that the best way to identify what causes this debug output to be printed is to start Dolphin from Konsole, and watch the output in the Konsole window while using it. This is the only way to see which of your actions triggers that output. AFAIK, some parts of kdelibs, like KIO's "File exists" dialog, still use KFileMetaDataWidget, which uses the deprecated Nepomuk code inside kdelibs. Maybe this is what's responsible for the output. If you can provide a backtrace for the crash, please file a new bug report.
(In reply to comment #5) > think I said earlier that the best way to identify what causes this debug > output to be printed is to start Dolphin from Konsole, and watch the output > in the Konsole window while using it. Indeed you did, in mitigation "when up to one's backside in alligators, the objective of draining the swamp is easily overlooked". > AFAIK, some parts of kdelibs, like KIO's "File exists" dialog, still use > KFileMetaDataWidget, which uses the deprecated Nepomuk code inside kdelibs. Yes, it is in fact, (contrary to an earlier comment I made) caused when a file is about to be overwritten and the (kio) rename dialogue showing meta-data is used. However this bug report https://bugzilla.novell.com/show_bug.cgi?id=879506 indicates that it is strigi/soprano that provides this functionality. Nonetheless - not a Dolphin problem. Whilst running Dolphin via Konsole there were a couple of (unrelated) errors that consistently appeared. Are these worthy of separate bug reports? If so pointers on the correct component to file against would be appreciated, as you can tell, I'm still rather hazy on that aspect :) 1) Right click (anywhere) in file list consistently produces: dolphin(PID)/kdecore (services) KServicePrivate::init: The desktop entry file "[current directory path]/.directory" has Type= "Application" but no Exec line 2) CD into a directory that has view properties changed (since last visit?) This is definitely related to a change in view properties, but the exact sequence of change(s) I've not established. dolphin(PID) KFileItemModel::setRoles: TODO: Emitting itemsChanged() with no information what has changed! > If you can provide a backtrace for the crash, please file a new bug report. Will do - "Murphy's Law" - won't crash now, debug packages are installed.
(In reply to comment #6) > > AFAIK, some parts of kdelibs, like KIO's "File exists" dialog, still use > > KFileMetaDataWidget, which uses the deprecated Nepomuk code inside kdelibs. > > Yes, it is in fact, (contrary to an earlier comment I made) caused when a > file is about to be overwritten and the (kio) rename dialogue showing > meta-data is used. > However this bug report https://bugzilla.novell.com/show_bug.cgi?id=879506 > indicates that it is strigi/soprano that provides this functionality. Yes, Strigi and Soprano provide this functionality to the obsolete Nepomuk 1 library inside kdelibs, and KIO makes use of this via the class KFileMetaDataWidget. If you are interested in further details, I encourage you to have a look at the source code of KFileMetaDataWidget in kdelibs 4.x and check where it is used. > 1) Right click (anywhere) in file list consistently produces: > > dolphin(PID)/kdecore (services) KServicePrivate::init: The desktop entry > file "[current directory path]/.directory" has Type= "Application" but no > Exec line I do not know if that is a bug or where it should be reported. > 2) CD into a directory that has view properties changed (since last visit?) > This is definitely related to a change in view properties, but the exact > sequence of change(s) I've not established. > > dolphin(PID) KFileItemModel::setRoles: TODO: Emitting itemsChanged() with no > information what has changed! This is not a bug. It seems that the message had been added at some point as a reminder that something in the code might be worth changing. However, it makes no sense at all to send that message to the user. I think we should just remove it.
(In reply to comment #7) Thanks for your, as usual, informative replies. > library inside kdelibs, and KIO makes use of this via the class > KFileMetaDataWidget. If you are interested in further details, I encourage > you to have a look at the source code of KFileMetaDataWidget in kdelibs 4.x > and check where it is used. It's a *very* long time since I did any programming, worked with DEC PDP-8s circa '73-'79. Used Watcom C back in the latter part of the 80's, didn't find it a particularly intuitive language to learn... Probably forgotten 99.9% of what little I did know! Not to be deterred I began looking at "class KFileMetaDataWidget::Private", now I know I've forgotten 99.9% of what I knew... and, of course this is C++... maybe it's as well I've forgotten, start afresh. Seriously, getting back into programming is something I've had (vague) intentions of doing. You may well have given me the push I needed. It would be good to be able to "give" as well as "take".
Git commit 7a83252e0d919d8408e0808ccbd7b401d57444d3 by Frank Reininghaus. Committed on 19/06/2014 at 18:27. Pushed by freininghaus into branch 'KDE/4.13'. Remove confusing warning message The message "TODO: Emitting itemsChanged() with no information what has changed!" is not helpful for the user. The implementation of the TODO will be done in master, see https://git.reviewboard.kde.org/r/118815/ M +0 -1 dolphin/src/kitemviews/kfileitemmodel.cpp http://commits.kde.org/kde-baseapps/7a83252e0d919d8408e0808ccbd7b401d57444d3
(In reply to comment #8) > Seriously, getting back into programming is something I've had (vague) > intentions of doing. You may well have given me the push I needed. It would > be good to be able to "give" as well as "take". Great :-) I hope you enjoy your return to programming, and it would be awesome if you can make contributions that many others will benefit from at some point. The problem that the "File exists" dialogs trigger the use of the obsolete Nepomuk 1/Soprano libraries might already be fixed in the KDE Frameworks 5 version of the KIO library though (but I'm not 100% sure).
Does this bug need to be reassigned to kfile?
I cannot find any trace of Nepomuk/Virtuoso (apart from two icons) inside Dolphin's code & both of these utilities are no longer shipped with any up-to-date distribution... I think we can safely close this bug now. If you still experience "phantom" calls, please reopen this report.