I’m a new user, still in trial mode, but am leaning toward purchasing the product for its ability to keep me organized. One question I do have is about saving a project. Why does this process take so long? Whenever I close a project, a dialogue box pops up that says, “Project Backup” and “Creating Backup” is displayed along with a progress bar that shows the percentage saved. This takes a good four or five minutes to complete. I also work with audio and video files, some of them very large. I could save a hundred changes on either of those programs before Scrivener completes its backup. Why is this? Is it because I’m still in trial mode? It’s just very odd because the file sizes for Scrivener projects are nowhere near as large as my audio and video work. I’m using a Windows 10 Home Edition 64 bit system with dual 6-core Pentium i7 processors at 3.4 ghz, 32 GB of RAM, a separate 4 GB video card, and the hard drive I’m saving to still has over 8 TB free. Is this normal behavior for the software?
Project Backup is not the same as save. Scrivener saves your work automatically, usually every 2 seconds. If your project is big it is normal to take some time to create the backup. The time necessary depends on multiple factors like: your machine specs, where do you save the resulting file, are there any other processes running at the same time as the backup, do you create a zip file, the size of the project folder…
Accuracy check: by default, it saves after 2 seconds of inactivity.
If you open the program, open your project, and get right to work and never slow down, there is a very good chance that Scrivener will not save along the way.
As krastev said, there is a difference between save and backup.
A Scrivener project is made up of a number of inter-related files and folders; it is not a single monolithic file.
By the default settings, if you stop interacting (typing, mouse, etc.) with Scrivener for longer than 2 seconds, it will save (write changes) to the component files that you have modified (and only those files), so the save process is usually extremely quick. It does this transparently in the background, but you can also force a manual save if you want.
Also by the default settings, when you close a project, Scrivener will also perform a project backup. This is a separate copy of your project as it is at that point of time, copied to a separate location. This gives you point-in-time copies of your work as you go along. Depending on how your settings are configured for backups, it may be deleting older backup copies after a certain number (if I remember correctly, 5 is the default), and it may be zipping them.
Trial mode has nothing to do with it. The only difference between trial mode and licensed mode is that you don’t get the license warning when you’re licensed.
Because Scrivener is a multi-file project format, every time you add a new file or folder into your project Binder, you are creating multiple files on disk, and creating a folder hierarchy. Most of those files are relatively small. However, if you have (for example) a total of 1GB of data in your Scrivener project, that is always going to take longer to copy than a single monolithic 1GB file. Why is that?
Because of the overhead involved in replicating the folder/file structure. When you copy a single 1GB file, your computer has to do the overhead of creating a single file in a single location – and then it can stream the reads (from the source) and the writes (to the target) in a serial fashion. It can make big writes to the disk, writing continuous blocks as fast as the underlying disk system will let it.
When you copy 1GB of multi-file data, however, you get a lot more overhead. Each parent folder has to be created before any child files/folders can be touched. Each separate little file is at least one different write operation, and the file creation overhead applies to each one of them. This adds up, and if your project is mostly tiny little files, it can dramatically increase the file copy time necessary to duplicate the project.
Another factor that can come into play is what sort of antivirus/antimalware software you have running. Many of the security/AV suites implement a real-time file checking component – which means they hook into the disk system at a low level to scan every disk block you are reading and writing – which can be another huge source of slowdown. I’ve seen, in informal testing, factors of 10x or greater slowdowns thanks to poorly behaved realtime scanning – and the systems involved were from “brand name” solutions. (Do not get me started on how buggy most AV/security suites are.) The same is true, BTW, for any other software that you may have that inserts itself into the disk stack.
The other thing to ask yourself is: where does your live project live, compared to where your project backup lives? They can be on different disk subsystems. On my laptop I have an SSD for my main OS drive and a USB-attached HDD with a legacy spinning platter. The read/write times are VERY different. If I put my project backups on the USB drive, writes to that are going to be inherently slower by a significant factor, just because of the technology involved.
I can’t point to anything in your specific case and say, “That’s why it’s taking so long,” but these are common factors I’ve seen throughout my 25+ year career in IT.
Thank you guys for the replies. I neglected to mention that I’m saving to an external hard drive. I do have a 1TB internal SSD as well but try to keep it free for installation files primarily. I appreciate everyone taking the time to explain the difference between “Backup” and “Save”.