hi there,

a main problem with the wuala project as whole is, that there is far too little information on technical details, far too little documentation and real information given by the developers.

people often wonder why the wuala software behaves this or the other way, search for solutions that are sometimes no real problems if the behaviour would be properly documented.

i started up some older build (winxp) wuala client after a while of downtime and it upgraded itself.
after logging in to the wuala network (username) the wuala client now works heavily on the wuala database files in probably reoganisation tasks (fragmentsxx.db and COMP-fragmentsxx.db files being messed with the whole time)

anyways so it literally took ages for this client to finish, and the connection status icon was yellow all the time. only after a long while, and when finally the insane diskactivity has finished, the connection status icon went green again.

ctrl+alt+d _shownetworkstats displayed that it wasnt connected to any supernodes during this period, hence the yellow icon i presume.

what makes me wonder if this is a neccessary behviour, that the client cant properly connect to the network until its finished with its database overhaul. maybe some multithreading designs could help, or maybe its just really the need to bring the database into a consistant and up-to-date state again before being able to add and fetch chunks of data again to and from it.

it would really be great if the wuala team could document its piece of software much more in detail.

hi there,

apparently there is a new feature during startup, named database cleanup. defragmentation of the datastorage or such.

interestingly i have never seen this window up til now, but it comes up during every restart of the wuala client (win32, b446).

is this the normal behaviour?

lately i have experimented with wuala and fileintegration on win32 (xp) and latest wuala builds (426). i was copying whole cd contents (different files, loads of folder structures) into a semi-private (group/friendshared(only 1 friend as an example/test)) to the wuala network drive (w: for example).

the copying went normally, but only some days after (this happened first some days ago, but i verified it today with other content (CDs)) i realized that the uploaded wuala content of the folder i copied the files into wasnt exactly the same as my original sources. some bytes/megabytes were missing, and i tracked down some of the files/folders that were created but only with filesize=0 (zero), or were missing completely.

i was copying the stuff with the help of total commander, so not the basic builtin explorer.exe functions, nor commandline copy stuff...

i might try some more of this stuff at a later time.

the missing/incomplete files dont seem to follow any certain rules or patterns, there are simply some folders that are completely identical/complete and some files are missing or come with zero size.

totalcommander never complained that it couldnt write to w: or anything else like that.

i was manually looking for the differences, found the missing/incomplete files and was overwriting the files on the wuala store again.

after these second tries and overwriting procedure the wuala store was eventually finally complete and identical to my source material.

i guess that some of the queues in the wuala client, the pending transactions, the chunk-creation and distribution or related functions and parts of the wuala client program are still lacking robustness.

please take a look at this and do your own tests with lots of files/folders and different objectsizes.
thanks.

hi there,

some while back i inserted an openoffice file into the wuala datastore.

somewhen later i edited the file with openoffice. then saved it inside openoffice. the file in the wuala data store has the new content and changes. but the timestamp in the wuala gui (win32) still shows the original filedates and timestamps for both inserted and last modified.

bug? fix? thanks.

hi there,

during my recent upload tests via filesystem integration method (see other thread http://getsatisfaction.com/wuala/topi... ) i somewhen realized that there are hugeloads of files in %temp%\wuala\ which wasnt the case in former builds of wuala.

there are also two directories in there (download and upload)

in the actual %temp%\wuala\ folder there seem to be a very big number of "original" files which i was trying to upload into the wuala store it seems.

the filenames have been changed somewhat to

hexnumber-originalfilename.extension

example:
f3edab22-mypicture.jpg
(hexnumber is maybe some hash/crc/crc32 or something)
the files are unencrypted, so i can actually use them with the appropriate application as they all hold the actual data (pictures, and so on....)

is this some bug? anyway related to my other thread? i suppose this is a huge security risk as even with reboots, wuala clients shutdown/restart these folders dont seem to go away or dont get empied nor cleaned up and the files can be seen by "anybody" who has access to the physical machine.

this is really weird. anyone else having this behaviour? win32/winxp that is. wuala426

hah, crazy survey if you cant actually enter the information that you need.

select some country you live in, and you cant continue the survey from page one as apparently some countries are outlawed to take part in the survey.....

i guess thats some antiterrorstrategy or united states export restrictions and censorship and other megalomaniac regulations.

too bad for the wuala users who live in the wrong country.

doubleplusungood

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.