Summary: | tags lost after file moved to another directory | ||
---|---|---|---|
Product: | nepomuk | Reporter: | Robin Green <greenrd> |
Component: | general | Assignee: | Sebastian Trueg <sebastian> |
Status: | RESOLVED DUPLICATE | ||
Severity: | normal | CC: | finex, mutlu_inek, peter.penz19, plafe, schafi, sebastian, trueg |
Priority: | NOR | ||
Version: | unspecified | ||
Target Milestone: | --- | ||
Platform: | Compiled Sources | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: |
Description
Robin Green
2007-11-23 14:34:58 UTC
I implemented a service to take care of this. It currently lives in playground/base/nepomuk-kde/filewatch. I would be happy if you could test it for me. It still has some issues: - Only works on Linux - Only works for files in the home folder - Based on inotify and, thus, is restricted as inotify (i.e. ~ 8000 folders max, no nfs support, and so on) That would be just perfect for my needs, as I have root access so I can increase the 8192 watches limit in /proc. However, I tried it and it does not work for me. I first needed to comment out the test line in CMakeLists.txt to get it to build; then, when I ran it, it detected me moving a file called 1.jpeg from $HOME/newest to $HOME, but the metadata did not appear in dolphin. I moved it back again and the metadata reappeared. (I started dolphin *after* moving the file.) hm, does the service run? You can check that via qdbus kded /kded org.kde.kded.loadedModules It should contain nepomukfilewatch Ok, I found two stupid bugs in the thing: a double connect and a deadlock. Now it should work properly. Please test. No - same result. And I know the service is running - I started it myself, and I can see it noticing the file moves from the terminal messages. which svn revision is this? 740971 @Sebastian: I'm trying to go through the hundreds of Dolphin bug-reports, I hope it's OK that I reassign this issue to you :-) Working on this one. For Linux there is a service that takes care of it, but since it is based on inotify we get problems on Win/MAC. In any case, my plan is to get the service into 4.2. I just tested this on KDE SC 4.4 beta 2, using soprano and strigi from trunk. Moving and renaming files using Dolphin now preserved both tags and ratings. Tags and ratings, however, are not copied when I copy a file using Dolphin. Is this intentional? Moreover, when I rename or move files using the command line, tags and ratings are lost. When I rename or move the file to the previous name/location, tags and ratings reappear as per comment #2 A small addition to my comment from a few minutes back: when a folder which contains rated and tagged files is moved, the tags and ratings are lost. When renaming or moving is undone, they reappear. I'm using KDE 4.4 and when I'm tagging a file and use the nepomuk search to find all files with this tag, everything seems to work perfectky. When I move this file to a different directory, the tag still gets displayed correctly but the nepomuk search for the tag doesn't find the file anymore. I just tested this with KDE SC 4.4.82 (4.5 beta 2). The bug is fixed: moving files across directories keeps the file-tag association. The file shows up in subsequent searches. IMO, this bug report can be closed. Thanks to all developers involved! Actually, I was wrong. When moving or renaming files (or the folders which contain them) using the command line (while KDE + nepomuk are running) will still destroy the association between file and tag. So nothing changed. Sorry for the noise. mutlu: are you sure about that? even moving files on the command line should result on updated meta data like tags. At least on linux that should be the case. At least for me, this doesn't work if I try to move a file to another partition. Tested with KDE SC 4.5 RC 3 *** This bug has been marked as a duplicate of bug 161403 *** *** Bug 202945 has been marked as a duplicate of this bug. *** |