put user and machine name into .gislock file

[benducke]

If a .gislock file gets created for a user, then it might be a good idea to store that user's current login name and machine name in the file. That way, external GUIs that encounter a lockfile when trying to log a user into a mapset will be able to output a more specific error message, including the lockfile creator's identity, giving the user a better clue as to whether the lockfile can be safely deleted or not.

Not sure what version of GRASS this could go into, but it seems to me it would not affect any of the current functionality(?).

[hamish]

there is a good chance that the lock file was created by you on the local machine. so perhaps it would be good to also log the lock file creation time as an indicator of how stale the file is. (or check file creation time if that is portable)

I am a bit unsure if this should really be targeted for grass 6.4 or only go into grass 7. I understand waiting for grass 7 is unpleasant for QGIS, but we must protect the stable branch.... if for grass64 we must ensure backwards compatibility with other grass 6.[0-3].

Hamish

[glynn]

Replying to benducke:

If a .gislock file gets created for a user, then it might be a good idea to store that user's current login name and machine name in the file. That way, external GUIs that encounter a lockfile when trying to log a user into a mapset will be able to output a more specific error message, including the lockfile creator's identity, giving the user a better clue as to whether the lockfile can be safely deleted or not.

The machine name should go into the file. At present, etc/lock reads the PID and checks whether the process is still running. Obviously, this only works if the creator process is running on the same system as the checking process.

Also, the current format is an "int" in the platform's native format, so you can't even report the PID correctly if it was written using a different byte order (or sizeof(int)).

lib/init/lock.c should at least check that PID is positive before checking for existence.

Not sure what version of GRASS this could go into, but it seems to me it would not affect any of the current functionality(?).

It can't go into 6.x, as existing versions of GRASS won't understand the new format, and in the case where the database is shared via NFS, you can't assume that all systems are using the same version of GRASS.

[neteler]

Did we miss this train again for GRASS 7.x?

[wenzeslaus]

According to ​semantic versioning, pre-release versions have a lower precedence than the associated normal version. A pre-release version indicates that the version is unstable and might not satisfy the intended compatibility requirements as denoted by its associated normal version, And we are not yet released 7.x. So, if we are still adding minor features to release branch, the rules allows us to add this if it is not too dangerous (I cannot tell) or it is very important.

Is somebody able to implement this?

[neteler]

Let's get it implemented now if we want to see it in GRASS 7... the last beta is being prepared.

[martinl]

Milestone renamed

[neteler]

Ticket retargeted after milestone closed

[martinl]

All enhancement tickets should be assigned to 7.6 milestone.

[martinl]

Ticket retargeted after milestone closed

[martinl]

Ticket retargeted after milestone closed