Bug report #808

fails to create ".gislock" on Windows

Added by Maciej Sieczka - almost 13 years ago. Updated about 11 years ago.

Status:Closed
Priority:Low
Assignee:Marco Pasetti -
Category:GRASS
Affected QGIS version: Regression?:No
Operating System:Windows Easy fix?:No
Pull Request or Patch supplied: Resolution:fixed
Crashes QGIS or corrupts data: Copied to github as #:10867

Description

QGIS 0.9 on Windows (XP, 2000) fails to create the ".gislock" file in the opened mapset. Then it complains closing mapset:

Cannot close mapset. Cannot remove mapset lock: d:/grassdata/spearfish60/user1/.gislock

I can't reproduce this behaviour in QGIS on Ubuntu Dapper, using 0.9.1 SVN 7389.

Associated revisions

Revision 9f02d0dd
Added by Jürgen Fischer about 12 years ago

workaround for non-functional lock.exe on windows (fixes #808)

git-svn-id: http://svn.osgeo.org/qgis/trunk/[email protected] c8812cc2-4d05-0410-92ff-de0c093fc19c

Revision 56b5bc28
Added by Jürgen Fischer about 12 years ago

workaround for non-functional lock.exe on windows (fixes #808)

git-svn-id: http://svn.osgeo.org/qgis/[email protected] c8812cc2-4d05-0410-92ff-de0c093fc19c

Revision 97808fb5
Added by Jürgen Fischer about 12 years ago

unload plugins on quit (fixes #808)

git-svn-id: http://svn.osgeo.org/qgis/trunk/[email protected] c8812cc2-4d05-0410-92ff-de0c093fc19c

Revision 299c5357
Added by Jürgen Fischer about 12 years ago

unload plugins on quit (fixes #808)

git-svn-id: http://svn.osgeo.org/qgis/[email protected] c8812cc2-4d05-0410-92ff-de0c093fc19c

History

#1 Updated by Markus Neteler over 12 years ago

Should this be reported to GRASS-trac?

#2 Updated by Maciej Sieczka - over 12 years ago

Markus

I don't know. Why do you think this a GRASS issue, not QGIS?

#3 Updated by Markus Neteler over 12 years ago

OK. Could you enable debugging output? Maybe then we see where it originates from.

Markus

#4 Updated by Maciej Sieczka - over 12 years ago

Replying to [comment:4 neteler]:

OK. Could you enable debugging output? Maybe then we see where it originates from.

I'm affraid I can't. That was on Windows. I'm not using Windows too often. Works OK on Ubuntu.

#5 Updated by Marco Pasetti - over 12 years ago

Locking is not permitted on windows. This is a WinGRASS problem.

#6 Updated by Maciej Sieczka - about 12 years ago

Still applies under WINE 1.0.0 configured to emulate Win XP, on amd64 Debian testing, using Marco's "QGIS 0.11.0 for Windows pre-release testing installer".

I'm reporting the bug in GRASS Trac: http://trac.osgeo.org/grass/ticket/226.

#7 Updated by Marco Pasetti - about 12 years ago

Replying to [comment:8 msieczka]:

Still applies under WINE 1.0.0 configured to emulate Win XP, on amd64 Debian testing, using Marco's "QGIS 0.11.0 for Windows pre-release testing installer".

I'm reporting the bug in GRASS Trac: http://trac.osgeo.org/grass/ticket/226.

I think that the bug could be fixed creating an empty .gislock file in the location's directory every time that location is opened.

Marco

#8 Updated by Marco Pasetti - about 12 years ago

Replying to [comment:9 marcopx]:

Replying to [comment:8 msieczka]:

Still applies under WINE 1.0.0 configured to emulate Win XP, on amd64 Debian testing, using Marco's "QGIS 0.11.0 for Windows pre-release testing installer".

I'm reporting the bug in GRASS Trac: http://trac.osgeo.org/grass/ticket/226.

I think that the bug could be fixed creating an empty .gislock file in the location's directory every time that location is opened.

Marco

Jurgen,

so you think that we could do that in one of the src\\qgis-dev\\src\\plugins\\grass\\ cpp files?

Marco

#9 Updated by Jürgen Fischer about 12 years ago

  • Status changed from Open to Closed
  • Resolution set to fixed

workaround in 56b5bc28 (SVN r9246): QGIS creates the lockfile by itself.

#10 Updated by Jürgen Fischer about 12 years ago

looks like Markus originally wanted to track this...

#11 Updated by Marco Pasetti - about 12 years ago

  • Status changed from Closed to Feedback
  • Resolution deleted (fixed)

Replying to [comment:11 jef]:

workaround in 56b5bc28 (SVN r9246): QGIS creates the lockfile by itself.

good, it works... but it generates another problem! if I close QGIS without closing the mapset the .gislock file is not deleted! thus, when I re-start QGIS and want to open the mapset, this is blocked because its .gislock file has not been deleted!

since locking is actually unsupported on windiws, we could just pass the "already exist check" on .gislock and just allow the user to open the mapset; what do you think?

Marco

#12 Updated by Jürgen Fischer about 12 years ago

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

Replying to [comment:13 marcopx]:

Replying to [comment:11 jef]:
since locking is actually unsupported on windiws, we could just pass the "already exist check" on .gislock and just allow the user to open the mapset; what do you think?

That wasn't a windows problem. All plugins were not unloaded cleanly using their unload() method and therefore the mapset wasn't unlocked on all plattforms. Fixed in 299c5357 (SVN r9250)

#13 Updated by Marco Pasetti - about 12 years ago

Replying to [comment:14 jef]:

Replying to [comment:13 marcopx]:

Replying to [comment:11 jef]:
since locking is actually unsupported on windiws, we could just pass the "already exist check" on .gislock and just allow the user to open the mapset; what do you think?

That wasn't a windows problem. All plugins were not unloaded cleanly using their unload() method and therefore the mapset wasn't unlocked on all plattforms. Fixed in 299c5357 (SVN r9250)

cool! you did a great job ;) congrats
Marco

#14 Updated by Anonymous about 11 years ago

Milestone Version 1.0.0 deleted

Also available in: Atom PDF