Bug report #808
fails to create ".gislock" on Windows
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
workaround for non-functional lock.exe on windows (fixes #808)
git-svn-id: http://svn.osgeo.org/qgis/trunk/qgis@9245 c8812cc2-4d05-0410-92ff-de0c093fc19c
workaround for non-functional lock.exe on windows (fixes #808)
git-svn-id: http://svn.osgeo.org/qgis/trunk@9245 c8812cc2-4d05-0410-92ff-de0c093fc19c
unload plugins on quit (fixes #808)
git-svn-id: http://svn.osgeo.org/qgis/trunk/qgis@9249 c8812cc2-4d05-0410-92ff-de0c093fc19c
unload plugins on quit (fixes #808)
git-svn-id: http://svn.osgeo.org/qgis/trunk@9249 c8812cc2-4d05-0410-92ff-de0c093fc19c
History
#1 Updated by Markus Neteler almost 17 years ago
Should this be reported to GRASS-trac?
#2 Updated by Maciej Sieczka - almost 17 years ago
Markus
I don't know. Why do you think this a GRASS issue, not QGIS?
#3 Updated by Markus Neteler almost 17 years ago
OK. Could you enable debugging output? Maybe then we see where it originates from.
Markus
#4 Updated by Maciej Sieczka - almost 17 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 16 years ago
Locking is not permitted on windows. This is a WinGRASS problem.
#6 Updated by Maciej Sieczka - over 16 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 - over 16 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 - over 16 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 16 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 16 years ago
looks like Markus originally wanted to track this...
#11 Updated by Marco Pasetti - about 16 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 16 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 16 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 over 15 years ago
Milestone Version 1.0.0 deleted