Alo Sarv
lead developer

Donate via

Latest Builds

version 0.3
tar.gz tar.bz2
Boost 1.33.1 Headers
MLDonkey Downloads Import Module Development
Payment completed
Development in progress.
Developer's Diary

Monday, February 07, 2005

Lots of fixes & improvements

Been a pretty nice and progressive development day, and since it's 5am and I'm rather wired, I'll just stick to dumping a compact summary of today's CVS updates here and get to sleep. So here goes:
Only current problem I'm aware of right now would be fixed if I had a clue where the problem lies. Thing is, it seems we'r losing ~30kb data somewhere between downloading and the target file. When PartData thinks it's complete, and performs full rehash, the rehash fails, and further investigation showed that the resulting file from the download was ~30kb smaller than was expected. The wierdest thing is that the regress-test still runs flawlessly, so I'v got no clue whatsoever right now where the problem is. Hope tomorrow brings better luck in searching this [hopefully_last] bug.

Madcat, ZzZz

"Trim new download filenames to avoid spaces at begin/end of filenames."

IMHO not a good idea. Changes on the filenames should be completely in the hands of the user, including any misleading whitespaces. Do it as option?

Maybe i am just missing the point, so could you explain it?
In general, it's useful to have automatic filename cleaners in place (like in eMule), however, you do have a point - such automatition can only be allowed if it doesn't interfere with user. Thus, implementing it in FilesList (inside core) was a violation of that. I'm currently looking into few possible solutions to have it customizable, extendable further via plugins, as well as overridable, and optional.

Most *nix filesystems allow for whitespaces at the beginning/end of filenames. They also allow for a lot more characters in the filenames, and I'm not talking about lenghth here. ? * " > < | are perfectly valid characters on a ReiserFS syustem, for example.

Beginning or trailing whitespaces can be annoying, but they can also serve a speciffic purpose, so just eliminating them without asking is not a good solution in my oppinion.
If you do use such characters in a shared file, other users may have a problem when they attmept to download it to the default filename. A similar problem exists with p2p apps support of >4GB files, while people with NTFS and linux filesystems can download and share them, windows 98/FAT32 cannot.
Post a Comment

<< Home

This page is powered by Blogger. Isn't yours?