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 423247 - saved filenames should be normalize for conflict
saved filenames should be normalize for conflict
Status: RESOLVED DUPLICATE of bug 421736
Product: epiphany
Classification: Core
Component: I18N
unspecified
Other Linux
: Normal normal
: ---
Assigned To: Epiphany Maintainers
Epiphany Maintainers
Depends on:
Blocks: 423036
 
 
Reported: 2007-03-27 07:32 UTC by Denis Jacquerye
Modified: 2009-08-05 12:48 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Denis Jacquerye 2007-03-27 07:32:18 UTC
When saving a file, if there's already a file existing with a canonically
equivalent name, they should conflict and be considered to have the same name,
i.e. ask the user to overwrite the other.

For example, a file "école" is in the working directory, and a file "école"
is going to be saved. These are the same name for the user, they should be
considered as such by the application.
Note: first name has <U+0065 LATIN SMALL LETTER E + U+0301 COMBINING ACUTE
ACCENT>
second name has <U+00E9 LATIN SMALL LETTER E WITH ACUTE>

When saving a new file, the name should probably be normalized, NFC is probably
the safest for compatibility with legacy systems.
Comment 1 Denis Jacquerye 2007-03-27 07:32:51 UTC
blocks meta bug 423036
Comment 2 Christian Persch 2007-03-27 12:25:39 UTC
Since this concerns all modules, and also should be taken into account in the design of GVFS, IMHO this should be brought up on desktop-devel-list.
Comment 3 Cyril Brulebois 2007-09-06 07:48:40 UTC
I had a very quick look at the code, it looks like this is related to “BuildDownloadPath()” in embed/mozilla/MozDownload.cpp (and similar for xulrunner). Would the proposed behaviour mean that instead of doing “g_file_test (path, G_FILE_TEST_EXISTS)”, one should be browsing the content of this directory, and trying to match normalized filenames? In that case, maybe a dedicated function might be welcome, since the “g_file_test()” function is already called in “BuildDownloadPath()”. If that sounds correct to you, I could give a try at patching this file. (As far as I understand it, one might want to implement this feature right now, instead of waiting for GVFS to be production-ready.)
Comment 4 Christian Persch 2007-09-06 20:57:52 UTC
Part of the fix is to normalise the filename in GetFilePath (only the filename itself, since the parent path is provided); a patch for that would be nice :)

Another part is whether the check in BuildDownloadPath should check whether a file with the same name but not-normalised exists already; I think that's not feasible right now.
I'd say always producing the normalised filename but not matching non-normalised filenames when checking for existence is ok.

The question is which normalisation form to choose... if GVFS will use one form we should of course use the same now. (Normalisation + GVFS has been discussed afair, but inconclusively.)
Comment 5 Alexandre Franke 2009-08-05 12:48:14 UTC

*** This bug has been marked as a duplicate of 421736 ***