Opened 5 years ago

Closed 2 months ago

#2685 closed enhancement (duplicate)

Add ignore lock flag to grass command

Reported by: wenzeslaus Owned by: grass-dev@…
Priority: normal Milestone: 8.0.0
Component: Startup Version: svn-trunk
Keywords: init, grass.py, CLI, exec Cc:
CPU: Unspecified Platform: Unspecified

Description

In grass.py we have -f flag to force removal of lock but to read only commands (list maps in Lacation or Mapset or get region from another Mapset) there is no need for removal, more precisely, it would be wrong. The right thing to do is to just ignore that the lock is there. It's up to the caller that only read only modules are called. Surely this can be used for parallel processing as well when same rules are applied as would be applied to parallel processing within GRASS session.

Current grass71 --help:

  -f    force removal of .gislock if exists (use with care!). Only with -text flag

Proposed grass71 --help:

  -f    force removal of .gislock if exists (use with care!)
          Only with -text and --exec flags
  -i    ignore presence of .gislock if exists (use with care!)
          Only with -text and --exec flags. Suitable for read only modules.

Change History (12)

comment:1 Changed 5 years ago by mlennert

Wouldn't this mean that every module has to check whether there is a .gislock ?

You can always create another mapset and read whatever you need from there, so I don't understand the need for a read-only access to a particular mapset.

Sounds like a dangerous path to me.

Moritz

comment:2 in reply to:  1 Changed 5 years ago by wenzeslaus

Replying to mlennert:

Wouldn't this mean that every module has to check whether there is a .gislock ?

No. There would be no check. It is up to the caller. Perhaps the note about read-only shouldn't be in the parameter explanation, just in a detailed documentation. Read-only is suggestion or use case here, not something enforced.

You can always create another mapset and read whatever you need from there, so I don't understand the need for a read-only access to a particular mapset.

There is several ways around it. g.list can just read from other Mapsets and g.mapsets can give you an (actual) read-only access to other Mapset.

However, the use case here is emulate what you get when you set up GRASS environment/session manually ("without starting explicitly"). You have no checks at all and you can still access and do anything. Purpose of suggested (-i) flag is to skip the lock check but still benefit from other things grass.py is doing like taking care of "gisrc" file.

Sounds like a dangerous path to me.

-f is also dangerous, and on MS Windows or when you set up GRASS environment/session manually ("without starting explicitly") there are no checks at all, so I don't think it is more dangerous than anything we have now. On the contrary, with -i you would explicitly ask for this dangerous behavior which is safer then getting it unexpectedly (in an implicit way) with manual setup of the environment or on MS Windows in general.

These things are what I considered but I might have missed something.

comment:3 Changed 4 years ago by neteler

Milestone: 7.1.07.2.0

Milestone renamed

comment:4 Changed 4 years ago by neteler

Milestone: 7.2.07.2.1

Ticket retargeted after milestone closed

comment:5 Changed 3 years ago by martinl

Milestone: 7.2.17.2.2

comment:6 Changed 3 years ago by martinl

Milestone: 7.2.27.4.0

All enhancement tickets should be assigned to 7.4 milestone.

comment:7 Changed 2 years ago by neteler

Milestone: 7.4.07.4.1

Ticket retargeted after milestone closed

comment:8 Changed 2 years ago by neteler

Milestone: 7.4.17.4.2

comment:9 Changed 22 months ago by martinl

Milestone: 7.4.27.6.0

All enhancement tickets should be assigned to 7.6 milestone.

comment:10 Changed 18 months ago by martinl

Milestone: 7.6.07.6.1

Ticket retargeted after milestone closed

comment:11 Changed 15 months ago by martinl

Milestone: 7.6.17.6.2

Ticket retargeted after milestone closed

comment:12 Changed 2 months ago by wenzeslaus

Keywords: exec added
Milestone: 7.6.28.0.0
Resolution: duplicate
Status: newclosed

Closing this as duplicate in favor of GitHub: PR:602 (Optionally disable mapset locking and cleaning) which addresses this in a better way where both (all) process need to participate in the disabling of the locking mechanism and more importantly, it addresses the issue of deleting the other session's temporary files while cleaning the mapset at the beginning or the end.

Note: See TracTickets for help on using tickets.