Bug 626955 - Socket searched for under different paths
Socket searched for under different paths
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: kdirstat (Show other bugs)
13
All Linux
low Severity medium
: ---
: ---
Assigned To: Chitlesh GOORAH
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2010-08-24 14:19 EDT by Göran Uddeborg
Modified: 2010-10-23 03:04 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-10-23 03:04:53 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Göran Uddeborg 2010-08-24 14:19:04 EDT
Description of problem:
I have a problem when using kdirstat.  I don't run the KDE desktop, and I suspect the problem could be on a lower level in the KDE stack.  But I don't know where to point.  So I thought I start where I see the problem, and maybe someone can help me get a more direct test case.

Out of the box, kdirstat doesn't find any files.  I've used strace, and figured out it tries to use a socket under two different file names:

    /tmp/ksocket-göran/klauncherFSfDRg.slave-socket
    /tmp/ksocket-göran/klauncherFSfDRg.slave-socket

Those having fought with character encodings might recognize "ö" as what you get if you convert the letter "ö" from latin-1 to utf-8.  But what kdirstat tries to look up is the above paths with a UTF-8 encoding.  I.e. "ö" are the bytes 0303 0266 while "ö" are the bytes 0303 0203 0302 0266.

The path that actually exists is /tmp/ksocket-göran/klauncherFSfDRg.slave-socket.  But it kdirstat also tries to bind() and connect() to the longer path.

If I do a symbolic link frpm ksocket-göran to ksocket-göran in /tmp, kdirstat starts to work normally.  So this does indeed seem to be the problem.

Maybe having a non-ASCII letter in my login name is to stretch the formal standards a bit.  But this looks like a bug in any case.

Could this be a kdirstat problem, or is it as I suspect something lower in the stack?  In the latter case, would anyone know what a more direct test case would be?


Version-Release number of selected component (if applicable):
kdirstat-2.5.3-10.fc12.x86_64

How reproducible:
Every time
Comment 1 Chitlesh GOORAH 2010-10-23 03:04:53 EDT
kdistart will be obsoleted by k4dirstat.

Note You need to log in before you can comment on or make changes to this bug.