dcplusplus-devel — Developer's list

Re: [dcplusplus-devel] comment in the file list?

[Jacek S. <arn...@gm...>]

hm, maybe a tooltip for the tabs or some other place to display user information (nick, hubs,
descriptions etc), both for list browsing and for pm's?

At some point in the future, it would be nice to make a sort of code->name map for the DE, EM etc
fields of inf, and if some field doesn't have a name, display the code. This way it's possible to
add info and old clients will still have fair chance to understand it...

/J

poy wrote:
>> Um, why can't people just use the normal description field for their 
>> client?
> 
> oh yeah right. i knew that was bloat somehow but i needed someone to tell me 
> why. ^^
> 
> poy 
> 
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> dcplusplus-devel mailing list
> dcp...@li...
> https://lists.sourceforge.net/lists/listinfo/dcplusplus-devel
> 

Re: [dcplusplus-devel] Towlower

[Jacek S. <arn...@gm...>]

itinerants wrote:
> I've just spent a (was it happy, or was it unhappy) several hours tracking
> down a long standing problem in my Mac port.
Welcome to the happy world of unicode then...I'm guessing your c library normalizes text (which is
probably not a bug...dc++ just doesn't consider those aspects of unicode).

> To cut a very long story short, my problem was that certain 'non-ascii'
> characters would lowercase to one thing, and then lowercasing that would
> give me something else (the 'ae' dipthong was the problem), so the hashing
> would hash it again on each launch.
> Obviously this is a bug in my standard c libraries (I'm getting tired of
> those), but it did lead me to wondering why HashLoader::startTag is
> lowercasing the files it reads from HashIndex.xml - they were lowercased
> before they were written to it, so surely ...
>                 string fname = Text::toLower(Util::getFileName(file));
>                 string fpath = Text::toLower(Util::getFilePath(file));
> Isn't required?
> 
> Incidentally, perhaps someone could enlighten me as to why file names are
> being lowercased at all?
The ADC spec says filenames are case insensitive, hence the lowercase (otherwise they'd require case
insensitive matching which is just as tricky). I'm guessing the lowercase call on xml load is for
backwards compatibility.

/J

Re: [dcplusplus-devel] ADC typeing notification

[Jacek S. <arn...@gm...>]

> I thougth about it. IMHO its a little stupid. First or all you need to add special parser into the server for the case
> whan this message types are restricted. In "TPN" case you can just drop it after reading the header.
> 
> Also if client-side dosent support this type of messages (MSG with ME flag and special text) - all the window/console
> (for console clients like microdc) will be filled with spam messages, but in TPN case this messages are just ignored.
I generally agree that this should go as a separate message - MSG is for sending text to the user,
no use sending this kind of stuff as text (it would get logged, it couldn't be detected
automagically etc etc)...

Intuitively I'm not convinced about the code set of what the user is doing - I'd say that would need
some review and maybe a reference implementation to see it in action...

Also, this should clearly go as an extension, not part of BASE. It wouldn't even have to be present
in the SUP since it doesn't require anything as far as hub-client comms go...

/J

[dcplusplus-devel] Bind address patch

[Todd P. <tod...@gm...>]

Here's a patch from one of my friends ('Quasi') that works on linuxdcpp
that solves his bind address issues (which may fix the recently reported
bug on the blog).  I've not tested it myself.

-- 
  Todd Pederzani
  tod...@gm...

Re: [dcplusplus-devel] comment in the file list?

[poy <po...@12...>]

> Um, why can't people just use the normal description field for their 
> client?

oh yeah right. i knew that was bloat somehow but i needed someone to tell me 
why. ^^

poy 

Re: [dcplusplus-devel] comment in the file list?

[Fredrik U. <ul...@gm...>]

Um, why can't people just use the normal description field for their client?

On Nov 21, 2007 8:49 AM, poy <po...@12...> wrote:
> this is an idea i've been having for a while; adding a comment in the file
> list where you can write anything about what's in your file list.
> the comment would either pop-up when opening the list, or simply show a
> button which, when clicked, would show the comment.
>
> some examples i've just made up:
> "hey i also have part 2&3 on DVD; tell me if you want them"
> "i share an unstable version of that program, careful with it! ;)"
> "here in my share you'll find many things like xxx in XXX, yyy in YYY, etc;
> have fun"
> "i have a slow bandwith"
> "all my stuff is in French"
>
> there's the same kind of comments in zip files sometimes, and i like them to
> show up before anything else.
>
> about implementing it, i guess that a <Comment> tag in files.xml would be
> enough; you'd fill it from a text area in settings.
> but before thinking about it any further, is this a good idea?
>
> poy
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> dcplusplus-devel mailing list
> dcp...@li...
> https://lists.sourceforge.net/lists/listinfo/dcplusplus-devel
>



-- 
Fredrik Ullner

[dcplusplus-devel] comment in the file list?

[poy <po...@12...>]

this is an idea i've been having for a while; adding a comment in the file 
list where you can write anything about what's in your file list.
the comment would either pop-up when opening the list, or simply show a 
button which, when clicked, would show the comment.

some examples i've just made up:
"hey i also have part 2&3 on DVD; tell me if you want them"
"i share an unstable version of that program, careful with it! ;)"
"here in my share you'll find many things like xxx in XXX, yyy in YYY, etc; 
have fun"
"i have a slow bandwith"
"all my stuff is in French"

there's the same kind of comments in zip files sometimes, and i like them to 
show up before anything else.

about implementing it, i guess that a <Comment> tag in files.xml would be 
enough; you'd fill it from a text area in settings.
but before thinking about it any further, is this a good idea?

poy 

[dcplusplus-devel] patch: always focus the message box in chat frames

[poy <po...@12...>]

at the moment, when a tab is selected, DC++ always gives the focus back to 
the widget of this tab that had the focus before the tab lost focus (hmm, 
hope it's understandable).

however, in some tabs like hubs and private messages, the focus should 
always be given to the message box, as it used to be in the WTL version.
this little patch fixes it by adding a bool alwaysSameFocus in 
MDIChildFrame.

btw Jacek, got my patch about window titles?

poy 

[dcplusplus-devel] Towlower

[itinerants <iti...@ho...>]

I've just spent a (was it happy, or was it unhappy) several hours tracking
down a long standing problem in my Mac port.

To cut a very long story short, my problem was that certain 'non-ascii'
characters would lowercase to one thing, and then lowercasing that would
give me something else (the 'ae' dipthong was the problem), so the hashing
would hash it again on each launch.
Obviously this is a bug in my standard c libraries (I'm getting tired of
those), but it did lead me to wondering why HashLoader::startTag is
lowercasing the files it reads from HashIndex.xml - they were lowercased
before they were written to it, so surely ...
                string fname = Text::toLower(Util::getFileName(file));
                string fpath = Text::toLower(Util::getFilePath(file));
Isn't required?

Incidentally, perhaps someone could enlighten me as to why file names are
being lowercased at all?

I'm off to a funeral tomorrow, back in a couple of weeks.

Re: [dcplusplus-devel] ADC typeing notification

[Jan T. <jan...@gm...>]

> For one, I'm not sure that such capability would even be appreciated
> by users. I mean, do anyone really care if I have minimized the
> window, and should they *really* need that information?

If you use jabber/gtalk/gizmo (if not - install psi or gajim or gtalk and add my google-email to the roster) than you
can see that this information really userful. For example you wrote something, if user in this tab - he/she thinking
about answering. Typeing - he/she typeing. Closed tab/window or moved to the other stuff - you can not wait for the answer.
This notifications really save time whan your every day chattings are rather active.

> Why can't you just send messages via the ME capability in MSG ("* user
> is writing")? I mean, you still need to modify the client to listen
> for input/window manipulation. If you want to display the text in a
> particular way, why not just add a parameter to MSG and use that in
> combination?
I thougth about it. IMHO its a little stupid. First or all you need to add special parser into the server for the case
whan this message types are restricted. In "TPN" case you can just drop it after reading the header.

Also if client-side dosent support this type of messages (MSG with ME flag and special text) - all the window/console
(for console clients like microdc) will be filled with spam messages, but in TPN case this messages are just ignored.


B R,
Jan

Re: [dcplusplus-devel] ADC typeing notification

[Fredrik U. <ul...@gm...>]

For one, I'm not sure that such capability would even be appreciated
by users. I mean, do anyone really care if I have minimized the
window, and should they *really* need that information?

Why can't you just send messages via the ME capability in MSG ("* user
is writing")? I mean, you still need to modify the client to listen
for input/window manipulation. If you want to display the text in a
particular way, why not just add a parameter to MSG and use that in
combination?

-- 
Fredrik Ullner

[dcplusplus-devel] ADC typeing notification

[Jan T. <jan...@gm...>]

Hello.

Im hungry about making ADC good chatting proto, because LAN users wont install jabber or IRC server just for
conversations, but will install DC Hub because of sharing capabilities.
So what about adding "typeing notification"? Like Jabber/ICQ/etc.
"Typeing" and "Stoped typeing" are rather userful in day to day conversations. And userfull (for example) for special
nicklist sorting when you see who is alive right now.

Now about implementation.
I thought about the way how to send it... and my idea is:

1. adding new type of message, for example "TPN" (like an extention, or in BASE...) for sending this notifications.
All of them should pass through the hub, because of DDOS capability.
INF messages are not very good because of their context, and MSG will make parceing more complicated, when typeing
notification are banned, so new type imho is better.

2. adding a switcher into cleint. (OFF/ON)

so. i see it like this:

4.3.16. TPN
TPN code

Contexts: F, T
Typeing notification.

Codes:
00 - Stoped typeing
01 - Typeing...
10 - Closed tab, minimised window, etc...
11 - Now in this tab, reading message
12 - Changed tab or window bacame unfocused, but not closed/minimised

all codes are sent when event occurs.

if user sends TPN to hub there it is not allowed - it got STA 25

Now some notes. TPN should be send to Reply-To user (for chatroom orgainzation and etc) (PM flag in MSG if any).
In that case chatrooms bot can normally broadcast this messages to "joined" users.

Thats all. I suppose.

B R,
	Jan

Re: [dcplusplus-devel] patch: updates VC headers to match changes in GCC headers

[Jacek S. <arn...@gm...>]

>     * Change any remaining std::min/std::max to just min/max for
>       consistency (I think there's only the one).
Well, actually I think the smartwin part mostly uses std:: while the dc++ part doesn't...so actually
the smartwin part should probably keep using std (to avoid importing std:: into the smartwin
namespace)...as to dcpp, at some point maybe it would make sense to use std:: as well (it's kind of
ugly to have all of std in the dcpp namespace as it is now...). win32 can keep using non-std:: since
importing std there doesn't affect other apps (dcpp/ library users)...

>     * Stop min/max being defined by windows.h, which can actually be
>       done by defining NOMINMAX before including it.
That's not enough since someone might have included windows.h before us (again in the library
scenario)...

> 
> -- 
> James Ross

[dcplusplus-devel] AutoSearch reloaded...

[itinerants <iti...@ho...>]

Having added ...
    fire(QueueManagerListener::AutoSearchingFor(), qi->getTarget());
And logged and analysed what's going on with autoSearching, perhaps now is
the time for an improvement?

Firstly, there is the problem of the 30 items - if nothing is found, and the
"queue of 30" isn't full, autosearching simply stops. That's just a bug -
it's happened to me and the only answer is to quit and relaunch the app,
something I'm loathe to do when I've waiting 24 hours to get onto a given
"difficult" download.
Even aside from that, the fact that a new candidate is found *randomly*
means that, theoretically, there may be items that you *never* search for -
they simply don't get randomly picked. Whilst I've never seen that happen
(which might be hard seeing as how I'd have to, by definition, wait
forever), I HAVE seen the same file searched for 3 times before a given file
*did* get searched for.

However, going further, seeing that quite a lot seems to be happening at the
moment, I'd propose one of the following 2 improvements to the algorithm...

1) The pretty easy one...
A) Remove the 30 limit entirely, letting the "recent" list get as large as
it likes.
B) When "findAutoSearch" fails to return a search candidate, empty the
"recents" list. Next time around it'll start with a clean sheet. This easily
fixes both problems listed above. I've implemented this and it works just
dandy.

2) The harder, but "better" one...
Build a list of everything that's eligible.
Order this list, using...
    Priority (user nominated it, let it mean something here as well)
    Number of existing sources (I've waited hours for it to pick something
with 0, yes zero, sources, whilst it gaily autosearched for things I had 60
sources for already)
Crunch through the list.
When the list is empty, go to step 1

What makes this a bit harder is having to deal with...
    New wait list items being added
    Priority changing
    Downloads that are still in the list finishing
Not insurmountable problems, of course, but riskier than solution 1.

Just my 2-peneth

[dcplusplus-devel] catching the enter key

[poy <po...@12...>]

the "pressing enter in search wasn't working" issue was solved by adding the 
following in answer to WM_GETDLGCODE in SearchFrame:
static HRESULT allKeys(WPARAM wParam, LPARAM) {
 if(wParam != VK_TAB)
  return DLGC_WANTMESSAGE;
 return 0;
}

now there are several other parts of DC++ where such a thing would be 
needed, eg in many list views, or the public hubs filter, pressing enter 
isn't working.
so i was wondering wether i just copy-paste that everywhere i need it, or 
should it rather be somewhere in smartwin?
or have the function in a place like WinUtil so that any class can have 
access to it, thanks to tr1::bind. :)

poy 

Re: [dcplusplus-devel] ValidateFileName problem on Macintosh...

[Jacek S. <arn...@gm...>]

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.
>  

Re: [dcplusplus-devel] patch: ListView double buffering (v6 only)

[Jacek S. <arn...@gm...>]

applied...

poy wrote:
> i remember having tried it with the WTL version, and it being useful. i
> applied your patch and yes, it does solve flickering and resizing the
> window goes (almost) fine. :)
yeah, the old dc++ used it for some of the list views afair

Re: [dcplusplus-devel] patch: updates VC headers to match changes in GCC headers

[Jacek S. <arn...@gm...>]

> 
> I still have no idea what you're on about, so I'd really like a better
> explanation. The defines are commented out, what's the problem?
Oops, I misread the patch, sorry. I thought you added the comment while your patch removes it...
=)

/J

Re: [dcplusplus-devel] patch: updates VC headers to match changes in GCC headers

[Jacek S. <arn...@gm...>]

> I still have no idea what you're on about, so I'd really like a better
> explanation. The defines are commented out, what's the problem?
windows.h does #define min(a,b), c++ does it using a template. We don't want to use the windows
version because it's not typesafe. dc++ uses min/max all over the place (for examples Streams.h:86)
so if you don't have #undef min, the windows.h version will preferred over the c++ version since the
preprocessor is run first and typesafety goes away. The best solution I've found so far is to
undefine min/max since I don't want to put parentheses around each min...makes sense?

> As far as compiling goes, openssl is the best open-source project I
> have ever seen (i.e. it actually compiled first time). It just needed
> some tweaks to its default CRT linking options to match those used by
> DC++, or all hell breaks loose when linking with DC++. Smile emoticon
That's because it's one of the few opensource libs that are actively being used with msvc...boost
would be another example, python extensions another (the mess with python is when you want to use
mingw instead because of how they depend on msvcrt)

what I don't like is the advertising clause in their license, it forces you to put a certain string
in a visible place in your app. I tend to put the ads anyway out of courtesy, but I believe it
should be voluntary.

/J

Re: [dcplusplus-devel] patch: updates VC headers to match changes in GCC headers

[Jacek S. <arn...@gm...>]

James Ross wrote:
>> What's the deal with the min/max comment? afair windows.h defines ugly 
>> versions of min/max?
> 
> It was all commented out, and all the places which use std::min or std::max 
> are wrapped in parentheses as the comment notes (except one). I don't think 
> it needs to have the commented-out defines, but the comment could be left 
> instead?
Well, if it works without and uses the c++ version that's fine (and then I want neither comment nor
undefs). But as far as I can see, there are no parentheses in the dc++ code that uses min/max and I
don't want them there either (harder to read), so unless I'm missing something cruical (mind that
most of the time the dc++ code doesnt use the the std:: prefix, so searching for that won't be
enough), this part of the patch won't go in...

> Thanks, most of it was making it link with openssl (and compiling openssl 
> with the right flags). :)
I would get rid of openssl (don't like its license), but I'm low on alternatives. gnutls seemed
trickier to compile because of the additional dependencies, and I'm guessing it won't work very well
with msvc...

/J

Re: [dcplusplus-devel] ValidateFileName problem on Macintosh...

[poy <po...@12...>]

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

Re: [dcplusplus-devel] ValidateFileName problem on Macintosh...

[James R. <si...@wa...>]

  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

Re: [dcplusplus-devel] ValidateFileName problem on Macintosh...

[itinerants <iti...@ho...>]

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

Re: [dcplusplus-devel] ValidateFileName problem on Macintosh...

[poy <po...@12...>]

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

Re: [dcplusplus-devel] ValidateFileName problem on Macintosh...

[James R. <si...@wa...>]

  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