Home > Blog > Programming > GSoC: Managing shared files in ownCloud

GSoC: Managing shared files in ownCloud

July 6th, 2011

In the last few days there has been many changes to sharing in ownCloud and more things are formulating in my head for the future. The bulk of the changes happened to the library that interacts with the database of shared items to allow for shared files to be renamed, moved around, and assigned permissions. It’s still a little messy and I hope to clean up the code in the next couple of days.

It’s a fairly simple idea for renaming and moving shared files. The library updates the target location for the shared file so you see it as a different name or in new location with no affect to the original file that is shared. It gets a little more complicated with files inside of shared folders. As I mentioned in my last blog post, if you share a folder the database only knows about the folder and not the files inside of it. On a side note, I have considered having an entry for every file inside a shared folder, but I’m concerned this will take up too much space in the database for large folders. If you rename or move a file within a shared folder, a new entry needs to be made in the database to keep track of that change. Luckily there are SQL functions such as LIKE and REPLACE as well as the use of wildcards, which make it easy to update the entries for a folder and any entries that may also be part of that folder.

Unlike Dropbox, sharing in ownCloud has been written with permissions in mind. You can assign a user permissions for a file you share. So, if you don’t want Bob messing up your text file you just shared with him even if it’s just an accident, you can assign him only read permission. Of course Bob could copy your shared file to a different location and then modify it, but none of those changes will ever happen to your original file. All shared files are readable by the users you shared them with, it wouldn’t make sense to have it any other way. It is up to you though if you want the user to have write permissions. Right now it’s just read and write permissions, I don’t see any need for a permission to execute.

I have thought about other sorts of permissions, such as preventing users from sharing the files you shared with them with others. Even if this was to be implemented I’m not sure how much good it will do, because it would only act as a small obstacle to someone who wants to share your files with others. I can’t think of a solution to prevent it completely besides ensuring that users understand what happens when they share their files.

You may be wondering what this means for deleting files. Well, in a sense you can delete files shared with you no matter if you have only read permission or both read and write. Don’t worry though, this doesn’t mean that your original files will be deleted by careless users. When a user deletes a file shared with them it deletes the entry from the database, it’s as if the file was never shared with them. So in the case of accidentical deletion it only affects the other user and not you. I hear files being deleted from their shared folders is a nuisance for users of Dropbox, we want ownCloud users to stay happy.

Now on my Todo list is adding support for user groups and looking into the filesystem hooks available so I can keep track of moving source files. These should hopefully be implemented by next week and then I should be able to start working on the user interface. This means that ownCloud users will soon be able to start testing my work with file sharing! If you have any feedback on how permissions or sharing works currently, please leave a comment or drop by ownCloud’s IRC channel.

Categories: Programming Tags: , ,
  1. damian
    July 8th, 2011 at 14:59 | #1

    Very nice work, good sharing is necessary, about the no-copy protection, there’s always a way of getting the data, I agree it’s very difficult if not impossible to prevent a user you share a file with from copying, The only solution I can think off is to offer them only through a web interface which prevents download and doesn’t cache anything, but the malicious user can always use prnt scr. or record the device or a thousand more methods, maybe an useful feature would be sharing parts of a odf document, if an odf web engine is implemented, you could put a button that said “share pages 2 to 4″, and a new document is created with only that pages and shared through opencloud.

  2. July 8th, 2011 at 15:33 | #2

    @damian I’m not sure how other apps in ownCloud will use sharing, it really is up to the developers that write them. I will keep that in mind though for the future. My goal is to make sure that users can share what they want easily and control everything that is going on, such as only sharing part of a text document. I’ll be focusing on the users and how they expect sharing to work when I design the user interface.

  3. Lukas
    July 9th, 2011 at 09:27 | #3

    >> I have considered having an entry for every file inside a shared folder, but I’m concerned this will take up too much space in the database for large folders.

    For the last few years data-storage is considered very cheep – like 0.2$/gb. Even if indexing overhead would be 5-10%, it would cost less than 1$ to have 50 -100 GB. For pictures or other larger files overhead would probably be what 0.01-0.1% per file?

    On the other hand hdd scan is slow and expensive. For any installation with more than a few users CPU gonna cost more than extra HDD space. Not to mention new trend, where shared hosting is limiting 1 worker per domain to encourage VDS adaptation, execution time is very important.

    >> Luckily there are SQL functions such as LIKE and REPLACE as well as the use of wildcards, which make it easy to update the entries for a folder and any entries that may also be part of that folder.

    All these operations are super slow too, as wild cards prevent usage of any indexes.
    Replace might also be a big performance eater. Unless you have ROW_FORMAT fixed – it means reserving maximum ever possible to user space per single records – replace is going to fragment the table. Optimizing a real running server means downtime.

    So large (fink any social network) companies NEVER deletes/edits existing files. Just flags them as so and inserts new entry. Its just cheaper. For small setups optimizing would be less costly, but overheads of having some extra space wasted is just too small to even bother about.

    >> All shared files are readable by the users you shared them with, it wouldn’t make sense to have it any other way. It is up to you though if you want the user to have write permissions. Right now it’s just read and write permissions, I don’t see any need for a permission to execute.

    if user wants to share ~/Documents folder with 569 files within, excerpt ~/Documents/TopSecret, no-read permission would make sense. AS otherwise he should manually share 568 files, and that would be pain in the…

    >> I have thought about other sorts of permissions, such as preventing users from sharing the files you shared with them with others. Even if this was to be implemented I’m not sure how much good it will do, because it would only act as a small obstacle to someone who wants to share your files with others.

    >> You may be wondering what this means for deleting files. Well, in a sense you can delete files shared with you no matter if you have only read permission or both read and write. Don’t worry though, this doesn’t mean that your original files will be deleted by careless users. When a user deletes a file shared with them it deletes the entry from the database, it’s as if the file was never shared with them.

    What if OwnCould is used for teamwork? would it mean that each user should do clean-up individually, instead of delegating one member for the job?

    I would think more about having some human readable set of rules:
    * Protected files – files that can be accessed by owner only.

    * Private files – files to be accessed by owner + using private links (good for IM sharing)

    * Shared files – other OwnCould users can read/edit/rename/delete, but any changes are made on copies, so it doesn’t affect owners version (could owner see versions by other users). Like a repo on git hub.

    * Sync’ed files – each user has equal rights for the file. So changes by one users is immediately visible of the rest. For deleting would be good to have “Unsubscribe/delete only for me” vs “Delete for everyone” dialog. Similar as in google docs.

    Same file could be shared and sync’ed with different people at the same time.

    For deleting files. Hmm, would it be hard to have a virtual recycle bin. All deleted deleted files would be permanently removed after 15/30 days, or on filling the quota. Deleting large files might have “permanent delete” option recommended.


    Would OwnCloud going to have some version control available?

    Since in most cases each version would mean a full copy of the file, it might be interesting to have either per folder “Versioned” flag, either “Archived” – all history is removed form archived files, as well as archived files is not included in to the search/sync with PCS by default, or even compressed for smaller footprint on the disk.

  4. July 9th, 2011 at 12:14 | #4

    @Lukas I never expected to get such a long comment response to this post. I think you’ve made some valid points and proposed some new use cases for sharing that I haven’t considered. I’ll be doing some more research and I will talk with my mentor about this in order to make some decisions.

    Since I believe it will be worthwhile for others to hear about this I’ll write a new post in response to your comment in the near future.

  5. May 28th, 2012 at 15:34 | #5

    Dear, in version 4, I can not synchronize the folder “Shared”, which is created by sharing in a group, I mean download and sync to sync with the client, is there any solution?, Greetings.!

Comments are closed.