Re: normalizing filenames and strings

["Denis Jacquerye" <moyogo gmail com>]

On 4/5/07, Federico Mena Quintero <federico ximian com> wrote:
> El jue, 29-03-2007 a las 09:52 +0200, Alexander Larsson escribió:
> > On Wed, 2007-03-28 at 19:52 -0600, Federico Mena Quintero wrote:
> > >
> > > [Those functions don't normalize currently; maybe they need to... do you
> > > have a reproducible bug?]
> >
> > NO! They should not normalize! Then you can't open a file that has an
> > unnormalized filename.
>
> You mean
>
> 1. user types a UTF-8 filename to open it
> 2. the app does g_filename_from_utf8() and gets normalized
> 3. the file can't be opened because its filename on disk is not normalized
>
> ?
>
> But you would have to type the human-readable-filename in the first
> place, whereas normally one picks the file from a list (in which case
> there is no problem, since we know the filename-on-disk in advance).
>
> It *is* a problem for Save As (or anything that requires you to type a
> possibly-existing filename), since the file dialog (or whatever) needs
> to correlate the human-readable-filename with the filenames that are on
> disk.  I really don't know if GtkFileChooserEntry and the file chooser
> in SAVE mode deal with this correctly.
>
> Denis, could you please test that case and file a bug against the file
> chooser if it doesn't work?

The filechooser doesn't use the existing filename if what is typed is
canonically equivalent, even if autocompletion gets it right.
I had already opened
http://bugzilla.gnome.org/show_bug.cgi?id=421736 and
http://bugzilla.gnome.org/show_bug.cgi?id=423242

> [Alex is right; the functions shouldn't normalize out of the box, at
> least not g_filename_from_utf8().  I don't really see a problem with
> g_filename_to_utf8() normalizing for the app's benefit, although this
> makes it more likely to uncover bugs with apps that try to round-trip
> filenames.]