Menu
▾
▴
dcplusplus-devel
|
From: itinerants <iti...@ho...> - 2007-11-14 10:24:58
|
In file... Util.cpp
Routine... Util::validateFileName
This attempts to convert an arbitrary "filename" into something that'll work
as a file name on the system it's running on. For example, the url of a hub
file list (" http://dchublist.com/hublist.xml.bz2") into a usable filename.
I can speak only for Macintosh, but '/' (and btw ':') need to be on the list
of "badChars" outside the "#ifdef _WIN32" switch, otherwise the filename
produced won't work.
R
|
|
From: <edv...@zo...> - 2007-11-14 21:20:40
|
Please get me off the mailinglist
Citeren itinerants <iti...@ho...>:
> In file... Util.cpp
> Routine... Util::validateFileName
>
> This attempts to convert an arbitrary "filename" into something that'll work
> as a file name on the system it's running on. For example, the url of a hub
> file list (" http://dchublist.com/hublist.xml.bz2") into a usable filename.
>
> I can speak only for Macintosh, but '/' (and btw ':') need to be on the list
> of "badChars" outside the "#ifdef _WIN32" switch, otherwise the filename
> produced won't work.
>
> R
>
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems? Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> dcplusplus-devel mailing list
> dcp...@li...
> https://lists.sourceforge.net/lists/listinfo/dcplusplus-devel
>
|
|
From: poy <po...@12...> - 2007-11-15 13:13:22
Attachments:
patch.patch
|
little fix, not tested of course.
as for ':', have a look at line 198 of Util.cpp. ;)
poy
----- Original Message -----
From: "itinerants" <iti...@ho...>
To: <dcp...@li...>
Sent: Wednesday, November 14, 2007 11:24 AM
Subject: [dcplusplus-devel] ValidateFileName problem on Macintosh...
> In file... Util.cpp
> Routine... Util::validateFileName
>
> This attempts to convert an arbitrary "filename" into something that'll
> work
> as a file name on the system it's running on. For example, the url of a
> hub
> file list (" http://dchublist.com/hublist.xml.bz2") into a usable
> filename.
>
> I can speak only for Macintosh, but '/' (and btw ':') need to be on the
> list
> of "badChars" outside the "#ifdef _WIN32" switch, otherwise the filename
> produced won't work.
>
> R
>
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems? Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> dcplusplus-devel mailing list
> dcp...@li...
> https://lists.sourceforge.net/lists/listinfo/dcplusplus-devel
>
>
|
|
From: James R. <si...@wa...> - 2007-11-15 13:27:20
|
From: poy=20 Sent: Thursday, November 15, 2007 1:13 PM To: Patches & development discussion=20 Subject: Re: [dcplusplus-devel] ValidateFileName problem on = Macintosh... little fix, not tested of course. as for ':', have a look at line 198 of Util.cpp. ;) Won't the addition of "/" to the list already containing "\" mean that = all the bits of ValidateFileName which appear to be doing some path work = will never match? One of the comments even implies it will be given = absolute paths, which are never going to work if you replace "/" and "\" = with "_", no? I guess the important question is whether ValidateFileName is expected = to accept and return a simple filename with no paths anywhere or not = and, if if paths are allowed/expected, are they meant to be preserved in = the output? --=20 James Ross |
|
From: poy <po...@12...> - 2007-11-15 14:00:41
|
yeah right - ignore that patch. :/
i guess validateFileName() tries to keep the path, cleaning only nested =
paths and bad chars. it might need to get re-written: no need to look =
for "/./", "//", etc when all '/' have been cleared.
itinerants, are you sure it "doesn't work" on Mac?
poy
----- Original Message -----=20
From: James Ross=20
To: DC++ Devel=20
Sent: Thursday, November 15, 2007 2:27 PM
Subject: Re: [dcplusplus-devel] ValidateFileName problem on =
Macintosh...
From: poy=20
Sent: Thursday, November 15, 2007 1:13 PM
To: Patches & development discussion=20
Subject: Re: [dcplusplus-devel] ValidateFileName problem on =
Macintosh...
little fix, not tested of course.
as for ':', have a look at line 198 of Util.cpp. ;)
Won't the addition of "/" to the list already containing "\" mean that =
all the bits of ValidateFileName which appear to be doing some path work =
will never match? One of the comments even implies it will be given =
absolute paths, which are never going to work if you replace "/" and "\" =
with "_", no?
I guess the important question is whether ValidateFileName is expected =
to accept and return a simple filename with no paths anywhere or not =
and, if if paths are allowed/expected, are they meant to be preserved in =
the output?
--=20
James Ross
-------------------------------------------------------------------------=
-----
=
-------------------------------------------------------------------------=
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a =
browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
-------------------------------------------------------------------------=
-----
_______________________________________________
dcplusplus-devel mailing list
dcp...@li...
https://lists.sourceforge.net/lists/listinfo/dcplusplus-devel
|
|
From: itinerants <iti...@ho...> - 2007-11-15 14:21:42
|
On 15/11/07 2:00 pm, "poy" <po...@12...> wrote:
In fact, I've looked into this some more...
1) validateFileName is a *bad* name (should be something like
"raionaliseFullPathSpecification", or whatever) - it takes full paths too,
rather than just file names, and, has rightly been pointed out, simply
adding '/' to the list of bad chars for the Mac messes things up.
2) The problem occurred on my build (on a Mac), when I wrote the bit to get
public hublists. In 2 places (" FavoriteManager::onHttpFinished", "
FavoriteManager::refresh") the hubURL is converted to a filename using
validateFileName - this produces "bad" names - the url=filename contains
extra '/' chars - extra folder levels to my OS, and those folders don't
exist.
http://hublist.hubtracker.com/hublist.xml.bz2 gets converted to...
http_/hublist.hubtracker.com/hublist.xml.bz2
What I've done is...
A) Invent a "urlToFileName" routine (replacing ':' and '/' with '_')
B) Replace those 2 calls listed above with calls to "urlToFileName" instead.
3) Whilst you could probably fix up validateFileName to act "differently" on
the actual filename part of a given path (although that might be hard since
the url looks like a pretty cool path), I don't think that's the way to go.
This isn't filename conversion, it's a url to filename conversion and
should, imho, have its own specific routine to do that.
static string urlToFileName(string tmp)
{
string::size_type i = 0;
// remove ':'
i = 0;
while( (i = tmp.find(':', i)) != string::npos) {
tmp[i] = '_';
i++;
}
// remove '/'
i = 0;
while( (i = tmp.find('/', i)) != string::npos) {
tmp[i] = '_';
i++;
}
return tmp;
}
> yeah right - ignore that patch. :/
>
> i guess validateFileName() tries to keep the path, cleaning only nested paths
> and bad chars. it might need to get re-written: no need to look for "/./",
> "//", etc when all '/' have been cleared.
>
> itinerants, are you sure it "doesn't work" on Mac?
>
> poy
> ----- Original Message -----
> From: James Ross
> To: DC++ Devel
> Sent: Thursday, November 15, 2007 2:27 PM
> Subject: Re: [dcplusplus-devel] ValidateFileName problem on Macintosh...
>
>
> From: poy
> Sent: Thursday, November 15, 2007 1:13 PM
> To: Patches & development discussion
> Subject: Re: [dcplusplus-devel] ValidateFileName problem on Macintosh...
>
>
> little fix, not tested of course.
>
> as for ':', have a look at line 198 of Util.cpp. ;)
> Won't the addition of "/" to the list already containing "\" mean that all
> the bits of ValidateFileName which appear to be doing some path work will
> never match? One of the comments even implies it will be given absolute paths,
> which are never going to work if you replace "/" and "\" with "_", no?
>
> I guess the important question is whether ValidateFileName is expected to
> accept and return a simple filename with no paths anywhere or not and, if if
> paths are allowed/expected, are they meant to be preserved in the output?
>
> --
> James Ross
>
>
> ------------------------------------------------------------------------------
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems? Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
>
>
> ------------------------------------------------------------------------------
>
>
> _______________________________________________
> dcplusplus-devel mailing list
> dcp...@li...
> https://lists.sourceforge.net/lists/listinfo/dcplusplus-devel
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems? Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> dcplusplus-devel mailing list
> dcp...@li...
> https://lists.sourceforge.net/lists/listinfo/dcplusplus-devel
|
|
From: James R. <si...@wa...> - 2007-11-15 14:38:40
|
From: poy=20 Sent: Thursday, November 15, 2007 2:00 PM To: Patches & development discussion=20 Subject: Re: [dcplusplus-devel] ValidateFileName problem on = Macintosh... i guess validateFileName() tries to keep the path, cleaning only = nested paths and bad chars. it might need to get re-written: no need to = look for "/./", "//", etc when all '/' have been cleared. Indeed; as itinerants has suggested, splitting it up would be a good = idea. It seems to me like there are two things going on here: a.. Filename sanitisation (remove invalid characters).=20 b.. Path sanitisation (remove unnecessary parts of paths). The URL -> filename case (e.g. for hub URLs) should be handled with the = filename sanitisation, provided that all the path separators are = included (I think including "\" and "/" in all cases would be good). = Other places would need to be checked. If no-one's done it before I get back home (Friday night), I'll probably = have a bash at doing a patch for this. --=20 James Ross |
|
From: poy <po...@12...> - 2007-11-15 15:10:44
|
yep. i can imagine 3 functions instead of 1 currently:
- cleanBadChars(string tmp) would clean any occurence of badChars[] =
found in tmp.
- validatePath would be the current validateFileName, making use of =
cleanBadChars in its first part.
- a new validateFileName would handle filename sanitisation, making use =
of cleanBadChars and then cleaning the remaining '\\' if win32 or '/' =
otherwise.
poy
Indeed; as itinerants has suggested, splitting it up would be a good =
idea. It seems to me like there are two things going on here:
a.. Filename sanitisation (remove invalid characters).=20
b.. Path sanitisation (remove unnecessary parts of paths).
The URL -> filename case (e.g. for hub URLs) should be handled with =
the filename sanitisation, provided that all the path separators are =
included (I think including "\" and "/" in all cases would be good). =
Other places would need to be checked.
If no-one's done it before I get back home (Friday night), I'll =
probably have a bash at doing a patch for this.
--=20
James Ross
-------------------------------------------------------------------------=
-----
=
-------------------------------------------------------------------------=
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a =
browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
-------------------------------------------------------------------------=
-----
_______________________________________________
dcplusplus-devel mailing list
dcp...@li...
https://lists.sourceforge.net/lists/listinfo/dcplusplus-devel
|
|
From: Jacek S. <arn...@gm...> - 2007-11-15 18:22:24
|
Well, two separate functions would indeed be reasonable...keep in mind that each OS has its own rules so I'd expect mac to be slightly different as well...windows names are extra ugly (lots of reserved names etc) and the current code doesn't take all cases into consideration (see http://msdn2.microsoft.com/en-us/library/aa365247.aspx, for example CON, NUL and friends)... Maybe the easiest way to handle paths would be to split them into their respective components and then validatefilename for each part, considering also dots and the like...oh, and / is a valid path separator on windows most of the time... oh, and itinerants, find_first_of might interest you (instead of repeating those loops =) /J poy wrote: > yep. i can imagine 3 functions instead of 1 currently: > - cleanBadChars(string tmp) would clean any occurence of badChars[] > found in tmp. > - validatePath would be the current validateFileName, making use of > cleanBadChars in its first part. > - a new validateFileName would handle filename sanitisation, making use > of cleanBadChars and then cleaning the remaining '\\' if win32 or '/' > otherwise. > |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X