- How do I install sykez/laravel-storage-copy?
- Run composer require sykez/laravel-storage-copy. The package ships as a Laravel service provider with auto-discovery for Laravel 5.5 and above, so there is no manual provider registration and no facade alias to add. There are no migrations to run and no config file you need to publish, so setup is essentially the Composer install plus a sandbox test of the storage:copy command.
- Which Laravel and PHP versions does it support?
- The package is a thin wrapper over the Storage facade, so it works with any Laravel version that uses Flysystem-backed disks defined in config/filesystems.php. However, guaranteed compatibility across Laravel major versions is not documented, so check the illuminate/support constraint in composer.json and the date of the last release before committing. Pin an exact version and test against the Laravel major you actually run.
- Can it copy whole directories recursively, or only single files?
- The command is built for copying files and directories between disks, and recursive traversal of nested trees is the intended use case. Because the project has very little public usage (roughly 7 stars and no dependents), it is worth spiking a deeply nested tree, an empty directory, and keys containing spaces or unicode in a sandbox first. If your source data includes symlinks or unusual path formats, test those explicitly before relying on the command.
- Does it stream large files or load them into memory?
- The package documentation does not state whether it uses Flysystem readStream and writeStream or buffers each file into memory, and that is the biggest unknown for anything beyond toy datasets. Run a copy with a file large enough to expose memory behavior and watch peak memory usage during the run. If it buffers, copy in batches or fork the command to stream.
- What happens if a file already exists at the destination?
- Overwrite, skip, and fail-on-exists behavior is not described in the package overview, so treat the current semantics as unknown until you verify them. Run the same copy twice against a sandbox disk and diff a manifest to see whether files are overwritten, duplicated, or rejected. Idempotency matters a lot if you plan to re-run the command for a delta before cutover.
- Which disk types can I copy between, such as S3 to S3, local to S3, or SFTP?
- Because it goes through Laravel's Storage facade and Flysystem adapters, it should work with any disk you have defined in config/filesystems.php, including local, S3, GCS, Azure, and FTP or SFTP. Pairings like local to S3 or S3 to S3 are handled by the underlying adapters rather than by the package itself. Verify visibility and metadata behavior for the specific pairing you need, since those differ between adapters.
- Is there a dry-run mode to preview what will be copied?
- A dry-run flag is not mentioned in the package documentation, so do not assume one exists. A practical substitute is to point the command at a scratch bucket or prefix and compare a file manifest before running the real job. If a preview is essential, the command is small enough to fork and add one in well under a day.
- Does it verify checksums or handle interrupted runs and partial failures?
- There is no documented checksum verification, resume support, or partial-failure handling, so treat data integrity as something you must confirm yourself. Generate a manifest of source keys, sizes, and hashes and compare it against the destination after the copy. For long-running jobs, plan to re-run the delta rather than relying on an automatic resume.
- Is it safe to run against production storage?
- It is a CLI-only Artisan command with no web attack surface, and it runs with whatever credentials your disks already use, so the main production risks are data integrity and long-running invocation behavior rather than security exposure. Scope the credentials to the specific bucket or prefix you are copying instead of reusing broad application credentials. Run it in a maintenance or dual-write window and re-run for the delta before cutover.
- Should I install it as a dev dependency, and what happens if the package is abandoned?
- If the command is only used for one-off environment migrations, composer require --dev keeps it out of your production runtime; promote it to a regular require or vendor the command if your deploy image needs it. The package has a single maintainer and effectively no adoption, so plan for the possibility of abandonment. The command itself is thin enough to fork or vendor in under a day, and rollback is a simple composer remove with no schema changes.