Re: Filenames, escaping, and GtkFileSystem

El mié, 24-03-2004 a las 17:55, Federico Mena Quintero escribió:
> Hi,
> I started to fix #136467 and found a few interesting things:
> - GtkFileSystem::make_path() is supposed to take in a folder path and a
> filename without path components, and produce folder_path + "/" +
> filename.  
> - However, gtk_file_system_unix_make_path() just uses
> g_build_filename(), which, for practical purposes, acts like
> g_strconcat() --- it also turns adjacent slashes into a single slash,
> but we can ignore that for now.  This means that
> gtk_file_system_unix_make_path ("/foo/bar", "/baz/beep"), which should
> fail because the second argument has path components, doesn't fail.
> - In contrast, gtk_file_system_gnome_vfs_make_path() uses
> gnome_vfs_uri_append_file_name(), which first escapes the filename, and
> then appends it to the URI --- for the example above, it would yield
> something like "/foo/bar/%37baz%37beep".
> - Nautilus flames you if you try to rename a file to something that
> contains a slash in it.  This makes people unhappy if they want to call
> a file "Report from the engineering/marketing teams".
> There are a few things we can do:
> 1. Specify that GtkFileSystem::make_path() should fail if the filename
> has path components.  In the context of GtkFileChooser, this would
> eventually bring up an error message box, very similar to the one
> Nautilus uses when you rename a file and try to put a slash in the name.
> 2. Specify that GtkFileSystem::make_path() must escape the filename,
> thus allowing any characters to appear in it, *and* then unescaping
> filenames when reading them from the file system.  This would make it
> possible to have file names like "Report from the engineering/marketing
> teams" above.  If we do this, we should modify Nautilus as well.
> I'm not sure what is the right thing to do.  People get unhappy if there
> are useful characters that they can't put in filenames, but doing
> escaping/unescaping everywhere a) goes against what every program does;
> b) may break applications which do filename munging on their own.
> Ideas?

The "/" on filenames provides ambiguity.  Because:
a) The user would create a file named "foo/bar"; but also
b) create a file named "bar" inside of the directory named "foo".

So, when you make any reference to "foo/bar", what does it means?
the file "foo/bar" or "foo/bar" as "bar" file in "foo"?

Also, it would be pretty anoying if the user could create files 
with such as name in the GUI but not in the shell or another usual
application that not uses our libraries. In other words, definitively
it will break applications.

OTOH, Windows doesn't allow the user names files with "/", I guess
for usability reasons as the explained.

Germán Poó Caamaño
mailto:gpoo ubiobio cl

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]