Red Hat Bugzilla – Bug 157784
sound-juicer can not handle special filesystem illegal characters
Last modified: 2013-03-13 00:48:22 EDT
Description of problem:
Suzanne Vega's 99.9FÂ° album using the default freeddb.org cd database pref
extracting into a fat32 mountpoint.
freedb gives me the album title 99.9FÂ° with the degree synbol
sound-juicer can't handle the degree symbol and throws an error about not being
able to write to the directory. Removing the degree symbol lets s-j proceed.
freedb also gives me a song title for track 4 as 99.9FÂ°. When s-j gets to track
4 it throws a similar error dialog about not being able to write to the file.
But this time s-j seems to hang completely and I have to forcibly kill it
Using "strip special characters" preference doesn't seem to have any effect.
Version-Release number of selected component (if applicable):
100% with the 99.9F album
This also happens with any song titles inclding illegal filename characters
(':', ';', etc.).
Well, "strip special characters" is supposed to only go after illegal filename
characters like shell commands, /, and such. If you look at upstream GNOME bug
142600, you'll see that recently sound-juicer was patched to strip out more of
the illegal filename characters when that option is use. So that should make it
better with respect to illegal characters.
However, "strip special characters" is NOT intended to change names from UTF8 to
ASCII for mountpoints which don't support UTF8 (or, mutatis mutandis, other
character sets.) It also, AFAIK, is not intended to pay attention to special
filesystem requirements. In the most absurd case, I'm pretty sure it would just
barf if you had something mounted as msdos with strict checking requiring only
8.3 filename length and not allowing long filenames at all.
It's not a case of "sound-juicer can't handle the degree symbol." The degree
symbol Â° is a legitimate filename character on ext2/ext3. I've created
filenames with that character before, and just tested sound-juicer extracting
filenames with that character. It works perfectly fine on a ext3 mountpoint.
The problem is that sound-juicer doesn't work around quirks in filesystems that
don't allow UTF8 names.
This really should be filed upstream, not here.
Can you verify this on a more recent version of sound-juicer, like 2.14.x?
I bet that there are still problems when extracting to filesystems that don't
accept general UTF8 characters.
I'll gladly retest and refile.
And to be clear... i don't really care if s-j garbles the text in the filename..
what I'm concerned about is the fact that s-j completely fails to handle the
situation with something approaching grace. It seems to handle the problem in
the album title fine. It throws an error and then lets me manually edit the
album tag so I can continue operations without an application failure. The
weirdness concerning the hangs on the offending symbol in the title tag is the
concern of the original report.
I don't care what the filename or the tag names end up being, what I care about
is s-j not hanging on the attempt like I observed. I'd be content with s-j
throwing an error dialog about the problem with enough information for me to be
able to manually edit the problematic tags so I can continue without s-j hanging
up and having to be forcible killed. I don't need it to fix a fat filesystem's
limitations automagically.. i just don't want to see sound-juicer keel over and
die when it runs into a fat filesystem limitation.
Yeah, I totally understand. After you retest, it's probably something that
should be filed upstream. I couldn't find an upstream bug that really matched
it; 142600 is about stripping Unix shell special characters, not the filesystem
OTOH, it does look like some changes five months ago made it use
g_filename_from_utf8() from glib, which is supposed to transform a UTF8 string
into the correct character set being used by the filesystem. In practice, I'm
not sure it will work quite right, especially when most of your filesystems are
UTF8 but you're ripping to a FAT mountpoint.
I tried ripping to a floppy which was mounted as not even vfat, but msdos (8.3
filenames and all that). No problem with the degree character Â°. (Now,
whether it's happy if you put it in a DOS machine, I don't know.) It even seems
to work ok with a few illegal filenames that work fine in Unix-- things like
extra trailing periods and the like. Puting a "?" into the filename does make
it hang with a bizarre error when writing to a vfat or msdos mounted drive,
although it rips fine into a Unix partition. But "strip special characters"
takes care of that one.
Can you please retest it, and possibly close it or file something upstream?
As soon as I can get a chance I'll retest. Feel free to close this based on on
the strength on your test. I'll reopen it upstream and ping this bug with a
comment if my retest still shows a problem.
Hmm, I tried again and now I can't replicate the hang. It throws up a
completely blank error box, but one that does have a close button. It aborts
the rip pretty much as expected except for no comprehensible error message. So
it's actually reasonably graceful, though a user may certainly wonder what went
wrong. A real error message should probably be added.
I filed it separately upstream as GNOME bug 339058, since the other bug seems
slightly different (about what "strip special characters" should strip.) I'm
going to close this as UPSTREAM, if you don't mind. If you still have the
problem, can you comment there?