initMountPoints is marking a user as successfully initialized too
early. If the user was not found an NoUserException was thrown, the
second time initMountPoints is called would not rethrow the exception
and happily continue.
This fix makes sure that we consistently throw NoUserException when
initMountPoints is called repeatedly with invalid users.
In some scenarios initMountPoints is called with an empty user, and
also there is no user in the session.
In such cases, it is unsafe to let the code move on with an empty user.
In theory, if your instance ever creates more jobs then your system cron can
handle, the default background jobs get never executed anymore. Because
everytime when the joblist returns the next job it looks for the next ID,
however there is always a new next ID, so it will never wrap back to execute
the low IDs. But when we change the sort order to be DESC, we make sure that
these low IDs are always executed, before the system jumps back up to
execute the new IDs.
The hook now calls the share manager that will call the responsible
shareProvider to do the proper cleanup.
* Unit tests added
Again nothing should change it is just to cleanup old code
If we do not allow public upload we should limit the permissions on
links shares upon retrieval.
* Added unit test
* Allow fetching federated shares by token as well
This makes the post_userDelete hook call the sharemanager. This will
cleanup to and from this user.
* All shares owned by this user
* All shares with this user (user)
* All custom group shares
* All link share initiated by this user (to avoid invisible link shares)
Unit tests are added for the defaultshare provider as well as the
federated share provider
in order to create a 1:1 copy of a file if a version gets created
we need to store this information on copyBetweenStorage(). This
allows us to by-pass the encryption wrapper if we read the source file.
The code path called when using external storage with WebDAV is using `\OC\Files\Storage\Wrapper\Encryption::getMetaData` which did not contain the actual encrypted version inside the cache entry version. This lead to the following:
1. User uploaded a file
2. File is created and `\OC\Files\Storage\Wrapper\Encryption::getMetaData` is called. It has an empty `encryptedVersion` but sets `encrypted` to either `true` or `false`.
3. The call when updating the file cache will use the old version.
Fixes#23536
The new sharing code is much stricter in checking permissions. However
for non moveable mounts the permissions UPDATE+DELETE are not reported
on the mount point.
This is just a quick fix.
* Updated unit tests
Thomas Müller
Roeland Jago Douma
Vincent Petry
Joas Schilling
Thomas Müller
Lukas Reschke
Roeland Douma
Joas Schilling
Robin Appelman
Stefan Weil
Jörn Friedrich Dreyer
Frank Karlitschek
Bjoern Schiessle