I don’t know how feasible this might be. I even imagine Keith et al. have already considered this and discarded the idea because it is not feasible. Still I will go ahead and offer it as a suggestion:
Why not change the default format of the Scrivener project to a compressed zip archive of all the folders and documents? This is what the OpenOffice and LibreOffice .odf format does, and Scrivener already supports compressing as zip archives backups.
I can see a few advantages to doing so, if it proves doable. The Windows version would have a single .scriv file for each project, rendering maybe better cross platform compatibility. Working with Dropbox should be easier since there is only one file going up and down. Maybe even iCloud backups would be possible or easier if there is only the one file, rather than the ‘package’ hidden folder, being backed up.
The drawback would be that when launching or closing a project, Scrivener would take a little longer to decompress or compress the files. Not very much longer, perhaps?
And what would happen with the automatic backups that take place every 2 seconds or whatever of inactivity? It would have to zip the whole thing up again and upload the lot, and with a large project that would stall the app for significant periods of time.
This would defeat the whole purpose of Scrivener’s existing file format, I’m afraid. The reason Scrivener uses a package/folder format is so that you can import as much research as you want, and grow the project as large as you like with text and research files (images, PDF files, movie files, sound files). By storing everything in a package/folder, Scrivener doesn’t need to read all of that into memory on project open (or decompress everything). Instead, it can read the bare structure of the project and load the text and research files only as required, as you click on them to open them.
OpenOffice, Word and Pages all use zipped formats, but they can do so because their files rarely grow more than a few megabytes, so decompressing all of the data within them into memory doesn’t cause a problem. By comparison, we have users with Scrivener projects in the gigabytes. I have more than one project of over 200MB, and we commonly hear from users with projects of between 100 and 500MB. Obviously, it’s not feasible to decompress all of that into memory. And decompressing it to disk - unzipping all of that data every time you opened a file - would be problematic too, obviously (and zipping it back up whenever you save!). And unfortunately, there are no frameworks or APIs that allow for the reading and writing of data in memory directly into a .zip file, so there’s no way of getting the behaviour we currently have with a .zip file.
Yup, that’s the problem. LibreOffice and Word might be monolithic document formats that use .zip to obscure their multi-file nature, but you can’t store 8 gigabytes of PDF files in an ODT or DOCX file (thank goodness!). Most of the problems with the idea boil down to that fundamental issue: Scrivener is designed to be a place that collects all of the loose ends associated with writing a work. Not everyone may use it that way, but that is what it is designed for. Thus, adopting a format that degrades usability after the first few hundred megabytes of audio interviews, or whatever, would defy its design. Having zip compression as an optional feature per-project negates many of the positive arguments for it, such as making things more familiar for Windows users who have never encountered large-scale software like this. We certainly could not set it on by default because then people will just get the impression that Scrivener is awful at what it claims to be good at.
Plus, for stuff like the now popular Dropbox style systems, lots of files always trumps one big huge massive file. These systems try to optimise networking so that if five bytes change in the middle of a 20mb file, only those bytes are transferred, but that doesn’t always work; it cannot be relied upon. That is even more true with compression, where a few changes might dramatically alter the the byte sequence throughout large portions of the file, if not the entire thing from end to end.
If you’re just looking for backups though, you’ve already got that. Use File/Back Up/Back Up To… and you’ll discover a checkbox to zip the duplicated project. This is a really convenient tool for periodically backing up to some networked device or service, or creating copies to send via e-mail.
The only scalable solution to this problem (that I’m aware of) is a binary database format, but this then goes against another principle of Scrivener’s design: don’t lock the user into a proprietary format.
When launching, closing OR saving a project. And remember that Scrivener autosaves at very frequent intervals.
We have users with gigabyte-scale projects. Such big projects need to be handled carefully to avoid performance problems even with the current file format. If you had to Zip/UnZip everything, every time? Disaster.
Scrivener’s hierarcy of folders and text, image and other formats is not unique.
Word changed to this in the late 1990’s but they wrap it in a zip format with .DOCX extension. This format works on any file system. This would protect Scrinver projects from being broken by an incomplete copy or move option in the File manager tools etc.
Also it would stop Scrivner from breaking OS features like Recent file list.
It also means that built in version in systems like OneDrive would suddenly become a powerful assest to Scrivener writers. Versioning happens now, but its imposibble to roll back hundreds of loose files to make sure we don’t break the project. If the project hierarchy was ZIP wrapped rolling back a version would be simple, like it is when any other system.
I have zipped a Scrivner folder structure. It works easly. No errors file name issues. So I am begging you to add a "Save Project as a Single .scrivz option in all OS’s And let us set to user this as an option. Thanks!!
Below is my recently saved files list in Windows 11 after opening ONE Scrivner project. It’s broken this feature in the OS. At top is same project as on file in a zip I created in a couple seconds. I would love it is Scrivner was tidy and kept is project is a Zip wrapper.
You can do that with backup copies. We’ve chosen not to do that with active projects because it’s a fairly major performance issue, due to the combination of (1) very frequent saves and (2) Scrivener’s ability to include large research and other materials inside the project.
I have strong confidence in you.
Microsoft does this with very large files and save continioulsy now when saved to Cloud synced location. I don’t think they have magically exceptional developers.
And given the power of machines over the last 20 years has increased dramatically especially with the replcaement of HDs with SSDs, I am pretty sure Scrivener would have acceptable performance on all PCs made in the last 7 years. I do think a transitional time would make sense where users with older machines of special needs, could save to “loose in the file system” or in a Zip container supporting those of us who value project security and lower risk of having some unfortunate accident spread our project all over, vs having one file.
I believe you can make it work. I don’t think you would have to use strong compression, just leverage the industry standard file wraper. But imagine if you did have a users with a HUGE set of files, on a relativly new machine, what value compressing those files might have Hmmmm?
I work on a graphics and text based animation tool written by one developer inhouse, that I myself have created and used files in excess of 1 GB in size, I works and No I don’t wait a long time to move between animation frames or pages in the tool.
I have confidence you can do it and in doing that create a more manageble and safer file format.
Never had a failure of Scrivener file in more than a decade of use. Pretty safe as it is, IMHO. And Scrivener does a pretty good job of managing the files already, so not sure putting the production into a Zip improves anything. As @kewms already says above, you can use the backup Zip files already now if this is how you want to interact with your projects.
Many of our users have dedicated writing machines, which are often older systems with minimal specifications. And many of our users have internet connections with limited bandwidth.
My comment was not hypothetical. We have tested exactly what you propose, and found that it made the application essentially unusable.
