Loading Profile...
Recent activity
Subscribe to this feed
nickname replied on June 11, 2008 07:58 to the problem "unreliable when dumping lots of files (small? big?) via fileintegration" in Wuala:
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.-
Luzius replied on June 11, 2008 06:04 to the problem "unreliable when dumping lots of files (small? big?) via fileintegration" in Wuala:
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? -
nickname replied on June 09, 2008 21:00 to the problem "unreliable when dumping lots of files (small? big?) via fileintegration" in Wuala:
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. -
Luzius replied on June 09, 2008 08:06 to the problem "unreliable when dumping lots of files (small? big?) via fileintegration" in Wuala:
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. -
nickname replied on May 23, 2008 10:08 to the problem "unreliable when dumping lots of files (small? big?) via fileintegration" in Wuala:
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. -
hechacker1 started following the problem "unreliable when dumping lots of files (small? big?) via fileintegration" in Wuala.
-
hechacker1 replied on May 23, 2008 08:37 to the problem "unreliable when dumping lots of files (small? big?) via fileintegration" in Wuala:
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. -
Luzius replied on May 16, 2008 06:49 to the problem "424 Crash" in Wuala:
Was fixed on Tuesday with update 426. -
-
hechacker1 replied on May 14, 2008 15:12 to the problem "424 Crash" in Wuala:
for whatever reason this seems to have resolved itself.
EDIT: nevermind, i see Wuala was updated to 426 -
hechacker1 replied on May 13, 2008 19:19 to the problem "424 Crash" in Wuala:
AFAIK, java is up to date: OS: Windows XP 1.6.0_05 Sun Microsystems Inc.
When I click "Update Java" in the control panel, it says that I already have the latest version. -
Jade replied on May 13, 2008 08:32 to the problem "424 Crash" in Wuala:
Try to updating Java. First I had the same problem but ofter the updat it works! -
-
hechacker1 reported a problem in Wuala on May 13, 2008 03:19:
424 CrashIt happens each time i start Wuala with the 424 build.
Build: WualaPC 424
App: Domain Application, user: Protoss
(Data Application, prim id: 190.16.0.3, ip: /24.30.152.85:9008 (global)
(Common Application Alpha WualaPC 424))
Date: May 12, 2008
OS: Windows XP 1.6.0_05 Sun Microsystems Inc.
Memory: 331 MB max 14 MB free 86 MB total
Local Host: q6600/192.168.1.115
Running for: 2min 40s
Exception: java.lang.Exception: com.wuala.common.exception.ApplicationRuntimeException
at com.wuala.obfuscated.nk.a(Z:169)
at com.wuala.common.exception.ApplicationRuntimeException.createReport(Z:62)
at com.wuala.obfuscated.RS.<init>(Z:30)
at com.wuala.obfuscated.fa.a(Z:286)
at com.wuala.obfuscated.fa.a(Z:160)
at com.wuala.obfuscated.fa.a(Z:117)
at com.wuala.platform.Wuala.launch(Z:94)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at com.wuala.starter.ReflectiveWrapper.invoke(ReflectiveWrapper.java:38)
at com.wuala.starter.ApplicationWrapper.launch(ApplicationWrapper.java:19)
at com.wuala.starter.WualaStarter.startWuala(WualaStarter.java:117)
at com.wuala.starter.WinWualaStarter.startWuala(WinWualaStarter.java:88)
at com.wuala.starter.WualaStarter.run(WualaStarter.java:35)
at com.wuala.starter.WinWualaStarter.run(WinWualaStarter.java:76)
Caused by: com.wuala.common.exception.ApplicationRuntimeException
at com.wuala.obfuscated.aea.uncaughtException(Z:21)
at java.lang.ThreadGroup.uncaughtException(Unknown Source)
at java.lang.ThreadGroup.uncaughtException(Unknown Source)
at java.lang.ThreadGroup.uncaughtException(Unknown Source)
at java.lang.Thread.dispatchUncaughtException(Unknown Source)
Caused by: java.lang.NullPointerException
at com.wuala.common.rmi.exception.RemoteException.isTreatAsConnectionProblem(Z:105)
at com.wuala.obfuscated.q.a(Z:60)
at com.wuala.obfuscated.Tz.HK(Z:113)
at com.wuala.obfuscated.CM.xG(Z:144)
at com.wuala.obfuscated.CM.run(Z:126)
--------------------------------------------
com.wuala.common.exception.ApplicationRuntimeException
at com.wuala.obfuscated.aea.uncaughtException(Z:21)
at java.lang.ThreadGroup.uncaughtException(Unknown Source)
at java.lang.ThreadGroup.uncaughtException(Unknown Source)
at java.lang.ThreadGroup.uncaughtException(Unknown Source)
at java.lang.Thread.dispatchUncaughtException(Unknown Source)
Caused by: java.lang.NullPointerException
at com.wuala.common.rmi.exception.RemoteException.isTreatAsConnectionProblem(Z:105)
at com.wuala.obfuscated.q.a(Z:60)
at com.wuala.obfuscated.Tz.HK(Z:113)
at com.wuala.obfuscated.CM.xG(Z:144)
at com.wuala.obfuscated.CM.run(Z:126)
--------------------------------------------
java.lang.NullPointerException
at com.wuala.common.rmi.exception.RemoteException.isTreatAsConnectionProblem(Z:105)
at com.wuala.obfuscated.q.a(Z:60)
at com.wuala.obfuscated.Tz.HK(Z:113)
at com.wuala.obfuscated.CM.xG(Z:144)
at com.wuala.obfuscated.CM.run(Z:126)
Thread: Main Thread</init>
