Problem/Motivation
When creating tests for drush commands realized that copy-local copy for the all scheme stalls after copying public:// when starting private:// files
Unknown root cause at this time.
Workaround: Execute with --scheme=public followed by another run with --scheme=private
Steps to reproduce
drush s3fs:copy-local --scheme=all
Proposed resolution
Remaining tasks
User interface changes
API changes
Data model changes
| Comment | File | Size | Author |
|---|---|---|---|
| #2 | drush_s3fs_copy_loca-3208175-2.patch | 5.21 KB | cmlara |
Comments
Comment #2
cmlaraRoot cause is that there is a static on the batch variable provided by batch_get() used in S3fsFileMigrationBatch::execute(). This data would remain persisted after we called drush_backend_batch_process() in execute() and be a part of the batch when we called execute() a second time for the private:// scheme. This corrupted the batching.
This can be resolved by moving drush_backend_batch_process() to S3fsCommands.php and calling the execute() commands only to prep the batch.
Reworking a bit of the language from S3fsCommands and cleaned up the tests to match the new logic flow.
Comment #3
cmlaraComment #5
cmlara