Loading Profile...
huge security risk: loads of files in %temp%\wuala\ lately - (original unencrypted files in there)
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
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
2 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?hmm. its empty on my system (mac) -
Inappropriate?did you try dumping a whole load of files (small, big, whatever) into your wuala filesystem integration (in whatever way that works on a mac of if it even exists)
i believe that it has to do with many files being copied to the wuala filesystem integration and then wuala client maybe not handling all the requests and queues properly, that it forgets about files, or simply forgets to delete these tempfiles or something like that.
although i never have previously encountered any unencrypted files with my content in any tempfolders or even just the hint that wuala would work in such a way.
wuala was trying to access various temp stuff and little files in the temp directories but never created upload, download and all this other stuff in there.
very weird.
any officials care to comment on this, whats going on here, what went wrong, if i can simply delete this temp stuff and so on?
or how can i trigger some cleanup function from within the wuala client, or retrigger the uploads, chunkmanagement.....
thanks.
-
Inappropriate?yep. one time I ́ve upped 2500 images at once. But never in the way of file-system-integration (also it works with a nfs). You ́re idea seemed to be logical.
-
Inappropriate?I never found anything in the "Uploads" folder (well, I didn't upload via FSI...) but streams seem to be cached in the "Downloads" folder. I found several ~100 MB pieces there once...
