Loading Profile...
unreliable when dumping lots of files (small? big?) via fileintegration
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.
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.
4 people have this problem
I have this problem, too!
Tell me when someone solves it.
The more people who report this problem, the more it gets noticed.
The more people who report this problem, the more it gets noticed.
-
Inappropriate?If you press F7 the Uploads window will appear. Are there any files that need to be uploaded still? Do they correlate with your list of incomplete or missing files? -
Inappropriate?no there are no uploads left there.. i am not a newbie ;)
there is plenty of maintenance going on but nothing unusual....
it also doesnt matter if i restart the wuala client after the actual filecopy/dumping into the wuala store or not. also it doesnt matter how long i leave the wuala client running. these files "never" get completed or added. never in reasonable timeframe ofcourse. who knows, maybe after a bazillion years a miracle would happen and those random files would magically reappear.
some files never get actually uploaded properly into the wuala store (filesystem integration) in the first place.
no kidding, these files are simply staying there with zero bytes in size or dont even appear. fullstop.
i guess the problem of creating/adding/copying a lot of files could be maybe also a problem in the filesystem/samba-libaries part of wuala.
dunno. the devs need to take a look at this. -
Inappropriate?sorry, nick - I just had to ask the obvious to rule it out. :)
Yeah, I've had the exact issue as you in the past. It is a hassle and waste of bandwidth to delete incomplete or missing files and then upload them again. Even when this is done, it is not clear if the upload will succeed for those files. -
Inappropriate?I have this same exact issue when I try to backup thousands of pictures at the same time. Some of the pictures never make it into the Wuala cache, or only appear to have zero bytes.
I started using syncback to do the synchronization between my backup hard drive and the W: drive.
syncback allows you to turn off intermediate/temporary files when copying to the Wuala drive. Microsoft's sync powertoy created lots of .jpg.tmp files that got uploaded instead of the .jpg to Wuala.
syncback also has a NSF copying mode that tries to preserve file attributes.
Eventually, after running sync over the folder a few times and letting Wuala finish uploading, all my files get uploaded.
But I do consider it a major bug.
I believe its caused by Wuala maxing out a single core CPU and not being able to keep up with the OS dumping the files into Wuala.
I wish Wuala was multithreaded so it could encrypt my files 4x faster. -
Inappropriate?yeah exactly. i was having also other issues where i recognized that wuala only maxes out one core (single threaded only)....
when rightclicking on folders with a lot of elements folders and subelements it takes literally ages til it brings up the context menu. also the whole wuala gui turns empty/white and doesnt get any updates/drawing/refresh. -
Inappropriate?Robustness of inserting files (especially into groups) will improve with the next update. I've just inserted 2500 files into Wuala using total commander and it seems to have worked correctly. There are lots of pending transactions though and it takes a while until they are committed.
-
Inappropriate?what about those temporary hashcode-filename.ext files in the %temp% folder?
i still have those files sitting around in my tempfolder...
did you ever experience that too? can the tempfolder %temp%\wuala\ safely be deleted?
what i am wondering about the tempfolder usage of wuala as of lately is that wuala never used to mess around in %temp%\wuala (it didnt even exist some builds ago) but it always used its %programfiles%\caleido\wuala\ folder and in there are also some temp, upload and download folders containing all kinds of crypto chunks and all this...
why is wuala currently working in the %temp%\wuala\ folder and also in its programfiles folder on windows (winxp service pack 3).
this is really weird.
as long as i am using wuala to upload/download stuff its still using the %temp%\wuala\ folder besides those trash-files that got there back then with this buggy behaviour.
so somehow i fear that my wuala installation will be hosed if i start messing with that %temp%\wuala\ folder as long as its not really clear what got this stuff started and if my wuala is (at present? at all?) in a consistent stage so that i could really safely delete that %temp%\wuala\ stuff....
:(
any enlightenment?
cheers.
I’m confused
-
Inappropriate?Some versions ago, we decided to use the system's temp folder for temporary stuff. You can safely delete everything in there as long as Wuala isn't "analyzing file x" in the status bar. We recommend to close Wuala before doing so. In theory, the temporary files should be deleted automatically (we call file.deleteOnExit when we create them, so Java should automatically delete them when Wuala shuts down, but that doesn't seem to work reliably). Do you think it is good to use the systems temp folder for temporary things or should we rather put all of Wuala's data at the same place?
-
Inappropriate?ok so now we know that on windows the %temp%\wuala\ folder is constantly in use, thats ok. all i was asking for was information and documentation if this was proper behaviour of wuala.
but then again, there are these old folder structures in %programfiles%\caleido\wuala\data\temp\
what about that? is that still being used and needed? the uploading, downloading and parts/chunks were being handled there in the past. why is there a million files in there especially in the upload and download directories there.
and especially the upload dir in %temp%\wuala\upload\ is also filled with little chunk-files
this doesnt make sense. i really dont like chaos on my computer and if wuala has actually changed its behaviour and is using the %temp% rather then %programfiles%, why not cleaning up one of the two and migrating the appropriate files over to the real directory.
i have multi hundred megabytes of chunk-files in the old %programfiles%\caleido\wuala\data\temp\upload\ and also .\download\ in there.
:(
p.s. the filedates were from feb2008 and apr2008 in the programfiles temp-are in up and download, so i deleted all that crap in there and removed the directories right back to the temp level.
guess it was trash wuala never cared to remove. now thats real windows monopolist-like behaviour. filling storage areas with useless stuff or never actually caring to properly clean up your space you have once been using.
welcome to the windows world. wuala seems to have adopted all the best habits from other windows programs, installers and even microsoft themselves.
congratulations. way to go. thanks.
I’m frustrated
EMPLOYEE
