Recently active topics in Wuala tagged with debugging

i have been wondering (on luzius changelog files (txt-files)) for some time whats happening with those padded/trailing zero/null at the end of textfiles.

whenever i view for example any textfile in
http://wua.la/Luzius/Documents/Wuala/... and i doubleclick them in the win32 wuala client on win32 (windows xp) my notepad++ (sourceforge project) starts up and displays the file.

but the last several characters of that file are ascii-zero/null... i have also created a very simple test-textfile and tried it myself. the zeros get somehow generated when using doubleclick....

but when i drag the file from wuala to my desktop again and md5sum/bytecompare that dragged text-file with the original textfile (which ofcourse didnt have any trailing/padding zeros) then everything is fine, so no zeros/trails there, the two files are the same size, same content same everything.

what is wrong here? is the doubleclick unrealible? is doubleclicking doing something else on textfiles than a normal download/dragdrop?

thanks and cheers.

hi,

i just discovered that probably the latest build (win32 374), introduces an error for me.

browsing in wuala (no matter what filetypes, images, documents, music) simply displays one page, no more next page and 1/9 ... up to 9/9 pages any more...

i also didnt find any options in the menus to change this behaviour...

what the heck is going on? is this a clientside or maybe even a server/script side issue?

thanks and cheers.

hi there,

lately i get a lot of these errors in the about dialobox (win32, latest builds) on networks with upnp routers when wuala client wants to check if theres a newer build out there...

if i close logout/restart wuala it downloads the latest build anyways even if the check in the about box failed.

would be great if the checking for a new build would be more reliable (maybe other protocol, triggering it directly with a button or a url and so on....)

maybe it has also to do with congested networks (even the local lan or the gateway to the inet), or nat-overloads at the gateway or such thing.

somehow i suspect that the versioncheck is also performed by means of udp rather than a tcp check of a browsing of some url/xml/file because the failed message turns up so very quickly/instantly on the client... there seems to be no timeout or something.

thanks.