After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 689450 - Be consistent with Windows filename handling
Be consistent with Windows filename handling
Status: RESOLVED FIXED
Product: easytag
Classification: Other
Component: general
2.1.x
Other Windows
: Normal normal
: 2.1
Assigned To: EasyTAG maintainer(s)
EasyTAG maintainer(s)
: 724284 731386 740578 753979 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2012-12-01 19:09 UTC by David King
Modified: 2016-01-26 18:35 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description David King 2012-12-01 19:09:12 UTC
From the original bug reports:

https://sourceforge.net/tracker/?func=detail&aid=1739636&group_id=5216&atid=105216
https://sourceforge.net/tracker/?func=detail&aid=2858556&group_id=5216&atid=105216

Under Windows folder names in browser are displayed wrong. In my case (Russian interface) KOI-8 charset is used instead of cp-1251 (default Russian Windows charset).

If a filename contains any characters which are not in the default Windows codepage (like, æ or û on CP1250 on Polish versions of Windows), EasyTag fails badly. The results are random, including:
* just not seeing the file at all
* replacing the filename with ???????? (and failing on read)
* reporting the file as a directory, obviously failing when trying to enter it.

As on real operating systems everything is ok, proving proper handling of Unicode in core EasyTag, this strongly suggests you're using the ancient SomeFunctionA win32 APIs somewhere, which are known to be broken this way.
Comment 1 David King 2014-02-13 15:24:34 UTC
*** Bug 724284 has been marked as a duplicate of this bug. ***
Comment 2 David King 2014-06-09 06:57:09 UTC
*** Bug 731386 has been marked as a duplicate of this bug. ***
Comment 3 David King 2014-11-23 23:30:50 UTC
*** Bug 740578 has been marked as a duplicate of this bug. ***
Comment 4 David King 2015-08-23 18:25:07 UTC
*** Bug 753979 has been marked as a duplicate of this bug. ***
Comment 5 David King 2016-01-26 00:04:18 UTC
There was extensive refactoring of filename handling in EasyTAG 2.4.1, and this should now be fixed. All filenames are now treated as being in the GLib filename encoding (UTF-8 on Windows, and mostly UTF-8 elsewhere, but with some defined fallbacks). Functions which do IO have been adapted to use the GLib wrappers, which accept filenames in the GLib filename encoding and handle it in a way appropriate for the given platform. There is special treatment of id3lib on Windows, as it does not use the wide character API.

It is possible that there are still some problems or corner cases, but those should be dealt with as new and separate bugs.
Comment 6 msdobrescu@gmail.com 2016-01-26 18:35:01 UTC
Hi, I did not get the error messages anymore.
Now, it skips renaming files directly.
For files having no special chars, like "01. Just Let Go.flac".