[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-bugs-dist
Subject:    [Bug 90581] New: rename / refresh of duplicate listings for same
From:       Justin Mason <jm-kde () jmason ! org>
Date:       2004-09-30 23:53:19
Message-ID: 20041001015317.90581.jm-kde () jmason ! org
[Download RAW message or body]

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
        
http://bugs.kde.org/show_bug.cgi?id=90581        
           Summary: rename / refresh of duplicate listings for same file can
                    cause SEGV and file deletion
           Product: juk
           Version: 2.0.1
          Platform: Debian testing
        OS/Version: Linux
            Status: UNCONFIRMED
          Severity: crash
          Priority: NOR
         Component: general
        AssignedTo: wheeler kde org
        ReportedBy: jm-kde jmason org


Version:           2.0.1 (using KDE KDE 3.3.0)
Installed from:    Debian testing/unstable Packages
OS:                Linux

OK, this one's really serious, because it's just eaten some of my music ;)

I'm not sure how exactly it happens, but JuK sometimes winds up with more than 1 entry in the Collection \
List for the same file.

Assuming that it means that there's two copies of the same tune floating about, I generally hit "Rename \
File..." to find out what their paths are.  (enh req: a context-menu-accessible "File Properties" dialog \
that listed this would be nice btw.)

Sometimes, however, they're actually the same file -- one file has "/path/to//file.mp3", whereas the \
other has "/path/to/file.mp3". (although AFAIK I just tried to reproduce the crash, and the two listings \
had only 1 filename; in other words, the Rename... dialog popped up with only 1 entry in its list.)

Anyway, a more reckless user like myself might think that hitting the OK button in the Rename dialog \
might act as a workaround, letting JuK realise that they're the same file.  so that's what I did ;)

The result of that is that the rename appears to complete safely, and the dialog disappears -- but there \
are still two entries in the Collection List.  So I tried to Refresh those two entries by: selecting \
both, context-menu, Refresh Items. that causes a coredump.

However, the files were OK -- but after this happened, I tried to reproduce it so I could capture a \
stacktrace.

I started JuK, and again the two listings of the same file were present in the List.  However, they had \
only 1 filename; in other words, the Rename File... dialog popped up with only 1 entry in its list!

Regardless, I hit OK, JuK coredumped -- but it deleted the file in question!   (and I failed to get the \
coredump, by absent-mindedly hitting "OK" on that too.)


[prev in list] [next in list] [prev in thread] [next in thread]