Opened 16 years ago
Last modified 6 years ago
#446 new enhancement
put user and machine name into .gislock file
Reported by: | benducke | Owned by: | |
---|---|---|---|
Priority: | minor | Milestone: | 7.6.2 |
Component: | LibGIS | Version: | svn-trunk |
Keywords: | locking, .gislock | Cc: | |
CPU: | Unspecified | Platform: | All |
Description
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(?).
Change History (14)
comment:1 by , 16 years ago
comment:2 by , 16 years ago
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.
comment:3 by , 16 years ago
Milestone: | 6.4.0 → 7.0.0 |
---|
comment:5 by , 11 years ago
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?
comment:6 by , 10 years ago
Let's get it implemented now if we want to see it in GRASS 7... the last beta is being prepared.
comment:7 by , 9 years ago
Milestone: | 7.0.0 → 7.0.5 |
---|
comment:8 by , 8 years ago
Milestone: | 7.0.5 → 7.3.0 |
---|
comment:11 by , 7 years ago
Milestone: | 7.4.1 → 7.4.2 |
---|
comment:12 by , 6 years ago
Milestone: | 7.4.2 → 7.6.0 |
---|
All enhancement tickets should be assigned to 7.6 milestone.
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