QGIS » QGIS Application

Yes, You can have a tab file open by multiple MapInfo session, ie. the tab file resides on a network drive and you have several MapInfo users working with the same file.
However only one of the users can edit the tab file at a time. When a MapInfo user starts editing a tab, the MapInfo program will create several files in the same directory as the original tab file. The presence of these files will block other users trying to start an editing session on the same file.

Not only related to the TAB file. Same for SHP for example.
QGIS under Windows puts a read lock from opening a file.
it should be done only when switching to edit mode.

If several users had opened the same shapefile in read-only mode and then one user is switching into edit mode, what should happen? I think that files are never good for shared use and that's one reason why databases exist.

For files currently QGIS ignores read-only locks. The last writer wins.
This allows at least read access for multiple users QGIS.
But this is not the case of MapInfo software that uses locks.

I can confirm the lock problem, but not with all QGIS versions:

• We got aware of the issue with 2.8.9 LTR.
• Newer versions, like 2.14 and 2.15 Nightly also have the issue.
• Trying older releases, we found out that up to 2.8.3, we had no problem at all with using MapInfo concurrently with QGIS.

So for the time being, we´re sticking with 2.8.3...

I have the same problem. This makes practically impossible to use QGIS in a multi-user/platform environment.
And using and deprecated version is far from ideal.

Giovanni Manghi wrote:

tagging this as a regression.

doesn't dc18b5b already fix this?

Jürgen Fischer wrote:

Giovanni Manghi wrote:

tagging this as a regression.

doesn't dc18b5b already fix this?

I don't have Mapinfo and so cannot test.
Can anyone please try QGIS master and report back? Thanks.

Giovanni Manghi wrote:

I don't have Mapinfo and so cannot test.
Can anyone please try QGIS master and report back? Thanks.

I'm installing the latest nightly build (2.15.0-69) from OSGeo4W and I'll let you know.
But as I wrote before, I've already tested 2.15.0-18 (weekly) and the issue was still there...

I installed QGIS master through the OSGeo4W package manager. This gave me 2.15.0-69. Our testing indicates that the issue indeed seems resolved in this build.
We can confirm that 2.15.0.18 still fails, so the patch must have been applied after that.
I also (re)installed 2.14 through OSGeo4W setup (2.14.2-1 -> 2.14.3-1), and it still fails too.

We can probably say that this bug is closed, but it doesn't help with Latest (2.14.x) and LTR (2.8.x)...
I'm not completely familiar with the release cycle: is some kind of backport to be expected?

Frank Olieu wrote:

I installed QGIS master through the OSGeo4W package manager. This gave me 2.15.0-69. Our testing indicates that the issue indeed seems resolved in this build.
We can confirm that 2.15.0.18 still fails, so the patch must have been applied after that.

Yes, better include the SHA from the title bar (or "QGIS code revision" from the about box for release builds) instead of OSGeo4W or weekly package numbers. the weekly installer 2.15.0-18 is from May 2nd, dc18b5b was committed on May 4th. So it can't have this change.

I also (re)installed 2.14 through OSGeo4W setup (2.14.2-1 -> 2.14.3-1), and it still fails too.

We can probably say that this bug is closed, but it doesn't help with Latest (2.14.x) and LTR (2.8.x)...
I'm not completely familiar with the release cycle: is some kind of backport to be expected?

Yes. But the commit wasn't automatically linked to this ticket and so there was no confirmation that it actually helped. This might have been overlooked.

2.8.x will probably not receive this - as it's the old LTR. The current LTR is 2.14 and will replace 2.8.x in the LTR repositories when 2.16 is released.

Giovanni Manghi wrote:

yes, anyway better ask also in the commit page.

Done! Thank you.

Jürgen Fischer wrote:

Yes, better include the SHA from the title bar (or "QGIS code revision" from the about box for release builds) instead of OSGeo4W or weekly package numbers. the weekly installer 2.15.0-18 is from May 2nd, dc18b5b was committed on May 4th. So it can't have this change.

Thank you for pointing this out.

(Note: Pull request where the fix was submitted: https://github.com/qgis/QGIS/pull/3034)

Backported to 2.14 in 52f3ca6