Bug 171052 - wrong encoding conversion of mount error messages
Summary: wrong encoding conversion of mount error messages
Status: RESOLVED WORKSFORME
Alias: None
Product: kdelibs
Classification: Unmaintained
Component: general (other bugs)
Version First Reported In: unspecified
Platform: unspecified Linux
: NOR normal
Target Milestone: ---
Assignee: kdelibs bugs
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-09-14 16:18 UTC by Alexander Patrakov
Modified: 2022-12-10 16:38 UTC (History)
0 users

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


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Alexander Patrakov 2008-09-14 16:18:14 UTC
Version:            (using KDE 4.1.1)
OS:                Linux
Installed from:    Unlisted Binary Package

To reproduce:

0) Use ru_RU.UTF-8 locale, or any other non-ISO-8859-1 locale that results in translated error messages from mount.

1) Misconfigure your system so that /media/sdb2 is mentioned in /etc/fstab (with noauto,user) but doesn't exist as a directory. Any other way to provoke a mount error also works.

2) Connect a disk, so that the sdb2 partition appears in the places view.

3) Click on the label of sdb2 in the places view. Dolphin will attempt to mount the partition and show an error message from the "mount" command in the bottom of the window.

Expected result: readable error, e.g.:

Произошла ошибка при обращении к DISK, система ответила: mount: точка монтирования /media/sdb2 не существует

(i.e.: An error occurred while accessing DISK, the system responded: mount: mount point /media/sdb2 does not exist)

Actual result: part of the translated string is glibberish:

Произошла ошибка при обращении к DISK, система ответила: _glibberish_ /media/sdb2 _glibberish_

as if the output of the mount command is somewhere converted to QString from Latin1, not from the local (incorrectly called 8-bit) charset.
Comment 1 Andrew Crouthamel 2018-11-02 04:23:11 UTC
Dear Bug Submitter,

This bug has been stagnant for a long time. Could you help us out and re-test if the bug is valid in the latest version? I am setting the status to NEEDSINFO pending your response, please change the Status back to REPORTED when you respond.

Thank you for helping us make KDE software even better for everyone!
Comment 2 Andrew Crouthamel 2018-11-16 02:48:02 UTC
Dear Bug Submitter,

This is a reminder that this bug has been stagnant for a long time. Could you help us out and re-test if the bug is valid in the latest version?

Thank you for helping us make KDE software even better for everyone!
Comment 3 Justin Zobel 2022-12-08 23:51:23 UTC
Thank you for reporting this issue in KDE software. As it has been a while since this issue was reported, can we please ask you to see if you can reproduce the issue with a recent software version?

If you can reproduce the issue, please change the status to "REPORTED" when replying. Thank you!
Comment 4 Alexander Patrakov 2022-12-09 10:41:03 UTC
I am not a KDE user anymore, but will try to reproduce this bug in a virtual machine on weekends.
Comment 5 Alexander Patrakov 2022-12-10 16:38:11 UTC
I have tried to reproduce the bug on today's KDE Neon image, and here are my findings:

1) It is still possible to provoke a mount error by including bad options in /etc/fstab. So the test case can still be executed.

2) Instead of calling mount directly, now (judging by the error message text) disk mounting on Linux goes through udisks2.

3) All error messages about mounting come from udisks2 via dbus.

4) Error messages that go through dbus are not marked for translation in udisks2 source code, and do not contain any non-ASCII characters.

Therefore, the code that displays mounting errors never receives input that could provoke visible encoding-conversion errors, and thus black-box testing is no longer possible. I tried and failed to look in the code whether it goes through QString::fromLatin1() or not.

As the bug, even if it in fact still exists, can no longer be triggered, let's resolve this as WORKSFORME.