Kelly Bellis Posted May 3 Posted May 3 Windows 10 Pro, AffPub2 v2.6.2 Any idea what we're talking about when reading "could not acquire a lock"? This message arose after I opened a document last worked on in August 2024 and I tried to Save As... Quote
MikeTO Posted May 4 Posted May 4 Hi Kelly, are you opening and saving your files on a cloud, network, or external drive? If so, move the file to a folder on your internal drive that is not synced to a cloud and it should work correctly. Quote Download a free PDF manual for Affinity Publisher 2.6 Download a quick reference chart for Affinity's Special Characters Affinity 2.6 for macOS Sequoia 15.5, MacBook Pro (M4 Pro) and iPad Air (M2)
Kelly Bellis Posted May 4 Author Posted May 4 Hi Mike, Thank you for the reply. No cloud, network or external drive is involved. The AffPub document is stored on an internal hard drive (L:\) though does have a long winded path, something which never has caused any issues. Quote
Kelly Bellis Posted May 4 Author Posted May 4 FWIW - The issue persists this morning with this 145-page document; however, and so far in other tests this morning, only with this one AffPub document. Other AffPub documents can be Saved As... without issue. Quote
carl123 Posted May 4 Posted May 4 28 minutes ago, Kelly Bellis said: though does have a long winded path, something which never has caused any issues. Windows does have a maximum filename + folder character limit of 256-260 characters You may want to make a copy of your file and rename it to test.afpub to see if that opens and "Saves AS..." OK When doing the "Save As..." use another short file name Or move it to a root directory and see if that opens and "Saves As..." OK MikeTO 1 Quote To save time I am currently using an automated AI to reply to some posts on this forum. If any of "my" posts are wrong or appear to be total b*ll*cks they are the ones generated by the AI. If correct they were probably mine. I apologise for any mistakes made by my AI - I'm sure it will improve with time.
Kelly Bellis Posted May 4 Author Posted May 4 @carl123 Cool. Thanks for that + ! L:\US Coast and Geodetic Survey Annual Reports\Geographical Positions\Annual Reports related to Geographic Positions\Extracted pages related to Geographic Positions in Section I\Section I -Geographic Positions from Annual Reports 1851-1874.afpub By my count there's 245 characters from stem to stern. If I Save As... appending with just 2 additional characters all is fine and dandy; however, in my blissful ignorance since the long forgotten days of 8dot3, and believing the 256-character limit was for individual names, not the full path string's summed character length, I failed to have put 2 and 2 together. And yes, I'm also seeing mention of 260 being the limit. FYI & FWIW - Another interesting discovery this morning is the potential in Windows 10, and later, to enable that maximum to be 32,767 characters through a registry modification. The caveat is that LongPathsEnabled may not play well with applications never designed to handle them. Thank you Carl for helping me understand the wall. And maybe, from all of this, the developers might consider that the terse message be expanded to inform the user that the lock couldn't be acquired due to the path string's length. Quote
Bound by Beans Posted May 4 Posted May 4 52 minutes ago, Kelly Bellis said: And maybe, from all of this, the developers might consider that the terse message be expanded to inform the user that the lock couldn't be acquired due to the path string's length. There’s nothing “maybe” about it. Any Windows architect in a company must anticipate this scenario, and when it’s served on a silver platter, the company should prioritize ensuring that a developer is explicitly instructed to implement an error message the developer does not write themselves. I can easily imagine Windows being gentlemanly enough to provide a specific error code for this — I can’t imagine otherwise (and there’s no need for forum members to look it up, that is Serif job). As it stands, we’re essentially dealing with a clunky, unhelpfil “An error occurred”-level message — a type of error customers unfamiliar with Windows’ long and storied history of limitations could never possibly figure out the cause of. It could easily be detected and translated into something user-friendly — perhaps even something proactive, so the error message doesn't completely restart the save workflow. Kelly Bellis 1 Quote
thomaso Posted May 5 Posted May 5 22 hours ago, Kelly Bellis said: The issue persists this morning with this 145-page document; however, and so far in other tests this morning, only with this one AffPub document. Can you confirm that the .afpub isn't corrupted? Does the issue saving issue still exist? Your 2nd screenshot seems to indicate that the file from August 2024 (1st screenshot) has been saved in May 2025, with its file size turning from 178 to 125 kB. Does your info about a "145-page document" actually refer to the 178 / 125 kB .afpub? Quote • MacBookPro Retina 15" | macOS 10.14.6 | Eizo 27" | Affinity V1 • iPad 10.Gen. | iOS 18.5. | Affinity V2.6
Kelly Bellis Posted May 5 Author Posted May 5 @thomaso 1) The issue was entirely due to the extra long character string path. Nothing was corrupted. 2) The file sizes are moot as one was from Aug 2024 and the other recently after editing Old Bruce 1 Quote
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.