On 15 Jan 2002 at 15:57, Andre Majorel wrote: > On 2002-01-15 11:59 -0000, Ian Abbott wrote: > > This is an initial proposal for naming the files and directories > > that Wget creates, based on the URLs of the retrieved documents. > > [massive snippage] > > Ian, can your proposal be summarised as : > > - in the internal representation of filenames, don't escape > anything (for instance, store "~" as "~", not "%7E"),
That's a separate issue as Wget currently escapes all characters in filenames that are "unsafe" HTTP characters, and it should really distinguish HTTP unsafe characters from OS/file-system unsafe characters. This means that Wget is already escaping all the characters that are problematic for Windows and more besides. The only exception being '?' which is explicitly included in the filename for a query (see compose_file_name() in url.c) and causes problems for Windows due to being an illegal character for that OS. Perhaps the Windows problem can be solved by a small change to the compose_file_name() function to avoid putting an explicit '?' in the file-name for Windows. I'm not sure if this should be replaced by some other character or by a %3F sequence (which would get changed to @3F later on Windows). (Incidentally, the compose_file_name() function also has a small buffer overflow problem in that it could overfill its result[] array by two characters in some cases.) Looking a bit more, the above is not always true as compose_file_name() is only called when no directory structure is to be created. When a directory structure is being created, mkstruct() is called instead of compose_file_name() (see url_filename()). There seem to be inconsistencies between mkstruct() and compose_file_name() in the way file-names are escaped - mkstruct() uses reencode_string(); compose_file_name() does its own thing. > - when doing fopen()'s and such, escape illegal characters > and only illegal characters. > > Is that correct ? I don't think I'd researched the existing situation closely enough as Wget is already doing most of what I proposed, except that it is escaping more characters than necessary for some file-systems and occasionally adding in an illegal character (on some file-systems) when it feels like it. Also, the inconsistencies in the way file-names are composed depending on what options are in use need to be fixed. I'd say ignore my previous "proposal", fix what's there already, and then maybe tune the safe/unsafe character handling for particular file-systems (with options to override this) later.
