out of memory if share contains broken directory names

Well... This looks oddly familiar.

https://developer.berlios.de/patch/index.php?func=detailpatch&patch_id=2353&group_id=2230

And probably has the same problem still. The question is if it's better to crash the client or share something that wasn't intended? Or even better, fix the problem so that neither occurs.

--RZ

See also bug #287982

Ok, we can show message box (with directory name contains bad file/folders) end exit.
Or show dialog with Abort, Retry and Ignore buttons ;)
Or just crash with message to stderr (user will see it in .xsession-errors).

I think those suggestions are lousy ways to deal with these kinds of errors. Optimally the files would be shared w/o trouble, if that's not feasible, just ignore them.

I think optimal solution it is just dump warning to stderr (~/.xsession-errors) and continue.

If we'll go with the dump error & continue, it should atleast be dumped to LogManager and shown in the main statusbar. That way it's remotely possible that user who doesn't run from the console will ever see it.

--RZ

Not sure the Win32 implementation of FileFindIter can ever return an empty string but if it does, it does not crash DC++, the result is a simple error message in the log : Error hashing <dirve:\folder\>: cannot the file specified.
However this message is misleading so if the attached patch satisfy you, it would fix both problem in both platforms.

can't hurt to check, please add.

Except that the same check led to a situation where something unintentional was shared. This was with an old version of LinuxDC++ (0.691 I believe) and required some character encoding changes between 2 executions.

I didn't manage to reproduce the effect with 0.75 core though, but don't know if it is because I don't remember the steps correctly or because other changes in the hashmanager code.

But yes, it can hurt to check (of course the other option was a crash in that situation, you decide which is more painful).

--RZ

Again, crash can only happen in the *nix part of the code, under Windows this causes a minor problem only. Because of this I think its better that you (I mean linuxdc++ devs, or the one who set this bug affects DC++) decide what to do / fix the unix part / remove DC++ from affected list...

Just to be clear, removing DC++ from the affected list is not a valid option. Since the DC++ project includes both the win32 GUI and the dcpp core, any defect that modifies the core regardless of whether it's *nix or windows specific should be marked as affecting DC++. If you're not okay with this, then you might think about splitting DC++ and libdcpp into separate launchpad projects.

As for the patch, since Razzloss is unable to reproduce his issue with sharing directories unintentionally on the current core, I'm okay with committing the patch as is. If someone later reproduces the issue then that will be addressed as a separate defect.

Fixed in DC++ 0.780.