Turn on file locking per default
|Target version:||Candidate for next bugfix release|
According to the CookBook, "the only guarantee is that the file will not be clobbered since GMT uses advisory file locking." But file locking is not enabled per default. Shouldn't we enable it?
#2 Updated by Remko over 4 years ago
Yes, I do remember the issue. File locking produced a problem for people using NFS mounted disks. Below is one user comment that I happen to have saved. But I remember we had more like it. Hence, I agree it is better not to enforce file locking.
We have a computer cluster with a large disk array attached. User will often put their GMT files on the disk array and not on their home disk on the cluster. We found that we could execute gmt commands if the files were moved over to the home directory or if from our home directory we executed the files. Example: cd /bigdisk1/ourhome/file.gmt However, if we move to the array disk and try to execute the file, we get a F-WRLCK error. Example: cd /bigdisk1/ourhome grdcut: Error returned by fcntl [F_WRLCK] Is this normal?
#3 Updated by Florian over 4 years ago
Well unfortunately we don't know the exact error with which
fcntl (fd, F_SETLKW, lock) (gmt_init.c:6075) returns. Remko, can you ask the guys to reproduce this? Would they be able to help us debug this problem? I've been using GMT with flock over NFS ever since and never had any issues reported before. I can rewrite the code to give us better error reporting.
Then I'd rather make file locking the default but let it be configurable via gmtset so that you don't have to recompile when you run into problems. How about that for a compromise?
#5 Updated by Florian over 4 years ago
- Status changed from Feedback to Closed
While file locking might not work reliably (POSIX fcntl is very buggy) there is no need to remove that code via ifdef/configure option. File locking works very well for our simplistic implementation. And if not, GMT just informs the user that the lock is not guaranteed and that he can continue at his own risk. Windows specific code was added. r12910 resolves this issue.