Indesign keeps reporting file is locked on SharePoint Online

[defaultyctpbh6egm77]

I have an end user that has an Indesign file saved to a SharePoint library.  There is also a Win 10 mapped network drive to the same SP Library, but most of the time, when she tries to open, Indesign reports that the file is already open with another user, which it is not.  Only 2 people have access to the library and the other person has confirmed they are not using the document.

Microsoft have looked at logs etc provided and say it's not a SharePoint issue, anyone have any pointers on where to look?

[Randy Hagan]

I'd suggest that you have a hanging InDesign lock file (.idlk) in your system, your colleague's system and/or your SharePoint drive that's at the root of your issue. Try the following steps, which will hopefully help you past your issue.

1. Close down InDesign on all your systems. No files open, no applications open. Completely shut down.
2. Search for all .idlk files in all your various locations — your system, your colleague's system, and your SharePoint server/cloud locations. Don't be surprised if you find a bunch of them. Kill them all. If all your InDesign applications are closed down, they're nothing but debris.
3. Go back to open your InDesign document. Most likely, this will get you up and running again.

InDesign lock files keep you from accidentally opening — and changing — an InDesign file if someone else has it open. That's a good thing, until it hangs up a file and suddenly it isn't. Periodic purges of .idlk file debris will make it a lot less likely that you'll have the same issue in the future.

Hope this helps,

Randy

[defaultyctpbh6egm77]

Hi Randy,

Thanks for the reply, just deleted 18 idlk files from SharePoint, waiting for a call back from my end user.  I did notice these before, where it had created the file in the same folder as the document, I did delete them, and for a short while it was ok but then failed next day again.  Will advise if this resolves.

[Randy Hagan]

The good news, then, is that you have isolated the issue, cured it temporarily, and can relay more precisely what is at the root of the problem.

Cloud resources are notoriously bad about hanging up resources when saving/closing InDesign files, and  clearing/releasing these .idlk files. Some services, like Dropbox, can mitigate the issue by turning off smart sync utilities. Others don't have such readily-accessible fixes. I can't address the SharePoint cloud end of your situation. But I can tell you that orphaned .idlk files are bad juju, no matter where they are found.

For an interim solution, I'd suggest that operators pull down a packaged folder from the cloud, update files from their own desktop, them upload the package with the latest changes back to SharePoint. This is not the preferred solution, but it will hopefully get you by while you work with whoever's managing your SharePoint resources to find a more permanent solution. Hopefully with this additional information, your Microsoft support folks can help you find a more effective solution for this issue.

Good luck,

Randy

[defaultyctpbh6egm77]

Morning,

Bad news is that the issue occured again within 30 mins.  Ran a search on entire C: on users system, no .idlk files found at all, I'd cleared the SP ones, very bizarre.  The search continues.

[Randy Hagan]

OK. So at this point we know what causes the problem, and what delivers a temporary fix to the problem. And we know the temporary fix is inadequate. And that you are not having the users work from packaged folders off their local drives and then uploading the results to your SharePoint server.

So the same workflow is generating the same results. And those same results are not satisfactory.

In the immediate term, is there a different cloud resource you can offer your users? I know IT folks hate exceptions, but if we are dealing with two users with one specific application, maybe a physical server address in-house for working with InDesign files, or an alternate cloud resource that doesn't cause the problems SharePoint is dealing you is the better option. Then, hopefully you can work with your Microsoft support to isolate things on the SharePoint side and come up with a better long-term solution.

I wish I had a better answer for you. But at this point there's nothing more I can offer.

Good luck,

Randy

[defaultyctpbh6egm77]

Sadly not, I have already been on with MS as I suspected it was a SP issue from the start, but after they have evaluated logs etc, they are saying it's an Adobe issue.

Think in the short term, will have to recommend that these Indesign docs are stored on the normal file servers and not SharePoint, until I can find the smoking gun and rectify the issue.  Thanks for all your help, really appreciate it.

[Randy Hagan]

Truth be told, it lies to some degree with both parties. Adobe generates the resilient .idlk/temp file, and SharePoint refuses access to release/delete it.

It's a lot harder to run a cloud service that can process working files than it is to create one that's a repository for stored ones. Microsoft devoted a lot of internal efforts to ensure that its own temp files for Office docs can seamlessly release temp files from documents. For others? Not so much. Neither side seems sufficiently motivated to resolve the issue.

So it's up to foks like us to figure out how to make this stuff work anyway.

I think setting aside local resources is the right call. If you're branching/defining by file suffix in your efforts, please be aware that InDesign documents (.indd files), templates (.indt), book files (.indb), libraries (.indl) and interchange/markup files (.idml) all need to be part of your solution.

Good luck,

Randy