Ticket #1407 (closed enhancement: fixed)

Opened 22 months ago

Last modified 19 months ago

confusing error message after grass7 crash

Reported by: MilenaN Owned by: martinl
Priority: blocker Milestone: 6.4.2
Component: wxGUI Version: svn-trunk
Keywords: startup Cc: grass-dev@…
Platform: Unspecified CPU: Unspecified

Description

After crashed grass7 session grass complains about .gislock file. The message is unhelpful if the user doesn't know what to do. Please add an explanation for the needed step to fix the blocked grass installation.

Attachments

leftover_gislock.png Download (32.0 KB) - added by MilenaN 22 months ago.
.gislock file present but no idea how to continue
linux_gislock.png Download (14.2 KB) - added by neteler 22 months ago.
Crashed GRASS session on Linux
wxgui_gislock.png Download (16.6 KB) - added by martinl 22 months ago.
remove gislock?

Change History

Changed 22 months ago by MilenaN

.gislock file present but no idea how to continue

follow-up: ↓ 5   Changed 22 months ago by MilenaN

Checking with the file expolorer, the indicated file does not exist.

  Changed 22 months ago by martinl

  • keywords wingrass added
  • platform changed from All to Unspecified

I think it's related only to Windows...

Changed 22 months ago by neteler

Crashed GRASS session on Linux

  Changed 22 months ago by neteler

  • keywords wingrass removed

The problem is similar on Linux, see attachment.

Changed 22 months ago by martinl

remove gislock?

follow-ups: ↓ 8 ↓ 12   Changed 22 months ago by martinl

I have modified the dialog to allow remove gislock and continue (r47226) - see the attached screenshot. Would it help?

in reply to: ↑ 1   Changed 22 months ago by martinl

Replying to MilenaN:

Checking with the file expolorer, the indicated file does not exist.

this should only refer to wingrass...

  Changed 22 months ago by martinl

  • cc grass-dev@… added
  • owner changed from grass-dev@… to martinl
  • status changed from new to assigned

  Changed 22 months ago by martinl

  • keywords wxgui added

in reply to: ↑ 4 ; follow-up: ↓ 9   Changed 22 months ago by martinl

Replying to martinl:

I have modified the dialog to allow remove gislock and continue (r47226) - see the attached screenshot. Would it help?

Backported to devbr6 in r47246. Testing welcomed.

in reply to: ↑ 8 ; follow-up: ↓ 10   Changed 22 months ago by martinl

Replying to martinl:

Replying to martinl:

I have modified the dialog to allow remove gislock and continue (r47226) - see the attached screenshot. Would it help?

Backported to devbr6 in r47246. Testing welcomed.

Before closing the ticket, should it be also backported to relbr64?

in reply to: ↑ 9   Changed 21 months ago by martinl

  • status changed from assigned to closed
  • resolution set to fixed

Replying to martinl:

Replying to martinl:

Replying to martinl:

I have modified the dialog to allow remove gislock and continue (r47226) - see the attached screenshot. Would it help?

Backported to devbr6 in r47246. Testing welcomed.

Before closing the ticket, should it be also backported to relbr64?

Backported as r48257

  Changed 21 months ago by martinl

  • keywords startup added; wxgui removed
  • component changed from Startup to wxGUI

in reply to: ↑ 4 ; follow-up: ↓ 13   Changed 21 months ago by hamish

  • status changed from closed to reopened
  • resolution fixed deleted

Replying to martinl:

I have modified the dialog to allow remove gislock and continue (r47226) -

I would argue to make the warning a lot more dire and the functionality much harder to access.

the user is blocked from starting twice for a good reason, and it's for their own safety whether they realize it or not. Too many people are used to broken software and just click past "an error occurred -> ignore" without thinking about it.

since grass can crash too, or the power go out, etc, sure it's nice to allow recovery without filesystem hacks, but perhaps have it launch a second dialog saying "Are you sure? If you really are running another GRASS session doing this could corrupt your data. Have another look in the processor manager just to be sure.." or something like that.

Hamsih

in reply to: ↑ 12 ; follow-up: ↓ 14   Changed 20 months ago by martinl

  • priority changed from normal to blocker

Replying to hamish:

the user is blocked from starting twice for a good reason, and it's for their own safety whether they realize it or not. Too many people are used to broken software and just click past "an error occurred -> ignore" without thinking about it. since grass can crash too, or the power go out, etc, sure it's nice to allow recovery without filesystem hacks, but perhaps have it launch a second dialog saying "Are you sure? If you really are running another GRASS session doing this could corrupt your data. Have another look in the processor manager just to be sure.." or something like that.

Try r48565, backported to devbr in r48566 for testing. Is it better?

in reply to: ↑ 13   Changed 19 months ago by martinl

  • status changed from reopened to closed
  • resolution set to fixed

Replying to martinl:

Try r48565, backported to devbr in r48566 for testing. Is it better?

Backported to relbr64 in r49016

Note: See TracTickets for help on using tickets.