SQL access rights and different platforms

[IoannisSyrogiannis]

Today, I suggested to two users to share the same configuration file, since they would eventually deal with the same projects.
One computer is a Mac with 2.18.15(? I am not sure, but I believe so), and was sharing the configuration and cinemas files with another Mac, storing them on a NAS. Nothing worth mentioning there.
The other, is a Windows PC. It had a 2.16 version and after finding out (because there was no choice for the cinemas SQL file), was updated to 2.18.18.
First time that the windows machine shared the config file, it was corrupted, but -since the KDM creator on the other was open, and probably because of that- the config.xml was automatically backed up to config.xml.1. So, that was good news.
Afterwards, and after backing up again, tried to change again to the configuration file on the network. No complaints there.
When tried to change to the cinemas.sqlite3 file on the network, though, it was impossible.
Every time that the (Win) DCP-o-matic would open, it would complain for the /<NAS>/<Folder>/cinemas.sqlite3 not being available to be written. Then the notice that the subtitles' way to treat Y axis offset is changed. Then, no change on the SQL file was possible. Every time that it was changed on preferences, it would (again) complain about not having the correct access rights.

For that, opening the KDM Creator on the Windows machine was impossible as well.

When the folder on the NAS was inspected, one could make a folder in it. But the cinemas file would not be read/write accessible.
When tried from the Mac computer to change the properties of the cinemas file, it was impossible. The user there would have full access, but "everyone" would have none. Unlocking the configuration and changing to "read/write", would change to "none" right away.

So, I am wondering:
Is there any solution to the situation that would include sharing that file between Mac OS and WindOwS?
Is the position of the cinemas database a part of the config.xml, and as long as the config.xml is the same, the cinemas.sqlite3 file should be as well?
Could it be that a difference on "describing" the position on the NAS (/<NAS>/<Folder>/cinemas.sqlite3 vs <NAS>://<Folder>/cinemas.sqlite3 vs <NAS>\<Folder>\cinemas.sqlite3) would render the cross-platform collaboration impossible?

I don't know if the file access privileges are something that is meant to be made from DCP-o-matic or not. So far, copying the cinemas file to a local folder and pointing to that, or pointing to the original file in /Users/<user>/AppData/... etc. etc. didn't solve the matter.
Any insight from anyone using the same config file for different platforms would be great.

[IoannisSyrogiannis]

To add some info on this, it seems that the configuration file on my (Win) PC contains the following:

Code: Select all

<CinemasFile>C:\Users\<user>\AppData\Local\dcpomatic2\cinemas.sqlite3</CinemasFile>

I understand, now, that it's most probably this, and not the file privileges that don't work cross-platform. Even if I can't be 100% sure.

So, is there a workaround?
May one use a relative path? (./cinemas.sqlite3) to show that the cinemas file is in the same folder as the configuration? (Even when I write this, I doubt that Windows will work with "./" instead of ".\".)
I thought that maybe using a file-share app, like dropbox, etc. would keep the file in a local folder, but that wouldn't solve the cinemas file being pointed on the configuration file. At least one of the different OS computers would choke on where cinemas.sqlite3 is.
Using a string that would be conformed in each system? Like, $CINEMAS_FILE ? That would be a new feature for DCP-o-matic, instead of workaround.

Is there anyone here that have solved that puzzle? How did you?

[carl]

I don't fully understand what is going on here, but first I'd be interested to know why you want to share config.xml between machines. I've tinkered a bit with this in the past and I don't think all this config stuff is in a very good state!

As it stands, sharing config.xml between two machines is a bit "risky", just because there is no locking, and config.xml is only read when DCP-o-matic starts.

[IoannisSyrogiannis]

The reason is that the machines are in the same room, working with the same files interchangeably and sharing the same certificates, DKDMs and cinema credentials "automatically" would render the copying of the (configuration) files upon every end of session on one machine unnecessary.

I was under the impression that it has been (not "common", but still) practice. Maybe because that was verbally explained to me in the past. And keeping the cinemas file an SQL database was to facilitate that.
Was the sole conversion of cinemas' file an indication that the specific file is meant to be shared between machines, but not any other (xml)?
Would it be better to export all KDM decryption settings and signing DCPs and KDMs chain and then import/add them to the other machine, and share only the cinemas' file?
The downside of that is having to copy DKDMs between the machines.

[carl]

I see, thanks.

It's true that config.xml sharing does happen... and you're right that the idea of using SQL was partly to make sharing data between instances easier to do properly.

I feel like the "correct" solution would be to fix the config system by removing anything that's not really "configuration" (e.g. certificates) and putting them somewhere else, in SQLite, so they can be shared. Then each machine could have its own config.xml which referred to the shared resources using the correct local path. I've tried to avoid making big changes like this in micro version updates, so I'd probably prefer to leave that until 2.20, which probably won't happen for a while.

That being said, I can't think of a reason not to allow <CinemasFile>foo.sqlite3</CinemasFile> to refer to a file at a position relative to config.xml.

[IoannisSyrogiannis]

Yes. I wouldn't expect such kind of a change to come from one day to another. That's why I was wondering if there is a workaround. But -in the rare occasions that it makes sense- it would make things easier when sharing different devices, or collaborating. Sharing different devices is more common, same as sharing resources is (encode servers etc.).