Bug report #14378

Mapinfo Tables cannot be opened simultaneously in QGIS > 2.8.3 and MapInfo

Added by James O'Connor about 8 years ago. Updated almost 8 years ago.

Status:Closed
Priority:Severe/Regression
Assignee:-
Category:Data Provider/OGR
Affected QGIS version:master Regression?:No
Operating System:Windows Easy fix?:No
Pull Request or Patch supplied:No Resolution:fixed/implemented
Crashes QGIS or corrupts data:No Copied to github as #:22360

Description

In the latest dev builds for QGIS that allow editing of MapInfo tables I have noticed that if a table is open in QGIS the same table is unable to be opened simultaneously in MapInfo. This does not seem to be an issue for other QGIS sessions only MapInfo. This will cause problems in environments where there are a mixture of MapInfo and QGIS users all using common MapInfo tables.

History

#1 Updated by Matthias Kuhn about 8 years ago

  • Category changed from GDAL Tools to Data Provider/OGR
  • Status changed from Open to Feedback

Is it possible to open a file in multiple MapInfo sessions?

#2 Updated by Bo Victor Thomsen about 8 years ago

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.

#3 Updated by Alain FERRATON about 8 years ago

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.

#4 Updated by Jukka Rahkonen about 8 years ago

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.

#5 Updated by Alain FERRATON almost 8 years ago

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.

#6 Updated by Frank Olieu almost 8 years ago

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...

#7 Updated by Hans Christian Haase almost 8 years ago

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.

#8 Updated by Giovanni Manghi almost 8 years ago

  • Subject changed from Mapinfo Tables cannot be opened simultaneously in QGIS and MapInfo to Mapinfo Tables cannot be opened simultaneously in QGIS > 2.8.3 and MapInfo
  • Priority changed from High to Severe/Regression

tagging this as a regression.

#9 Updated by Jürgen Fischer almost 8 years ago

Giovanni Manghi wrote:

tagging this as a regression.

doesn't dc18b5b already fix this?

#10 Updated by Giovanni Manghi almost 8 years ago

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.

#11 Updated by Frank Olieu almost 8 years ago

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...

#12 Updated by Frank Olieu almost 8 years ago

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?

#13 Updated by Giovanni Manghi almost 8 years ago

  • Status changed from Feedback to Closed
  • Resolution set to fixed/implemented

I'm not completely familiar with the release cycle: Are some kind of backports to be expected?

yes, anyway better ask also in the commit page.

#14 Updated by Jürgen Fischer almost 8 years ago

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.

#15 Updated by Frank Olieu almost 8 years ago

Giovanni Manghi wrote:

yes, anyway better ask also in the commit page.

Done! Thank you.

#16 Updated by Frank Olieu almost 8 years ago

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.

#17 Updated by Even Rouault almost 8 years ago

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

#18 Updated by Jürgen Fischer almost 8 years ago

Backported to 2.14 in 52f3ca6

Also available in: Atom PDF