robert1p​
I'm sorry for the late reply. I'll respond below:
Are the files compressed before size is measured? Or if we compress the files before adding them, will it give us more time before we run into the limit?
Is the limit based on the size of the encrypted blob stored on your server?
Can you confirm that each History entry does not contain a unique copy of attached Files? For example, if an Item has three files, and I edit some non-file text multiple times, I would expect that each History entry would simply reference the same three files. It would only be when I update one of the three files that I would now have a forth file in my Vault; i.e. the original three, plus the new update.
I assume the system isn't efficient enough to simply store delta changes for file updates? For example, if I change two lines of text in a 20MB PDF file, I will then have two 20MB PDF files in the Vault (and not a single 20MB PDF, plus a delta).
I've tested this and the file size at the time of upload is counted towards the storage limit. If you compress a file before uploading it to 1Password, then the compressed size of the file will be taken into account.
For items that have previous versions, only the current version is considered "Active" and is counted towards the file storage used.
There isn't any way to edit an existing file. You need to download the file, edit it on your end, and then add the edited file back to 1Password. At which point it would be considered a completely new item.
I assume space is counted against all users of a share vault?
Data storage is cumulative and valid across all shared vaults and personal vaults.
I hope that helps.
-Dave