New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

uploaded files not seen by shared users #54

Open
matrog opened this Issue Aug 25, 2014 · 14 comments

Comments

5 participants
@matrog

matrog commented Aug 25, 2014

All the file uploaded to a shared folder cannot be seen by any share user, on the mobile app they see a NO_KEY file

@megous megous added the enhancement label Oct 23, 2014

@megous

This comment has been minimized.

Owner

megous commented Oct 23, 2014

Megatools don't support creating or writing to shared folders.

@megous megous modified the milestone: megatools 2.0 Jan 1, 2015

@connesc

This comment has been minimized.

connesc commented Jan 5, 2015

This feature would be very useful.
I use megatools for uploading large files in a shared folder, but I always need to generate a new link in order to make the last files accessible by shared users.

@megous

This comment has been minimized.

Owner

megous commented Jan 6, 2015

This will work in 2.0, because that version will support sharing.

The issue is that megatools needs to send file key to everyone with whom the file is being shared. This requires getting their RSA public keys and calling a special api, that will send them encrypted file key, so that they can decrypt it with their private RSA key and access the newly uploaded file.

@connesc

This comment has been minimized.

connesc commented Jan 7, 2015

OK, thanks a lot for the explanation. Does it works the same way for a publicly shared folder (where the private key is embedded in the URL) ?

Also, is there already any expected release date for 2.0 ?

@megous

This comment has been minimized.

Owner

megous commented Jan 7, 2015

Yes, except that the RSA key is not used to communicate to the recipients what key was used to encrypt the individual file keys (share key). The share key is used directly (it's passed in the folder url).

@megous

This comment has been minimized.

Owner

megous commented Jan 7, 2015

No ETA, though you can watch progress in #84

@connesc

This comment has been minimized.

connesc commented Jan 7, 2015

Ok, thanks for everything. I'll follow this closely 😃. Good luck!

@megous

This comment has been minimized.

Owner

megous commented Jan 7, 2015

:)

@chinhodado

This comment has been minimized.

chinhodado commented Feb 12, 2015

Can you explain a bit more the case of publicly shared folder? In 2.0, would it be possible to just generate the shared link of a folder once and keep using it as new files are added in that folder, or would a new link still have to be generated every time?

Also, is there a workaround for this at the moment (i.e. get a link to a shared folder that will always display all the files in that folder, not just the files that were there when the link was created)?

@megous

This comment has been minimized.

Owner

megous commented Feb 12, 2015

Yes. When putting files or folders into a subtree of a folder, megatools will have to check and create a list of all shares set on all parent folders of a path where files or folders are put.

When the uploaded file is added to the filesystem via {a: 'p'} request, megatools will use share keys of all the above mentioned shares and encrypt the file/folder key of the uploaded/created/copied/moved file or folder with all applicable share keys.

So for example if you have a structure like /Root/share1/share2, where share1 is shared with bob and joe, and share2 is exported publicly (which is just a special case of folder sharing), and you move 100 files into /Root/share1/share2, megatools will take handles of share1, and share2, share keys for bob, joe, and public export, and will create 300 new file/folder keys for bob, joe, and public export, so that they can access the files.

This has to be done on every filesystem operation that operates on shared folders, to keep files properly shared. It should also be done smartly, so that copying/moving files within the same shared folder will not force the re-encryption of file/folder keys.

No workaround, atm. You can try to use megatools from the dev branch and use the new share or export command. That should export files that are not yet exported within a particular exported/shared folder.

@chinhodado

This comment has been minimized.

chinhodado commented Feb 18, 2015

Thanks for the thorough explanation. Waiting for v2.0 :)

@festum

This comment has been minimized.

festum commented May 18, 2016

Waiting for v2.0 too but when?

@megous

This comment has been minimized.

Owner

megous commented May 18, 2016

Not soon. It's just a hobby, and ATM I'm floded with paid work.

@megous

This comment has been minimized.

Owner

megous commented May 18, 2016

There are some changes in the dev branch that I haven't yet pushed out that implement part of the encrypted HTTP streaming, that are required for data transfers. (major missing thing in the dev branch atm.) When that's done the rest is a piece of cake.

ezsh added a commit to ezsh/Queen that referenced this issue Oct 8, 2018

Switch publishing from megatools to megacmd
Megatools can't add files to a shared folder (the uploaded file is not
downloadable (megous/megatools#54). mega-put
from the megacmd package does not have this problem.

ezsh added a commit to ezsh/Queen that referenced this issue Oct 8, 2018

Switch publishing from megatools to megacmd
Megatools can't add files to a shared folder (the uploaded file is not
downloadable (megous/megatools#54). mega-put
from the megacmd package does not have this problem.

ezsh added a commit to ezsh/Queen that referenced this issue Oct 8, 2018

Switch publishing from megatools to megacmd
Megatools can't add files to a shared folder (the uploaded file is not
downloadable (megous/megatools#54). mega-put
from the megacmd package does not have this problem.

ezsh added a commit to ezsh/Queen that referenced this issue Oct 8, 2018

Switch publishing from megatools to megacmd
Megatools can't add files to a shared folder (the uploaded file is not
downloadable (megous/megatools#54). mega-put
from the megacmd package does not have this problem.

ezsh added a commit to ezsh/Queen that referenced this issue Oct 8, 2018

Replace megatools with megacmd in the publishing script.
Megatools can't add files to a shared folder (the uploaded file is not
downloadable (megous/megatools#54). mega-put
from the megacmd package does not have this problem.

ezsh added a commit to ezsh/Queen that referenced this issue Oct 8, 2018

Replace megatools with megacmd in the publishing script.
Megatools can't add files to a shared folder (the uploaded file is not
downloadable (megous/megatools#54). mega-put
from the megacmd package does not have this problem.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment