I'm not sure what has changed recently, but a large part of my firm has started experiencing error (109) whenever they attempt to save after editing a pdf document. Most of them are on 9.5.5, a few are on 9.5.3.
My first advisement was to print the document to PDF and save that to their desktop in order to maintain their changes so they could then reupload to Sharepoint or bring the file into a binder in Engagement (accounting software), assuming some sort of interaction with the network was causing the error. However, that didn't make the error (109) go away. Even files that were printed to pdf and saved on the desktop cannot be edited and resaved on the desktop without that error reoccuring.
If it was one or two users, I'd suspect a rogue program of some sort was causing incompatibility issues, but it's getting into the low 30s now and I'm hoping to get this solved.
What tool is used to generate these PDF documents? You can check under File > Properties > Description tab. Also, in the same dialog, are there any unusual fonts?
Do you have the Pro. version of Acrobat around? Have you tried using Preflight to see if there are any syntax errors or font errors? It may be that the point update of Acrobat is more strick on determining the validity of the PDF and it's exposing something that a earlier version of Acrobat 9 did not. This can happen on PDF documents created using 3rd party tools, which are not necessarily formed properly.
Excellent suggestions Lori. We're unable to use Pro to troubleshoot at the moment, but we were able to see that all the files are generated by the same program under the description tab (GoSystems). I'm currently running through some test with my users to figure out how these documents are being saved.
We've narrowed the behavior to any deletion produces the Error (109) upon saving. This could be pages or even edits added during the same session. If any item is deleted, then saving the document will produce the error. Strangely enough, opening the document, doing save-as before any work is done, then overwriting the document with itself removes this behavior and the file behaves appropriately.
I'll let you know if any other problems crop up in Acrobat related to this issue, but for now it appears to be another companies template/print behavior + user issue.