Bug 53164 - filename displayed incorrectly, shown as locked when it's not
Summary: filename displayed incorrectly, shown as locked when it's not
Status: RESOLVED DUPLICATE of bug 56071
Alias: None
Product: konqueror
Classification: Applications
Component: general (show other bugs)
Version: unspecified
Platform: RedHat Enterprise Linux Linux
: NOR normal
Target Milestone: ---
Assignee: Konqueror Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2003-01-19 20:36 UTC by Brandon Nuttall
Modified: 2003-06-04 18:46 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments
screenshot + another comment (178.39 KB, image/png)
2003-01-19 20:40 UTC, Brandon Nuttall
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Brandon Nuttall 2003-01-19 20:36:46 UTC
Version:            (using KDE KDE 3.0.3)
Installed from:    RedHat RPMs
OS:          Linux

Using RedHat 8 with the lastest version of KDE as distributed through the RedHat Network.

File names with odd characters are displaying incorrectly in Konquerer.  If a file has one of these odd characters in its filename, Konquerer is showing it as "locked" when it's really not.  I have seen this happen with the degree symbol and the Latin "AE" symbol.  (I don't know the character codes off hand.)

If this bug tracking database supports attached files, I'll attach a screenshot showing the effect.  If not, please email me and I'll send you a screenshot of the effect; it's really easier to understand if you see it in action.

How to reproduce:  I can provide a file with one of the symbols in the filename if necessary; again, I don't know the character code.
Comment 1 Brandon Nuttall 2003-01-19 20:40:45 UTC
Created attachment 785 [details]
screenshot + another comment

Yikes, it looks like the KDE terminal doesn't know what the character is,
either.  This doesn't explain why Konq thinks the file's locked, though.  As
you can see from the screenshot, XMMS knows what the character is supposed to
be, and the file plays fine.
Comment 2 Avi Alkalay 2003-06-03 15:45:07 UTC
This is a consequence from the same bug reported in #56071, #50270. 
Comment 3 Waldo Bastian 2003-06-04 18:46:27 UTC

*** This bug has been marked as a duplicate of 56071 ***