Loading Profile...
protecting elements (read only) from changes in filesystem integration
it would be nice if there was a feature to be able to protect elements in the wuala store so that applications which work with the filesystem integration (driveletters, pathnames etc...) couldnt accidentally change modify or delete your stuff in there.
it would then for example only be possible to alter the contents of a folder or to delete stuff from within the wuala gui, but not on via driveletters/pathnames.
in a similar way there are usb-storage sticks, flash-chips or harddrives that have a physical little switch where you can set a read-only mode and thus protect your data for example from virusses, install programms accidental deletion and so on.
thanks
it would then for example only be possible to alter the contents of a folder or to delete stuff from within the wuala gui, but not on via driveletters/pathnames.
in a similar way there are usb-storage sticks, flash-chips or harddrives that have a physical little switch where you can set a read-only mode and thus protect your data for example from virusses, install programms accidental deletion and so on.
thanks
5 people like this idea
I like this idea!
Tell me when this idea gets some attention.
The more people who like this idea, the more it gets noticed.
The more people who like this idea, the more it gets noticed.
-
Inappropriate?I like this. The other day I was messing around with a sync utility and I accidently deleted some files.
I’m excited
-
Inappropriate?its also useful for example when you store archived data (for example cd/dvd contents of archive data, which needs data-integrity/no-change-protection, and so on...)
storing stuff inside wuala doesnt guarantee to stay unchanged and unaltered as of yet.
i could definitely need an archive/protection/read-only setting/option for certain files/folders/elements in the wuala store.
thanks. -
Inappropriate?A protection flag is no our (growing..) wish list. Not only for the FSI, also for private content (think about content you want to share with a group but users should not be able to copy it).
-
Inappropriate?huh? dont understand a word...
"... is no our wish list"... whats that supposed to mean? not on our wishlist? now on our wishlist? ;)
second: want to share with group but users not be able to copy it? how do you share stuff if users cant copy it?
every access, viewing, listening, whatevering IS copying it at least into the memory of the target computer/wuala/software/operatingsystem/network/wire....
this sentence makes as much sence as the stuff that the copyright-lobbies are constantly blabbing about.
you cant share information if you dont want people to allow to consume/copy/read/listen/store it in some way.
either you keep stuff or you share. there is no inbetween.
same stuff applies to crazy concept of so called intellectual property.
its your property as long as you dont offer it to the world. as soon as its out there it can and will be copied if interesting enough.
the whole world is about sharing. -
Inappropriate?sorry for the typo. It is now on our wish list..
second, yes users can download stuff on their harddrive and upload it again. It was more about to remove the copy file action for protected stuff. But maybe this is more confusing than something other (as users could think it is protected now..). Maybe a bad idea :)
I’m unsure
-
Inappropriate?Well, maybe a switch that duplicate versions of that file may NEVER be public? I hope you already use something similar for your abuse-system...
Disabling "Copy File" for others should also be part of that switch, you don't have to make it too easy for "them"! ;-) -
Inappropriate?well that could be somewhat problematic on false positives although not very likely.
cause: hash collisions. as hashes no matter how good they are, are ofcourse not unique.
maybe hashes for files/chunks/parts with filesizes and so on. but still it can break your system at any later point of time and you have to manually track down what went wrong.... dont know how to solve this.
except if everybody went open minded and creative commons and the like :)
cheers
I’m confident
1 Comment
Add a comment
This is one of the best points
-
AFAIK Wuala uses SHA256... you'll have to store quite some Exabytes to produce a collision there. I don't really think hash collisions should be a real issue here as the probability is so small, that it really doesn't matter in any case. -
Inappropriate?any news on this matter? when is read-only (protection) coming to wuala sharedfolders/filesystemintegration.
could really use this setting. protecting backups is a prime and essential matter and a very important feature.
thanks.
EMPLOYEE
