304943 2012-08-10 19:56:06 +0000 File Watcher prevents removable media from being unmounted 2013-10-04 13:32:34 +0000 1 1 10 Unmaintained nepomuk filewatch 4.9 Gentoo Packages Linux RESOLVED FIXED NOR major --- 1 stephan.menzel nepomuk-bugs a.j.ball alexandre.bonneau bugs.kde.org cfeck chalkerx christian.fontana christian_bay circular.ebin cruzki123 fatgerman fedux hrvoje.senjan humufr johan.thelmen karsten.htw kde kde kevin.kofler korgens martin me meyerm nepomuk-bugs Oliver orion pereira.alex quantumphazor rdieter rm roland.leissa sami sergio tim.eberhardt w01dnick wengxt wilcobeekhuizen yannick.roehlly http://commits.kde.org/nepomuk-core/662d24f734efad461d74a11488519269ec611496 4.10 190 oldest_to_newest 1283671 0 stephan.menzel 2012-08-10 19:56:06 +0000 Since I have upgraded to 4.9 I cannot unmount USB drives anymore. The removable media icon tells me there is an application acessing it. Using fuser I determined nepomuk as being the reason. It is having a process "/usr/bin/nepomukservicestub nepomukfilewatch" using the removable drive. I have the option "Ignore all removable media" set in the configure dialog and also tested disabling file indexing. Both did not work once the media has been used once. Reproducible: Always Steps to Reproduce: 1. Mount removable media 2. Use it 3. Klick on 'unmount' Actual Results: Unmount does not work, error message tells there's applications still using it, although there aren't Expected Results: Drive unmounted I would consider this major as it forces me to reboot all the time in order to remove those drives. I am aware though that some would consider this normal at best. I just choose the severety it has for me. 1284380 1 me 2012-08-13 15:27:55 +0000 Git commit 24caa3821aed71e590a3e55a76c6e4bc08f7d9d5 by Vishesh Handa. Committed on 08/08/2012 at 17:38. Pushed by vhanda into branch 'KDE/4.9'. FileWatch: Remove watches for removeable media before unmounting Added 2 signals in RemovableMediaCache * deviceRemoved * deviceTeardownRequested When the device is about to be unmounted all the watches are removed so that it can be unmounted sucessfully. FIXED-IN: 4.9.1 REIVEW: 106002 M +24 -6 common/removablemediacache.cpp M +3 -0 common/removablemediacache.h M +9 -1 services/filewatch/nepomukfilewatch.cpp M +6 -0 services/filewatch/nepomukfilewatch.h http://commits.kde.org/nepomuk-core/24caa3821aed71e590a3e55a76c6e4bc08f7d9d5 1284422 2 me 2012-08-13 18:00:05 +0000 (In reply to comment #0) > > I would consider this major as it forces me to reboot all the time in order > to remove those drives. I am aware though that some would consider this > normal at best. I just choose the severety it has for me. I agree with your assessment. It is a major bug. Thanks for the bug report. Let me know if there is anything else. 1284475 3 yannick.roehlly 2012-08-13 22:26:17 +0000 Hi Vishesh, Thanks for patching this, it will easy the use of KDE for people wanting to 'index' their removable drives. Nevertheless, there is maybe a problem when Nepomuk indexes the removable drives when it's told not to do so? Regards, Yannick 1284741 4 stephan.menzel 2012-08-14 18:10:29 +0000 I am afraid so. Something in the settings of what should be indexed and what not seems broken, possibly related to this. I have nepomuk index my home, with some subfolders excluded. One of them subfolders is a read only ntfs partition. And Nepomuk keeps indexing it. I can tell for the constantly high CPU consumption of mount.ntfs and nepomuk. strace tells it is indexing this partition, which is too large for that. And I have explicitly excluded all ntfs mounts. Also, the USB drives shouldn't have been indexed in the first place. Also because of the settings. Nevertheless, the patch does fix a bug so I guess this should probably be a new one? I'm not sure. Please let me know if I can provide any further information. Stephan 1285090 5 stephan.menzel 2012-08-15 14:53:00 +0000 I did some additional testing on this to find out whether the indexer would eventually finish with the ntfs and removable volumes. Doing so I discovered another issue. It appears to be leaking considerable amounts of mem. I didn't notice that earlier as I had to reboot often but now that I've had it running for 5 hours I found my system came to a crawl because the indexer process was using more than 6GB of memory, which caused swapping. Now I have it set to use 512MB, so it doesn't regard this setting. I rebooted and did the test again 2 times with the same result. After about 5-6 hours the system starts swapping and I have to shut down. This would probably be another report but I'll just comment this here to let you know. I can file another bug on this if you think it's in order. I'm reopening. Let me know if you would like another report. Cheers, Stephan 1289156 6 me 2012-08-20 08:02:40 +0000 Please file another bug. If you say the fileindexer is leaking memory, please could you run it in massif, and provide the output? $ qdbus org.kde.nepomuk.services.nepomukfileindexer /servicecontrol quit Wait for it to shutdown and then run, $ valgrind --tool=massif nepomukservicestub nepomukfileindexer 1289236 7 stephan.menzel 2012-08-20 11:42:11 +0000 I have filed https://bugs.kde.org/show_bug.cgi?id=305486 The mem leaking issue is reported there. However, this leaves the issue of the not regarded settings for what and what not to index. In fact, I came to wonder if all this is probably just settings issue all along. I have tried the following settings: 1) Indexer on / off 2) Amount of memory to use 3) Which directories to index None of them seems to have any effect. If just the settings were somehow ignored, that would explain the misbehaving indexer, the memory consumption and the fact that I can't seem to turn it off. Maybe that would be worth investigating. Let me know if I can provide any further information. Cheers, Stephan 1289794 8 yannick.roehlly 2012-08-21 20:50:29 +0000 Hi Vishesh, I applied de commit diff and recompiled nepomuk-core but the problem is still here. Do I need to recompile something with the new nepomuk-core development files? Yannick 1294768 9 yannick.roehlly 2012-09-06 19:36:35 +0000 Hi Vishesh, I've upgraded to nepomuk-core 4.9.1 and the problem is still here : to be able to unmount an external drive, I first have to disable nepomuk. Yannick 1294772 10 kde 2012-09-06 19:44:02 +0000 You don't need to disable Nepomuk but only suspend file indexing using nepomuk icon located in system tray and wait until last indexation finished. 1294777 11 yannick.roehlly 2012-09-06 20:18:34 +0000 Hi Ignacio, No, I have to completely disable nepomuk. If I only suspend indexing, nepomukservicestub is still 'locking' the device and I can't unmount it. I tried to delete all the nepomuk configurations but the problem is still here. Yannick 1294778 12 kde 2012-09-06 20:23:55 +0000 You have a different behavior than me. In my system suspend file indexing and wait a few until last file was indexed it's enough and if I can't wait I only need a killall -3 nepomukindexer. 1295878 13 me 2012-09-10 11:14:27 +0000 (In reply to comment #9) > Hi Vishesh, > > I've upgraded to nepomuk-core 4.9.1 and the problem is still here : to be > able to unmount an external drive, I first have to disable nepomuk. > > Yannick Damn. I cannot seem to reproduce it then. Could you make sure it is the filewatch process that is holding the watches? I'm reopening this. 1296055 14 yannick.roehlly 2012-09-10 20:08:28 +0000 Hi Vishesh, thanks for taking care of this. The process that is using the drive has for command line: /usr/bin/nepomukservicestub nepomukfilewatch Note that this happens with an USB3 drive, although nepomuk is configured not to deal with removable drives. Is it possible that this drive is not considered as removable by nepomuk (although the system allows me to unmount it with the new drives applet)? Regards, Yannick 1296056 15 me 2012-09-10 20:13:05 +0000 (In reply to comment #14) > Hi Vishesh, thanks for taking care of this. > > The process that is using the drive has for command line: > /usr/bin/nepomukservicestub nepomukfilewatch > > Note that this happens with an USB3 drive, although nepomuk is configured > not to deal with removable drives. Is it possible that this drive is not > considered as removable by nepomuk (although the system allows me to unmount > it with the new drives applet)? > > Regards, > > Yannick Could you please enable the debug output via kdebugdialog, restart the filewatch service and attach the debug output? Here is how you would restart it - > $ qdbus org.kde.nepomuk.services.nepomukfilewatch /servicecontrol shutdown > wait for it to quit > $ nepomukservicestub nepomukfilewatch 1296383 16 73840 yannick.roehlly 2012-09-11 20:24:51 +0000 Created attachment 73840 nepomukservicestub nepomukfilewatch output Hi Vishesh, Here's the output (I commented inside the file). I don't know if it's useful as I have not the debug packages installed. If they are needed, tell me and I'll try again with them installed. Yannick 1296594 17 stephan.menzel 2012-09-12 10:03:04 +0000 (In reply to comment #14) > Note that this happens with an USB3 drive, although nepomuk is configured > not to deal with removable drives. Is it possible that this drive is not > considered as removable by nepomuk (although the system allows me to unmount > it with the new drives applet)? Hi Yannick, just a comment here: I have tried this with USB1 and 2 drives, as well as SD Cards. All were affected, although Nepomuk is configured to ignore them. HTH, Stephan 1304101 18 sami 2012-10-08 06:41:44 +0000 I am affected too but, strangely, on only one of my machines (out of three). Both of them have nepomuk enabled but file indexing completely disabled + external storage media ignored. They run KDE SC 4.9.2. 1305520 19 stephan.menzel 2012-10-13 16:57:51 +0000 (In reply to comment #18) > I am affected too but, strangely, on only one of my machines (out of three). > > Both of them have nepomuk enabled but file indexing completely disabled + > external storage media ignored. They run KDE SC 4.9.2. Weird. I have tested two setups and both are affected. I have also updated to 4.9.2 and reactivated nepomuk. All relevant nepomuk options are still ignored, forcing me to disable it again. Will there be a fix for this? 1307739 20 fatgerman 2012-10-20 20:43:21 +0000 I have the same problem, using KDE SC 4.9.2 on Kubuntu. Nepomuk not only scans USB devices but also any NFS shares that I have mounted through /etc/fstab. I've tried all the options - the option to make it ask me before indexing anything made dialogs appear, I clicked 'Ignore' but then it started indexing them anyway. The file indexer is disabled now (but hasn't always been) and the system tray applet says it is idle but disabling Nepomuk is the only way to make the disc activity stop. It's creating enough activity that connections over NFS keep dying. 1307924 21 sami 2012-10-21 14:42:57 +0000 The problem just occurred on a machine that was previously not affected. The following command enabled me to unmount my HD: qdbus org.kde.NepomukServer /servicemanager stopService nepomukfilewatch 1313948 22 orion 2012-11-09 17:11:16 +0000 Seeing this on a couple Fedora systems. It also picks up nfs automounted directories. Ignore all removable media is selected. File Indexer is disabled on at least one of them. nepomuk-core-4.9.2-5.fc17.i686 1313949 23 hrvoje.senjan 2012-11-09 17:15:11 +0000 Just to add info that the bug is also present with current master 1314342 24 stephan.menzel 2012-11-10 21:34:19 +0000 Could we please get a heads up from the developers about this one? Maybe there is anything we can do to move things along here? So far I have to disable Nepomuk completely because of this one and bug 305486 1315567 25 chalkerx 2012-11-14 17:40:49 +0000 I can reproduce this on my portable harddrive (formatted in ext4), if it's mounted before nepomukfilewatch is launched. 1315570 26 chalkerx 2012-11-14 17:49:23 +0000 Qt: 4.8.3, KDE: 4.9.3 1317616 27 christian.fontana 2012-11-22 21:38:34 +0000 I report the same issue with kubuntu 12.10. I've to stop semantic desktop to umount removable device christian f. 1318230 28 w01dnick 2012-11-25 06:01:33 +0000 As for me, if I just mount USB thumb, usually all is 'ok', but sometimes nepomukservicestub opens some folder on it and do nothing else (used folder is constant). When open drive in Dolphin, chances are higher. When I mount external HDD (one of partitions) with ext4, nepomukservicestub begin to indexing that drive (lsof shows different folders). KDE SC 4.9.3 (from openSUSE binaries). 1319483 29 martin 2012-11-29 18:01:42 +0000 I'm seeing this with KDE 4.10 beta 1. Plug in a removable hard drive, I get asked whether nepomuk should index it. I say no. (Removable device indexing is disabled in system settings). The indexing indeed doesn't happen, however nepomuk sits idly on the removable disk, preventing me to unmount it. lsof shows : nepomukse 1556 martin 115r DIR 8,17 4096 2 /media/d8d73d06-239f-44ce-a607-27282b824a3b If I kill this service, and unmount before it gets respawned, the unmount is successful. Happens on a clean KDE config. 1320396 30 tim.eberhardt 2012-12-02 13:46:04 +0000 Confirming this using kde 4.9.3 and qt 4.8.3 on gentoo linux amd64. Blocking process is nepomukservicestub. 1320725 31 me 2012-12-03 15:01:12 +0000 Git commit 662d24f734efad461d74a11488519269ec611496 by Vishesh Handa. Committed on 03/12/2012 at 15:47. Pushed by vhanda into branch 'master'. FileWatch: Remove any existing dirIterator when removing the watches When issuing a command to remove the watches, watches could be being added at that point. In that case one should remove those iterators so that watches are not added after it is unmounted. Also, the dirIterators seem to prevent the medium from being unmounted. Also make sure _k_addWatches is invoked if the dir iterater list is not empty. There can be a case when there is only 1 dir iterator, and it fails to add a watch. In that case _k_addWatches is not called again, and that iterator is never removed. This happened to me for a 'lost+found' directory. FIXED-IN: 4.10 M +15 -5 services/filewatch/kinotify.cpp M +1 -0 services/filewatch/nepomukfilewatch.cpp http://commits.kde.org/nepomuk-core/662d24f734efad461d74a11488519269ec611496 1320957 32 chalkerx 2012-12-04 09:11:42 +0000 Thanks! 1324695 33 me 2012-12-18 19:34:18 +0000 *** Bug 307595 has been marked as a duplicate of this bug. *** 1327442 34 me 2012-12-30 16:50:07 +0000 *** Bug 312389 has been marked as a duplicate of this bug. *** 1329278 35 pereira.alex 2013-01-06 21:01:40 +0000 I am testing openSUSE KDE 4.10 RC2. I am suffering from this bug. I have an external usb disk, and although I have "ignore removable devices" setting selected, nepomuk still tries to index the external usb disk. I cannot remove the usb disk until I disable nepomuk. After that I can remove it safelly. Also , lsof shows that its nepomuk that is using the usb disk. Thanks 1329392 36 me 2013-01-07 08:11:23 +0000 (In reply to comment #35) > I am testing openSUSE KDE 4.10 RC2. > > I am suffering from this bug. I have an external usb disk, and although I > have "ignore removable devices" setting selected, nepomuk still tries to > index the external usb disk. > > I cannot remove the usb disk until I disable nepomuk. After that I can > remove it safelly. > > Also , lsof shows that its nepomuk that is using the usb disk. > > Thanks oh man. Really? Could you check if running $ qdbus org.kde.nepomuk.services.nepomukfilewatch /servicecontrol shutdown fixes the issue? Also, are you sure it tries to index the the external usb disk? Or does it just try to install watches? 1329404 37 pereira.alex 2013-01-07 09:12:00 +0000 At the moment i cannot check it, but to add : I have 3 distributions installed in my computer ( i like to test :) ) and : openSUSE does it; fedora does it; kubuntu doesnt do it ! i tried several times to reproduce this bug on kubuntu but was not able to. maybe a case of distribution patches ? Thanks 1331199 38 humufr 2013-01-11 20:44:08 +0000 It is present with kubuntu and package for 4.10 rc2. The only workaround I did find is to disable nepomuk. (In reply to comment #37) > At the moment i cannot check it, but to add : > > I have 3 distributions installed in my computer ( i like to test :) ) and : > > openSUSE does it; > fedora does it; > kubuntu doesnt do it ! i tried several times to reproduce this bug on > kubuntu but was not able to. > > maybe a case of distribution patches ? > > Thanks 1332226 39 meyerm 2013-01-15 09:24:45 +0000 It's also a problem on Archlinux (4.9.5). 1332368 40 fedux 2013-01-15 19:15:58 +0000 (In reply to comment #36) > (In reply to comment #35) > > I am testing openSUSE KDE 4.10 RC2. > > > > I am suffering from this bug. I have an external usb disk, and although I > > have "ignore removable devices" setting selected, nepomuk still tries to > > index the external usb disk. > > > > I cannot remove the usb disk until I disable nepomuk. After that I can > > remove it safelly. > > > > Also , lsof shows that its nepomuk that is using the usb disk. > > > > Thanks > > oh man. Really? Could you check if running > $ qdbus org.kde.nepomuk.services.nepomukfilewatch /servicecontrol shutdown > fixes the issue? > > Also, are you sure it tries to index the the external usb disk? Or does it > just try to install watches? That worked for me. I could umount the device after that command. I'm using archlinux. $ lsof /media/64EE32CBEE329570/ COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME nepomukse 2755 fedux 27r DIR 8,17 4096 5 /media/64EE32CBEE329570 nepomukse 2755 fedux 28r DIR 8,17 4096 36 /media/64EE32CBEE329570/boot Output of ps: 2755 ? SNl 0:11 /usr/bin/nepomukservicestub nepomukfilewatch $ LANG=C /usr/bin/nepomukservicestub --version Qt: 4.8.4 KDE Development Platform: 4.9.5 Nepomuk Service Stub: 0.1.0 1332386 41 johan.thelmen 2013-01-15 20:43:35 +0000 I got this with updated Kubuntu quantal with quantal-backports and quantal-updates. I have upgraded to raring (in development) and have not seen this problem again. 1333153 42 rm 2013-01-18 17:44:56 +0000 (In reply to comment #36) > oh man. Really? Could you check if running > $ qdbus org.kde.nepomuk.services.nepomukfilewatch /servicecontrol shutdown > fixes the issue? > > Also, are you sure it tries to index the the external usb disk? Or does it > just try to install watches? I have Opensuse 12.2 with KDE 4.9.5. Entering $ qdbus org.kde.nepomuk.services.nepomukfilewatch /servicecontrol shutdown helps, but only temporarily - i.e. for the active KDE session. A logout of KDE and a new login will lead to the old problem as soon as you mount an external USB device again. 1337113 43 alexandre.bonneau 2013-02-01 16:01:33 +0000 I can confirm comment #11, on Kubuntu using kde 4.9.5 I can't unmount some usb3 devices. Oddly, it does not happen every time. I still haven't figured out what triggers this wrong behavior. To be able to unmount your external devices, you have to completely disable nepomuk. If you only suspend indexing, nepomukservicestub is still 'locking' the devices. 1339631 44 stephan.menzel 2013-02-09 17:43:10 +0000 I have just upgraded to KDE 4.10 and can't reproduce it anymore. Looks like this is indeed fixed. Thanks! 1339652 45 sami 2013-02-09 18:10:49 +0000 Not on my machine that was previously unaffected. lsof prints: nepomukse 19925 (me) 21r DIR 8,17 4096 2 /run/media/(me)/(device) I’ve configured the file indexer to ignore external storage devices. Maybe it is due to the switch to udisks2 (and thus /media/(device) → /run/media/(user)/(device))? 1339944 46 karsten.htw 2013-02-10 11:33:39 +0000 For me (like Sami B.), this bug isn't fixed in KDE 4.10! If I activate Nepomuk, I can't unmount removable media. There are some process, which are prevent this. Her is an output from the terminal: ########################################## ]$ lsof | grep '/run/media/karsten/BackUp' nepomukse 9144 karsten 14r DIR 8,81 4096 2097155 /run/media/karsten/BackUp/Back_In_Time/Desktop QThread 9144 9150 karsten 14r DIR 8,81 4096 2097155 /run/media/karsten/BackUp/Back_In_Time/Desktop QInotifyF 9144 9152 karsten 14r DIR 8,81 4096 2097155 /run/media/karsten/BackUp/Back_In_Time/Desktop ######################################### If I deactivate Nepomuk, I can (without problems) unmount removable media. In the setting of Nepomuk I have configured to ignored removable media and there are no files or folders on the removable media configured (for searching and indexing in Nepomuk). 1340083 47 stephan.menzel 2013-02-10 18:23:26 +0000 Well, Karsten and Sami B, one of you should reopen this, so it gets some attention. I can't since it's gone on this machine here where I first observed it. 1340098 48 kevin.kofler 2013-02-10 18:52:31 +0000 Reopening based on comment #45 and comment #46. I think Sami B. is probably right, there must be a hardcoded /media somewhere, /run/media needs to be added to that for udisks2. 1340289 49 rm 2013-02-11 09:37:37 +0000 For me the KDE 4.10 reaction (combination of nepomuk and device notifier reactions) is even stranger than with KDE 4.9.5 before: I attach an external USB drive with 3 partitions - all 3 partitions are first shown by the device notifier as expected. I mount one of the partitions (by using the device notifier). I try to unmount it again. Not possible - a warning appears that one process is still active. lsof shows it is a nepomuk service lsof +d /media/f2e85cdf-d38c-4528-b716-e6832fa7f669 COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME nepomukse 5606 xmr 9r DIR 8,22 4096 2 /media/f2e85cdf-d38c-4528-b716-e6832fa7f669 Some seconds later I try to unmount the external partition of the USB-device once again - with the unmount options in the device notifier. Now it works - the mounted partition really gets unmounted. However - the KDE device notifier afterwards does not show any external device any longer - which is wrong. 1340290 50 rm 2013-02-11 09:42:07 +0000 Addition to my comment #49: Nepomuk's indexing was of course configured to ignore all removeable media. 1340291 51 rm 2013-02-11 09:43:18 +0000 Addition to my comment #49: Nepomuk's indexing was of course configured to ignore all removeable media. 1341345 52 humufr 2013-02-13 12:56:35 +0000 Hi, another point, in one of my external hard drive there are two partitions, one NTFS and one ext2. I do not have any problem to unmount the NTFS one but the ext2 is always occupied thanks to nepomuk indexer (with the configuration set to ignore all removable hard drive naturally). 1341346 53 humufr 2013-02-13 12:57:18 +0000 I forgot: kubuntu with final 4.10 1341408 54 circular.ebin 2013-02-13 15:14:47 +0000 I'm having the same issue with an inability to unmount removable media (my ipod & pendrive), in Kubuntu 12.10, with KDE 4.10.00. Nepomuk is set to ignore removable media. Though it's ejected and notifications state its ok to remove, I have been removing the unmounted media without any data losses (knocking on wood). One of my pendrives formatted to ext4 will properly unmount when ejected, however when the format is fat32 or ext3, unmount doesn't happen. 1342060 55 me 2013-02-15 13:59:40 +0000 Until I can reproduce this I unfortunately cannot fix it. As a workaround, I've created this page - userbase.kde.org/Nepomuk/RemovableMediaHandling which offers a simple solution. When the device cannot be unmounted is the mount point the only directory for which 'lsof' returns nepomuk or does it do so for other directories as well? 1342070 56 karsten.htw 2013-02-15 14:45:29 +0000 (In reply to comment #55) > Until I can reproduce this I unfortunately cannot fix it. As a workaround, > I've created this page - userbase.kde.org/Nepomuk/RemovableMediaHandling > which offers a simple solution. Ok, thank you. This workaround works for me. > > When the device cannot be unmounted is the mount point the only directory > for which 'lsof' returns nepomuk or does it do so for other directories as > well? Yes. On my system the mount point is the only directory for which 'lsof' returns nepomuk (see my comment: https://bugs.kde.org/show_bug.cgi?id=304943#c46 ) 1343322 57 bugs.kde.org 2013-02-19 13:28:03 +0000 > When the device cannot be unmounted is the mount point the only directory > for which 'lsof' returns nepomuk or does it do so for other directories as > well? No, on my system (4.9.5), there are others as well. The problem only happens on really removable media (usb-harddrive), but not on internal media (sata-harddrive) that is effectively also used in the same way (mounted from time to time). Why the different treatment of these similar components? BTW, I my workaround was to do a lazy unmount, i.e., # umount -l path/to/mountpoint 1343354 58 me 2013-02-19 14:17:56 +0000 I've pushed this patch into 4.10.1. It might be the cause of the problem - commit af371633a3cc71a5649a2d0335f5a42794b55c4d Author: Vishesh Handa <me@vhanda.in> Date: Tue Feb 19 19:39:49 2013 +0530 kinotify removeWatch: use QDirIterator::path not filePath It could be that the iterator doesn't contain any elements or that next() still hasn't been called. In that case QDirIterator::filePath would not return anything and it wouldn't be removed. This might be the reason why some removeable media cannot be removed. I'm not changing the status of this bug, cause I'm not sure if this fixes it. Please do let me know once 4.10.1 has been released. 1343358 59 me 2013-02-19 14:22:23 +0000 *** Bug 315368 has been marked as a duplicate of this bug. *** 1343700 60 bugs.kde.org 2013-02-20 12:45:31 +0000 A follow-up to my report: > No, on my system (4.9.5), there are others as well. The problem only happens > on really removable media (usb-harddrive), but not on internal media > (sata-harddrive) that is effectively also used in the same way (mounted from > time to time). Why the different treatment of these similar components? I've tried the workaround from the userbase website; it does not work. Note that the removable media is being manually mounted under a subdirectory of /mnt 1343713 61 me 2013-02-20 13:17:20 +0000 (In reply to comment #60) > A follow-up to my report: > > > No, on my system (4.9.5), there are others as well. The problem only happens > > on really removable media (usb-harddrive), but not on internal media > > (sata-harddrive) that is effectively also used in the same way (mounted from > > time to time). Why the different treatment of these similar components? > > I've tried the workaround from the userbase website; it does not work. Note > that the removable media is being manually mounted under a subdirectory of > /mnt The workaround will not work in the 4.9 series. It's only there in 4.10 1344901 62 christian_bay 2013-02-24 15:58:22 +0000 I think this discussion misses a very important point. I set up nepomuk to only index my home directory and some of its subdirectories (this is probably the default anyways). I would assume that this models a whitelist for folders to be indexed. Why would nepomuk even bother to index stuff that is apparantly not beneath my home directory like /media? To my mind this is the fundamental problem here. If there is a whitelist specified, then nepomuk should ignore anything that is not included there. Period. If someone really wants to index removable media (I don't really see a use case for this anyways), then one should include /media in the whitelist. I'm on Kubuntu 12.10, KDE 4.9.4. I see this issue on two laptops with different USB hard disks, USB 2.0 USB 3.0. $ nepomukindexer --version Qt: 4.8.3 KDE Development Platform: 4.9.4 NepomukIndexer: 0.1.0 1345051 63 chalkerx 2013-02-25 06:03:02 +0000 > I think this discussion misses a very important point. I set up nepomuk to only index my home directory and some of its subdirectories (this is probably the default anyways). I would assume that this models a whitelist for folders to be indexed. Why would nepomuk even bother to index stuff that is apparantly not beneath my home directory like /media? You missed something: http://userbase.kde.org/Nepomuk/RemovableMediaHandling 1345052 64 chalkerx 2013-02-25 06:06:31 +0000 Long story put short: indexing is indexing, metadata is metadata. Watches are needed so that metadata wouldn't be lost when moving files, even is indexing is completely disabled in the whole system. There is a separate configuration option that turns this behavior off, but no checkbox in the gui for it now. 1348201 65 stephan.menzel 2013-03-06 09:29:01 +0000 (In reply to comment #47) > Well, Karsten and Sami B, one of you should reopen this, so it gets some > attention. I can't since it's gone on this machine here where I first > observed it. I have to correct this one. It has just re-appeared. So it is not fixed for me either in 4.10 1348218 66 alexandre.bonneau 2013-03-06 10:19:54 +0000 On my system (with 4.10), the bug only arises for usb hardisks, not for usb flash keys, even if I use the same usb3 port. Could that be related ? 1351723 67 sergio 2013-03-16 21:00:52 +0000 I'm still getting this on 4.10.1, lsof display more than mount point: nepomukse 1246 sergio 14r DIR 8,17 4096 2 /media/Backup nepomukse 1246 sergio 22r DIR 8,17 4096 917507 /media/Backup/backintime/tablet/sergio nepomukse 1246 sergio 23r DIR 8,17 4096 917508 /media/Backup/backintime/tablet/sergio/1 nepomukse 1246 sergio 24r DIR 8,17 4096 2539540 /media/Backup/backintime/tablet/sergio/1/20121116-001631-683/backup/home/sergio nepomukse 1246 sergio 25r DIR 8,17 4096 2736201 /media/Backup/backintime/tablet/sergio/1/20121116-001631-683/backup/home/sergio/web nepomukse 1246 sergio 26r DIR 8,17 24576 3842098 /media/Backup/backintime/tablet/sergio/1/20121116-001631-683/backup/home/sergio/web/press2work nepomukse 1246 sergio 27r DIR 8,17 4096 3850255 /media/Backup/backintime/tablet/sergio/1/20121116-001631-683/backup/home/sergio/web/press2work/tiny_mce nepomukse 1246 sergio 28r DIR 8,17 4096 3850256 /media/Backup/backintime/tablet/sergio/1/20121116-001631-683/backup/home/sergio/web/press2work/tiny_mce/plugins 1351724 68 sergio 2013-03-16 21:01:27 +0000 I'm still getting this on 4.10.1, lsof display more than mount point: COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME nepomukse 1246 sergio 14r DIR 8,17 4096 2 /media/Backup nepomukse 1246 sergio 22r DIR 8,17 4096 917507 /media/Backup/backintime/tablet/sergio nepomukse 1246 sergio 23r DIR 8,17 4096 917508 /media/Backup/backintime/tablet/sergio/1 nepomukse 1246 sergio 24r DIR 8,17 4096 2539540 /media/Backup/backintime/tablet/sergio/1/20121116-001631-683/backup/home/sergio nepomukse 1246 sergio 25r DIR 8,17 4096 2736201 /media/Backup/backintime/tablet/sergio/1/20121116-001631-683/backup/home/sergio/web nepomukse 1246 sergio 26r DIR 8,17 24576 3842098 /media/Backup/backintime/tablet/sergio/1/20121116-001631-683/backup/home/sergio/web/press2work nepomukse 1246 sergio 27r DIR 8,17 4096 3850255 /media/Backup/backintime/tablet/sergio/1/20121116-001631-683/backup/home/sergio/web/press2work/tiny_mce nepomukse 1246 sergio 28r DIR 8,17 4096 3850256 /media/Backup/backintime/tablet/sergio/1/20121116-001631-683/backup/home/sergio/web/press2work/tiny_mce/plugins 1353575 69 korgens 2013-03-22 16:28:33 +0000 It seems that this bug is back for me, too. I tested on Archlinux: Linux 3.8.3-2-ARCH #1 SMP PREEMPT Sun Mar 17 13:04:22 CET 2013 x86_64 GNU/Linux My version of KDE: 4.10.1 Fresh install of KDE (deleted all .kde4, .local and .config files before loging in). Configuration: Configuration Settings -> Nepomuk server -> Indexing: "ignore all removable devices" ... -> Custom folders: I've left only folders inside /home checked How to reproduce: 1) Place an USB drive copy, copy some video files to it. 2) Try to "safely remove" from Dolphing or from "available devices" on the system tray. Message says impossible because there is a program accessing it. 3) From the command line, issuing lsof /dev/sdd1 shows nepomuk. Not even root can unmount the device. Killing all nepomuk related processes doesn't help, because they get respawned. The worst part is having to explain to other family members and work associates that they need to shutdown or logoff their session... ;-) 1353689 70 cruzki123 2013-03-23 09:28:29 +0000 You don't need to shutdown. Dissabling nepomuk (from the systemtry, for example) you can remove you usb key and then enable again :) 1354485 71 kde 2013-03-26 05:42:48 +0000 I also suffer from the inability to umount my USB hard-drive after my Fedora 17 system updated to nepomuk 4.10.1 on March 20th. Luckily comment 36 of this thread suggested running /usr/bin/qdbus org.kde.nepomuk.services.nepomukfilewatch /servicecontrol shutdown which I did. At that point I can umount my USB drive. I hope that helps. 1354648 72 wilcobeekhuizen 2013-03-26 15:58:28 +0000 I can confirm this bug is alive on KDE 4.10. Nepomuk is keeping processes open on removable media even when set to ignore removable media. 1364054 73 Oliver 2013-04-26 06:27:19 +0000 I noticed the same problem today with an external USB3 drive. Nepomuk is configured to ignore removable media. I have to completely disable Nepomuk to be able to unmount the drive again. Running Gentoo Linux with KDE 4.10.1 $ lsof /run/media/oliver/OSCHWABE500G COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME nepomukse 24702 oliver 16r DIR 8,113 4096 1253377 /run/media/oliver/OSCHWABE500G/data nepomukse 24702 oliver 17r DIR 8,113 4096 22167553 /run/media/oliver/OSCHWABE500G/data/Backup T60 nepomukse 24702 oliver 22r DIR 8,113 4096 22167555 /run/media/oliver/OSCHWABE500G/data/Backup T60/Backup_D nepomukse 24702 oliver 23r DIR 8,113 4096 22167571 /run/media/oliver/OSCHWABE500G/data/Backup T60/Backup_D/Programme nepomukse 24702 oliver 24r DIR 8,113 4096 22167655 /run/media/oliver/OSCHWABE500G/data/Backup T60/Backup_D/Programme/Picasa2 nepomukse 24702 oliver 25r DIR 8,113 4096 22167804 /run/media/oliver/OSCHWABE500G/data/Backup T60/Backup_D/Programme/Picasa2/web nepomukse 24702 oliver 26r DIR 8,113 4096 22167946 /run/media/oliver/OSCHWABE500G/data/Backup T60/Backup_D/Programme/Picasa2/web/templates $ ps -ef|grep 24702 oliver 24702 24660 0 08:23 ? 00:00:01 /usr/bin/nepomukservicestub nepomukfilewatch 1364774 74 79530 bladud 2013-04-29 04:36:08 +0000 Created attachment 79530 Extra debug output patch Could someone who is experiencing this please recompile with the attached patch, and grab the debug output, following Vishesh's instructions in comment 15? 1388367 75 wilcobeekhuizen 2013-08-07 07:09:44 +0000 I can no longer reproduce this bug with KDE 4.10.5 on Arch Linux 1394683 76 Oliver 2013-09-03 05:02:41 +0000 Can't reproduce it with KDE 4.10.5 on Gentoo Linux either. 1401479 77 me 2013-10-04 13:32:34 +0000 Marking this as FIXED for the second time. Please feel free to reopen it if it still occurs. (It would be even more awesome if you could find the time to be available online so that we could debug this together) 73840 2012-09-11 20:24:51 +0000 2012-09-11 20:24:51 +0000 nepomukservicestub nepomukfilewatch output konsole.txt text/plain 4932 yannick.roehlly fiDina/ina/ina8gbmVwb211a3NlcnZpY2VzdHViIG5lcG9tdWtmaWxld2F0Y2gKbmVwb211a2Zp bGV3YXRjaCgxNDM3NCkvbmVwb211ayAobGlicmFyeSkge2Fub255bW91c306Okdsb2JhbE1vZGVs Q29udGFpbmVyOjppbml0OiBDb25uZWN0aW5nIHRvIGxvY2FsIHNvY2tldCAiL3RtcC9rc29ja2V0 LXlhbm5pY2svbmVwb211ay1zb2NrZXQiCm5lcG9tdWtmaWxld2F0Y2goMTQzNzQpL25lcG9tdWsg KGZpbGV3YXRjaCBzZXJ2aWNlKSBOZXBvbXVrMjo6RmlsZVdhdGNoOjp3YXRjaEZvbGRlcjogIi9o b21lL3lhbm5pY2siCm5lcG9tdWtmaWxld2F0Y2goMTQzNzQpL25lcG9tdWsgKGZpbGV3YXRjaCBz ZXJ2aWNlKSBLSW5vdGlmeTo6YWRkV2F0Y2g6ICIvaG9tZS95YW5uaWNrIgpuZXBvbXVrZmlsZXdh dGNoKDE0Mzc0KS9uZXBvbXVrIChmaWxld2F0Y2ggc2VydmljZSkgS0lub3RpZnk6OlByaXZhdGU6 Om9wZW46Cm5lcG9tdWtmaWxld2F0Y2goMTQzNzQpL25lcG9tdWsgKGZpbGV3YXRjaCBzZXJ2aWNl KSBLSW5vdGlmeTo6UHJpdmF0ZTo6b3BlbjogU3VjY2Vzc2Z1bGx5IG9wZW5lZCBjb25uZWN0aW9u IHRvIGlub3RpZnk6IDEzCm5lcG9tdWtmaWxld2F0Y2goMTQzNzQpL25lcG9tdWsgKGZpbGV3YXRj aCBzZXJ2aWNlKSBOZXBvbXVrMjo6SW52YWxpZEZpbGVSZXNvdXJjZUNsZWFuZXI6OnJ1bjogU2Vh cmNoaW5nIGZvciBpbnZhbGlkIGxvY2FsIGZpbGUgZW50cmllcwpuZXBvbXVrZmlsZXdhdGNoKDE0 Mzc0KS9uZXBvbXVrIChmaWxld2F0Y2ggc2VydmljZSkgTmVwb211azI6OkludmFsaWRGaWxlUmVz b3VyY2VDbGVhbmVyOjpydW46IERvbmUgc2VhcmNoaW5nIGZvciBpbnZhbGlkIGxvY2FsIGZpbGUg ZW50cmllcwpuZXBvbXVrZmlsZXdhdGNoKDE0Mzc0KSBOZXBvbXVrMjo6UmVtb3ZhYmxlTWVkaWFD YWNoZTo6c2xvdFNvbGlkRGV2aWNlQWRkZWQ6ICIvb3JnL2ZyZWVkZXNrdG9wL1VEaXNrcy9kZXZp Y2VzL3NkYyIKbmVwb211a2ZpbGV3YXRjaCgxNDM3NCkgTmVwb211azI6OlJlbW92YWJsZU1lZGlh Q2FjaGU6OnNsb3RTb2xpZERldmljZUFkZGVkOiAiL29yZy9mcmVlZGVza3RvcC9VRGlza3MvZGV2 aWNlcy9zZGMxIgpuZXBvbXVrZmlsZXdhdGNoKDE0Mzc0KSBOZXBvbXVrMjo6UmVtb3ZhYmxlTWVk aWFDYWNoZTo6Y3JlYXRlQ2FjaGVFbnRyeTogVXNhYmxlICIvb3JnL2ZyZWVkZXNrdG9wL1VEaXNr cy9kZXZpY2VzL3NkYzEiCm5lcG9tdWtmaWxld2F0Y2goMTQzNzQpIE5lcG9tdWsyOjpSZW1vdmFi bGVNZWRpYUNhY2hlOjpzbG90QWNjZXNzaWJpbGl0eUNoYW5nZWQ6IHRydWUgIi9vcmcvZnJlZWRl c2t0b3AvVURpc2tzL2RldmljZXMvc2RjMSIKbmVwb211a2ZpbGV3YXRjaCgxNDM3NCkgTmVwb211 azI6OlJlbW92YWJsZU1lZGlhQ2FjaGU6OnNsb3RBY2Nlc3NpYmlsaXR5Q2hhbmdlZDogIi9vcmcv ZnJlZWRlc2t0b3AvVURpc2tzL2RldmljZXMvc2RjMSIgYWNjZXNzaWJsZSBhdCAiL21lZGlhL1Nh dXZlZ2FyZGVzIiB3aXRoIGlkZW50aWZpZXIgImZpbGV4Oi8vZTczZGU0MmUtOGM2ZS00MzI5LWE3 ZTEtMjRhNmVhNzkxNGJhIgpuZXBvbXVrZmlsZXdhdGNoKDE0Mzc0KS9uZXBvbXVrIChmaWxld2F0 Y2ggc2VydmljZSkgTmVwb211azI6OkludmFsaWRGaWxlUmVzb3VyY2VDbGVhbmVyOjpydW46IFNl YXJjaGluZyBmb3IgaW52YWxpZCBsb2NhbCBmaWxlIGVudHJpZXMKbmVwb211a2ZpbGV3YXRjaCgx NDM3NCkvbmVwb211ayAoZmlsZXdhdGNoIHNlcnZpY2UpIE5lcG9tdWsyOjpGaWxlV2F0Y2g6OnNs b3REZXZpY2VNb3VudGVkOiBEZXZpY2UgY29uZmlndXJlZCB0byBub3QgYmUgaW5kZXhlZC4KbmVw b211a2ZpbGV3YXRjaCgxNDM3NCkvbmVwb211ayAoZmlsZXdhdGNoIHNlcnZpY2UpIE5lcG9tdWsy OjpGaWxlV2F0Y2g6OnNsb3REZXZpY2VNb3VudGVkOiBJbnN0YWxsaW5nIHdhdGNoIGZvciByZW1v dmFibGUgc3RvcmFnZSBhdCBtb3VudCBwb2ludCAiL21lZGlhL1NhdXZlZ2FyZGVzIgpuZXBvbXVr ZmlsZXdhdGNoKDE0Mzc0KS9uZXBvbXVrIChmaWxld2F0Y2ggc2VydmljZSkgTmVwb211azI6OkZp bGVXYXRjaDo6d2F0Y2hGb2xkZXI6ICIvbWVkaWEvU2F1dmVnYXJkZXMiCm5lcG9tdWtmaWxld2F0 Y2goMTQzNzQpL25lcG9tdWsgKGZpbGV3YXRjaCBzZXJ2aWNlKSBLSW5vdGlmeTo6YWRkV2F0Y2g6 ICIvbWVkaWEvU2F1dmVnYXJkZXMiCm5lcG9tdWtmaWxld2F0Y2goMTQzNzQpL25lcG9tdWsgKGZp bGV3YXRjaCBzZXJ2aWNlKSBOZXBvbXVrMjo6SW52YWxpZEZpbGVSZXNvdXJjZUNsZWFuZXI6OnJ1 bjogRG9uZSBzZWFyY2hpbmcgZm9yIGludmFsaWQgbG9jYWwgZmlsZSBlbnRyaWVzCgojCiMgVGhl cmUgaXMgbm8gbW9yZSBvdXRwdXQgd2hpbGUgbmVwb211ayBpcyBzY2FubmluZyB0aGUgZGlyZWN0 b3J5LiBUaGVuLCBJIHRyeSB0byB1bm1vdW50IHRoZSBkcml2ZS4KIwoKbmVwb211a2ZpbGV3YXRj aCgxNDM3NCkvbmVwb211ayAoZmlsZXdhdGNoIHNlcnZpY2UpIEtJbm90aWZ5OjpyZW1vdmVXYXRj aDogIi9tZWRpYS9TYXV2ZWdhcmRlcyIKbmVwb211a2ZpbGV3YXRjaCgxNDM3NCkvbmVwb211ayAo ZmlsZXdhdGNoIHNlcnZpY2UpIEtJbm90aWZ5OjpyZW1vdmVXYXRjaDogIi9tZWRpYS9TYXV2ZWdh cmRlcyIKbmVwb211a2ZpbGV3YXRjaCgxNDM3NCkvbmVwb211ayAoZmlsZXdhdGNoIHNlcnZpY2Up IEtJbm90aWZ5OjpyZW1vdmVXYXRjaDogIi9tZWRpYS9TYXV2ZWdhcmRlcyIKbmVwb211a2ZpbGV3 YXRjaCgxNDM3NCkvbmVwb211ayAoZmlsZXdhdGNoIHNlcnZpY2UpIEtJbm90aWZ5OjpyZW1vdmVX YXRjaDogIi9tZWRpYS9TYXV2ZWdhcmRlcyIKbmVwb211a2ZpbGV3YXRjaCgxNDM3NCkvbmVwb211 ayAoZmlsZXdhdGNoIHNlcnZpY2UpIEtJbm90aWZ5OjpyZW1vdmVXYXRjaDogIi9tZWRpYS9TYXV2 ZWdhcmRlcyIgICAgIApuZXBvbXVrZmlsZXdhdGNoKDE0Mzc0KS9uZXBvbXVrIChmaWxld2F0Y2gg c2VydmljZSkgS0lub3RpZnk6OnJlbW92ZVdhdGNoOiAiL21lZGlhL1NhdXZlZ2FyZGVzIiAgICAg IApuZXBvbXVrZmlsZXdhdGNoKDE0Mzc0KS9uZXBvbXVrIChmaWxld2F0Y2ggc2VydmljZSkgS0lu b3RpZnk6OnNsb3RFdmVudDogIi8iIEV2ZW50SWdub3JlZCAgICAgICAgICAgICAgICAgICAgICAg Cm5lcG9tdWtmaWxld2F0Y2goMTQzNzQpL25lcG9tdWsgKGZpbGV3YXRjaCBzZXJ2aWNlKSBLSW5v dGlmeTo6c2xvdEV2ZW50OiAiLyIgRXZlbnRJZ25vcmVkICAgICAgICAgICAgICAgICAgICAgICAg ICAgCm5lcG9tdWtmaWxld2F0Y2goMTQzNzQpL25lcG9tdWsgKGZpbGV3YXRjaCBzZXJ2aWNlKSBL SW5vdGlmeTo6c2xvdEV2ZW50OiAiLyIgRXZlbnRJZ25vcmVkICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgCm5lcG9tdWtmaWxld2F0Y2goMTQzNzQpL25lcG9tdWsgKGZpbGV3YXRjaCBz ZXJ2aWNlKSBLSW5vdGlmeTo6c2xvdEV2ZW50OiAiLyIgRXZlbnRJZ25vcmVkICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIApuZXBvbXVrZmlsZXdhdGNoKDE0Mzc0KS9uZXBvbXVr IChmaWxld2F0Y2ggc2VydmljZSkgS0lub3RpZnk6OnNsb3RFdmVudDogIi8iIEV2ZW50SWdub3Jl ZCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIApuZXBvbXVrZmlsZXdh dGNoKDE0Mzc0KS9uZXBvbXVrIChmaWxld2F0Y2ggc2VydmljZSkgS0lub3RpZnk6OnNsb3RFdmVu dDogIi8iIEV2ZW50SWdub3JlZCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIApuZXBvbXVrZmlsZXdhdGNoKDE0Mzc0KS9uZXBvbXVrIChmaWxld2F0Y2ggc2VydmljZSkg S0lub3RpZnk6OnNsb3RFdmVudDogIi8iIEV2ZW50SWdub3JlZApuZXBvbXVrZmlsZXdhdGNoKDE0 Mzc0KS9uZXBvbXVrIChmaWxld2F0Y2ggc2VydmljZSkgS0lub3RpZnk6OnNsb3RFdmVudDogIi8i IEV2ZW50SWdub3JlZApuZXBvbXVrZmlsZXdhdGNoKDE0Mzc0KS9uZXBvbXVrIChmaWxld2F0Y2gg c2VydmljZSkgS0lub3RpZnk6OnNsb3RFdmVudDogIi8iIEV2ZW50SWdub3JlZApuZXBvbXVrZmls ZXdhdGNoKDE0Mzc0KS9uZXBvbXVrIChmaWxld2F0Y2ggc2VydmljZSkgS0lub3RpZnk6OnNsb3RF dmVudDogIi8iIEV2ZW50SWdub3JlZApuZXBvbXVrZmlsZXdhdGNoKDE0Mzc0KS9uZXBvbXVrIChm aWxld2F0Y2ggc2VydmljZSkgS0lub3RpZnk6OnNsb3RFdmVudDogIi8iIEV2ZW50SWdub3JlZApu ZXBvbXVrZmlsZXdhdGNoKDE0Mzc0KS9uZXBvbXVrIChmaWxld2F0Y2ggc2VydmljZSkgS0lub3Rp Znk6OnNsb3RFdmVudDogIi8iIEV2ZW50SWdub3JlZApuZXBvbXVrZmlsZXdhdGNoKDE0Mzc0KS9u ZXBvbXVrIChmaWxld2F0Y2ggc2VydmljZSkgS0lub3RpZnk6OnNsb3RFdmVudDogIi8iIEV2ZW50 SWdub3JlZApuZXBvbXVrZmlsZXdhdGNoKDE0Mzc0KS9uZXBvbXVrIChmaWxld2F0Y2ggc2Vydmlj ZSkgS0lub3RpZnk6OnNsb3RFdmVudDogIi8iIEV2ZW50SWdub3JlZApuZXBvbXVrZmlsZXdhdGNo KDE0Mzc0KS9uZXBvbXVrIChmaWxld2F0Y2ggc2VydmljZSkgS0lub3RpZnk6OnNsb3RFdmVudDog Ii8iIEV2ZW50SWdub3JlZApuZXBvbXVrZmlsZXdhdGNoKDE0Mzc0KS9uZXBvbXVrIChmaWxld2F0 Y2ggc2VydmljZSkgS0lub3RpZnk6OnNsb3RFdmVudDogIi8iIEV2ZW50SWdub3JlZApuZXBvbXVr ZmlsZXdhdGNoKDE0Mzc0KS9uZXBvbXVrIChmaWxld2F0Y2ggc2VydmljZSkgS0lub3RpZnk6OnNs b3RFdmVudDogIi8iIEV2ZW50SWdub3JlZApuZXBvbXVrZmlsZXdhdGNoKDE0Mzc0KS9uZXBvbXVr IChmaWxld2F0Y2ggc2VydmljZSkgS0lub3RpZnk6OnNsb3RFdmVudDogIi8iIEV2ZW50SWdub3Jl ZAoKIwojIFRoaXMgbGluZSBpcyByZXBlYXRlZCBhZ2FpbiBhbmQgYWdhaW4gd2l0aCBzb21ldGlt ZSB0aGUgInJlbW92ZVdhdGNoIiBsaW5lLgojCgoK 79530 2013-04-29 04:36:08 +0000 2013-04-29 04:36:08 +0000 Extra debug output patch file_304943.txt text/plain 918 bladud ZGlmZiAtLWdpdCBhL3NlcnZpY2VzL2ZpbGV3YXRjaC9raW5vdGlmeS5jcHAgYi9zZXJ2aWNlcy9m aWxld2F0Y2gva2lub3RpZnkuY3BwDQppbmRleCBlZDk5ODNlLi45ODY1OWQ0IDEwMDY0NA0KLS0t IGEvc2VydmljZXMvZmlsZXdhdGNoL2tpbm90aWZ5LmNwcA0KKysrIGIvc2VydmljZXMvZmlsZXdh dGNoL2tpbm90aWZ5LmNwcA0KQEAgLTI5NSwxNCArMjk1LDE4IEBAIGJvb2wgS0lub3RpZnk6OmFk ZFdhdGNoKCBjb25zdCBRU3RyaW5nJiBwYXRoLCBXYXRjaEV2ZW50cyBtb2RlLCBXYXRjaEZsYWdz IGZsYWdzDQogDQogYm9vbCBLSW5vdGlmeTo6cmVtb3ZlV2F0Y2goIGNvbnN0IFFTdHJpbmcmIHBh dGggKQ0KIHsNCisgICAga0RlYnVnKCk8PCJTaXplIG9mIGRpcml0ZXJhdG9yczoiPDxkLT5kaXJJ dGVyYXRvcnMuc2l6ZSgpOw0KICAgICAvLyBTdG9wIGFsbCBvZiB0aGUgZGlySXRlcmF0b3JzIHdo aWNoIGNvbnRhaW4gcGF0aA0KICAgICBRTXV0YWJsZUxpbmtlZExpc3RJdGVyYXRvcjxRRGlySXRl cmF0b3IqPiBpdGVyKCBkLT5kaXJJdGVyYXRvcnMgKTsNCiAgICAgd2hpbGUoIGl0ZXIuaGFzTmV4 dCgpICkgew0KICAgICAgICAgUURpckl0ZXJhdG9yKiBkaXJJdGVyID0gaXRlci5uZXh0KCk7DQog ICAgICAgICBpZiggZGlySXRlci0+cGF0aCgpLnN0YXJ0c1dpdGgoIHBhdGggKSApIHsNCisgICAg ICAgICAgICBrRGVidWcoKTw8IlJlbW92aW5nOiI8PGRpckl0ZXItPnBhdGgoKTsNCiAgICAgICAg ICAgICBpdGVyLnJlbW92ZSgpOw0KICAgICAgICAgICAgIGRlbGV0ZSBkaXJJdGVyOw0KICAgICAg ICAgfQ0KKyAgICAgICAgZWxzZQ0KKyAgICAgICAgICAgIGtEZWJ1ZygpPDwiTm90IHJlbW92aW5n OiI8PGRpckl0ZXItPnBhdGgoKTsNCiAgICAgfQ0KIA0KICAgICAvLyBSZW1vdmUgYWxsIHRoZSB3 YXRjaGVz