The data directory is not necessarily located at "../..". The proper
directory is now got by running "php console.php config:system:get
datadirectory".
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
A zip32 file can contain, at most, 65535 files (and folders), so take
that constraint into account.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
* OSX doesn't handle 64zip that well
* Some other implentations don't handle it perfectly either
* If the file is belog 4GiB (some overhead) => zip32
* This covers the 99% case I bet
Signed-off-by: Roeland Jago Douma <roeland@famdouma.nl>
Add a new column.
In the postSchemaChange copy over the values (with lower).
This should work just fine as this is a very simple operation.
Even if you have 1M users in the db backend this should be fast
enough.
Signed-off-by: Roeland Jago Douma <roeland@famdouma.nl>
In order to autoload the server context classes the "bootstrap"
directory was explicitly listed in Behat autoload configuration. This is
fine in the configuration of acceptance tests for the server, but it
would force the configuration of acceptance tests for the apps to
explicitly include the path for the server context classes to be able to
use them (for example, for the login step).
Besides with its own configuration Behat also supports autoloading
classes using Composer, so now context classes are autoloaded using
Composer instead; thanks to this the server context classes are
autoloaded also in the acceptance tests for apps without any explicit
configuration in them.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
The jQuery File Upload plugin triggers the "stop" event once there are
no more files being uploaded (even if some of them were added when
another upload was already in progress). Therefore, the progress bar
should be hidden in the "fileuploadstop" callback.
In some cases the "stop" event is not triggered and thus the progress
bar is not hidden once no more files are being uploaded. This is caused
by a race condition and it will be fixed in another commit; except in
buggy cases like that one (that need to be fixed anyway) it is safe to
hide the progress bar in the "fileuploadstop" callback.
In any case, note that the callbacks in "fileuploaddone" may be called
after the "stop" event was triggered and handled when using chunked
uploads. In that case once all the chunks are uploaded the assembled
file is moved to its final destination, so its promise could be resolved
after the "stop" event was triggered. Therefore a different approach
would be needed to keep the progress bar visible until the chunked
upload is truly finished, but for the time being the current one is good
enough.
Before this commit the progress bar was being hidden when the first
upload finished, either successfully or with an error, no matter if
there were other files being uploaded too.
The progress bar was being explicitly hidden also when the upload was
cancelled. When an upload is cancelled all the single uploads are
aborted, which triggers a "fail" event for each of them. However, the
"stop" event is always triggered when no more files are being uploaded,
so it is triggered too once all the single uploads were aborted. As all
the single uploads are immediately aborted in a loop when the general
upload is cancelled it makes no difference to hide the progress bar when
the first single upload is aborted or when all the single uploads were
aborted, so the progress bar is no longer explicitly hidden in the
former case.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Daniel Calviño Sánchez
Roeland Jago Douma
John Molakvoæ (skjnldsv)
Roeland Jago Douma
Morris Jobke
blizzz
Nextcloud bot
Jared Boone
Julius Härtl
Joas Schilling