Formed in 2009, the Archive Team (not to be confused with the archive.org Archive-It Team) is a rogue archivist collective dedicated to saving copies of rapidly dying or deleted websites for the sake of history and digital heritage. The group is 100% composed of volunteers and interested parties, and has expanded into a large amount of related projects for saving online and digital history.
Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.
Sign upGitHub is where the world builds software
Millions of developers and companies build, ship, and maintain their software on GitHub — the largest and most advanced development platform in the world.
Check target disk space before attempting restore #296
Comments
|
@adamcharlton: makes sense. Should be easy to implement for single VM restores. |
|
@adamcharlton out of curiosity, which macOS/rsync version are you using? |
|
@adamcharlton we've been discussing this internally. The TL;DR is that estimating if there's enough free disk space available is complicated and/or expensive because we compress some data that has to be expanded remotely. We're looking into better error reporting for now, so the cryptic rsync error isn't the only thing you get. |
Hi, I encountered an issue where my restore failed due to insufficient disk space on the restore target.
When running the restore on Linux an error like
rsync: writefd_unbuffered failed to write 4 bytes to socket [sender]: Broken pipe (32)occurs however on a Mac you do not get an error at all and it just stalls until you close the restore process.I think it would be nice if the restore calculated the size of the restore about to happen and verified that the
/data/userdirectory on the target had sufficient space for the restore, as this would provide instant feedback that the restore would not be successful.