.idlk files over Cloud storage.

[JayFOCUS]

When you open an Indesign file it creates a .idlk file that stops other users from opening the same file, when it's open by other users. Works great on a server.

On All cloud services we have tried, including Creative Cloud, that file is ignored and two people can easily open the same page at the same time. 

Does anyone know of a cloud service that allows the .idlk file to exist?

[Randy Hagan]

No, alas, I don't.

Not only is the .idlk file no lock, if both (or more) users don't close out of the file before backing out of the cloud drive, the remaining .idlk file can keep everybody from getting back into it. Please don't ask me how I know, the memory is too painful.

For your own good, I recommend you package .indd files on cloud drives and pull them down locally to work on them.

Just like nuking it all from orbit, it's the only way to be sure.

[JayFOCUS]

Pulling files from the cloud, to work on them, and then reuploading again, creates a massive unnessary task for each designer that seems counter-intuitive to using the cloud in the first place.

[rob day]

If a shared file gets worked on simultaneously a Conflicted copy should be added to the local Creative Cloud Files Folder, so here I worked on SyncFile.indd from two different computers at the same time (SYNC TEST folder is inside of my /Users/username/Creative Cloud Files folder):

Pulling files from the cloud, to work on them, and then reuploading again, creates a massive unnessary task for each designer

You shouldn’t have download and upload the files. A work around might be to simply move the file out of the local Creative Cloud Files folder, which would hide it from other collaborators as the CCF folder is sync’d. You could effectively create a "checkout folder" outside of the CCF folder on all of the collaborator’s machines.

Here I’ve dragged  SyncFile.indd to my desktop, opened the file, edit, and save. To make the edited file available to others, all I have to do is drag it back into the SYNC TEST  folder, which is inside of my CCF folder.

Also it looks like files saved and sync’d by a collaborator on a remote machine will open as unsaved—there will be a asterisk in the title.

[JayFOCUS]

I really appreciate your time and how through your answer was. Although not ideal, becuase it creates extra steps, it is a viable workaround and that's what we'll be doing. Thanks for taking the time. 

[John T Smith]

This is a public forum with "some" Adobe staff participation, use the links below to make a report or request
-for Video & Audio & Animator programs https://adobe-video.uservoice.com/
-https://www.adobe.com/cfusion/mmform/index.cfm?name=wishform

[Laubender]

Hi John,

thankfully someone moved that thread over to the Adobe InDesign forum.

Randy's answer above is an excellent one, I think.

Otherwise, when a team is working with a mutual cloud storage volume, every participant has to communicate if he/she wants to open an InDesign document and also has to communicate to all when the document is closed again.

What could happen if that does not work:

The one who saves the document last will "win" and all other edits will be non-existent.

Regards,
Uwe Laubender

( ACP )

[Geоrge]

There is no real "cloud" simultaneous work with .indd. Forget it at this moment of time. This is not a Google Docs philosophy.

But! You can construct share folder in the local network with VPN access and then use it InDesign-InCopy workflow. 

If you're need InDesign-to-Indesign workflow then use it this: https://www.automatication.com/index.php?id=13

[BobLevine]

I am going to repectfully, but strongly disagree with the others.

Communication is key here. This workflow is for very small workgroups and it shouldn't be that hard to send a message to others saying you'll be working on the document.

Copying back and forth is going to cause way more problems. The other possibility is if some are just editing content is to use InCopy which does honor the lock files.

[JayFOCUS]

Respectfully, if the solution is some kind of Monday.com 'communication' platform open at the same time, just to communicate to other staff, about who has what page open and when they closed it, it would unnessarly create hundreds of messages per day, which would just become white noise.

It's pretty simple, when someone has a file open, you either get a stopped from opening the file (just like what happens on a server) or you get a warning before you proceed. 

[Test Screen Name]

This would be a good enhancement for InDesign, why not suggest it. It's certainly not a bug, and it is reckless to move to this workflow in a busy environment where people will not coordinate, carefully and reliably, every time. Disasters will happen constantly and it is your fault for moving to the workflow. Suggestions: https://www.adobe.com/products/wishform.html

[JayFOCUS]

It works just fine on a server. 

[Test Screen Name]

The basic problem is a common one: how to work exclusively on a shared resource, not at all unique to InDesign or publishing. What I describe is basically a "check out/in" system. The user indicates they want to check out a file, the file or folder gets downloaded (perhaps an optimized copy checking it is up to date), the user edits; the user says they are finished, the changes are uploaded, the lock is released. Many companies have surely been working this way forever, since it has always been the case that working from a network share in unsupported and risky.

So I'd be looking for an InDesign plug-in that automated the check-out/download/open and save/close/upload/check-in process. A good check-in/out system will have ways of dealing with exceptions e.g. view locks, release locks held by failed connections, check in a file worked on offline, all with auditing and accountability, and hopefully versioning (or based on a versioning cloud like DropBox). Does anyone know of any such?

[Geоrge]

>>  working from a network share in unsupported and risky.

You make may day. Can I do answer by some video to you about that cloud-services is "not" more risky than corporate-network? Here you go - 

https://youtu.be/CFdZWgiAj8I

[Test Screen Name]

Oh, I agree, don't need to see the video to agree. Cloud is outside of your control, could close down or be mis-adminstered or anything. However, it has many conveniences. So long as it is comprehensively backed up (or is only a backup), I'm reasonably happy, again so long as my data is not too sensitive. Lot of stuff I wouldn't put out there unencrypted.

As well as not being a great place to keep data, it's also a poor place to be fetching it from, because the internet is not 100% reliable. There is of course no real "open from the cloud" functionality, you are always working with a synchronised copy; while file sharing will read or write partial files as needed.

I think adoption has been boosted by a wave of optimism, and utterly flawed reasoning in some cases ("great, we don't need to back up any more, the cloud will do it for us!")

[Randy Hagan]

Certainly working in "the cloud" has its issues. But referring back to the original question, this issue centers not on the vagaries of cloud services but on the vagaries of where InDesign scatters .idlk files and how well they work to prevent introducing version control issues.

As Bob reported elsewhere in this thread, other Adobe programs don't have the same issue. I wouldn't say InDesign lock files are the root of all evil, but they're certainly at the root of a bunch of 'em. I'm as big a fan of workarounds as the next guy — or more — but isn't this a pretty common issue around these parts? Perhaps this should merit some special attention by Adobe developers?

Randy

[rob day]

I think it is worth noting that the OP’s original question, about collaboration versioning problems, doesn’t have anything to do with Cloud server security—if you are worried about a hacker getting into an Adobe server and stealing your page layouts, then don’t use the sync’ing feature.

You could imagine a checkin and checkout workflow, where there is no file sync’ing or lock files—a single version of a package is passed between the collaborators for editing, which would prevent accidental overwriting. But the downsides of that approach would be worse that the overwrite possibilities, starting with where is the backup of the current version happening?

Bob is right, the group has to communicate, or someone will have to be responsible for untangling conflicted copies.

[Kasyan Servetsky]

We work on DropBox and encounter the same problem. Here's my idea about how to solve it. So far, it's totally untested.

[JayFOCUS]

Is this working for you? Sounds like a great solution!

[rob day]

What if there were 3 collaborators all working on laptops connected to the internet via WiFi? User A unknowingly looses her WiFi connection, opens the file, makes a correction, saves and closes. In that case user A’s warning text and the ID files would not sync to the other user’s DB folders until she reconnects to the WiFi network. In the meantime Users B & C could be making edits, and their warning text file would sync to their machines, but not to user A’s.

[Kasyan Servetsky]

An unstable internet connection is a different issue: you have to find out why it’s unstable to eliminate the cause. In my case, it turned out to be a broken TV socket so I took my soldering iron and fixed it.

Also, I use a cable connection for the computer where I do my work and wi-fi for the rest of the devices. This makes the connection much faster and reliable.

[rob day]

I can see that the script alert would work much of the time, but as the size of the collaboration groups grow so do the uncontrollable network variables. I think that’s the reason we are not seeing something better than conflicted copies from Adobe or Dropbox. The script is obviously going to work between two communicating parties, but does it work in a group of 20 noncommunicative collabrators on variable networks?

[Kasyan Servetsky]

I think the script should work with 20 and even 120 collaborators (though in our workflow only 4 involved in the process).

The main idea behind the script:

1. warn if someone has already opened the file
2. tell who exactly opened the file

Of course, it's possible that two users would open a file simultaneously and we would have to examine the conflicted copies. But it's a rare chance.

Also, if someone updates numbering in a book, and others have docs open, in the current version, this would give a warning for each open doc.

Anyway, in my opinion, with the script collaboration via DropBox would be easier than without it.

[rob day]

What happens if 2 of the 20 collaborators open, edit, and save the file on laptop with no internet connection? The text file generated by the script may or may not have been sync’d to those two users and wouldn’t necessarily be up-to-date.

[Test Screen Name]

I agree, no reliable solution can be built purely on synching of files. It needs a higher level monitor on a server somewhere, which locks or checks locks in real time.