[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]