Bug 157784 - sound-juicer can not handle special filesystem illegal characters
sound-juicer can not handle special filesystem illegal characters
Product: Fedora
Classification: Fedora
Component: sound-juicer (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: John (J5) Palmieri
Depends On:
  Show dependency treegraph
Reported: 2005-05-15 09:12 EDT by Jef Spaleta
Modified: 2013-03-13 00:48 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-04-19 13:57:53 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

External Trackers
Tracker ID Priority Status Summary Last Updated
GNOME Desktop 142600 None None None Never
GNOME Desktop 339058 None None None Never

  None (edit)
Description Jef Spaleta 2005-05-15 09:12:06 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):

How reproducible:
100% with the 99.9F album
Comment 1 Rik Cross 2005-07-18 15:36:33 EDT
This also happens with any song titles inclding illegal filename characters
(':', ';', etc.).
Comment 2 John Thacker 2006-04-14 15:01:41 EDT
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.
Comment 3 John Thacker 2006-04-14 15:07:44 EDT
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.
Comment 4 Jef Spaleta 2006-04-14 15:20:41 EDT
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.

Comment 5 John Thacker 2006-04-15 11:28:52 EDT
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.

Comment 6 John Thacker 2006-04-19 13:32:20 EDT
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?
Comment 7 Jef Spaleta 2006-04-19 13:52:30 EDT
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.

Comment 8 John Thacker 2006-04-19 13:57:53 EDT
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?

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