Open team dashboard in 'ro' and exit deletes dashlock.txt
Brought to you by:
ken_raisor,
tuma
Menu
▾
▴
#194 Open team dashboard in 'ro' and exit deletes dashlock.txt
We found that if one user (userA) has the Team Dashboard data open (and has the dashlock.txt file), and a second user (userB) tries to open the same Team Dashboard data, they correctly get a message saying that the data is locked (from the dashlock.txt), and the option to open the data in 'read-only' mode. Which works fine. However, when userB exits, he deletes userA's dashlock.txt file. This effectively removes userA's lock, and so the second time userB runs (or another user runs), the lock get's stolen.
Note, all of this is assuming that permissions are set such that all users are in the same group and all files have read/write allowed to the group, which is necessary for this scheme of sharing the team data/editing responsibilities to work anyway.
Seems that on exit, the code which deletes the lock isn't check it see if it is the owner, hopefully not hard to fix.
The code which creates these lock files works with the operating system to place an exclusive lock on the file in question. When UserA is holding this native lock, the operating system should not allow UserB to delete it. If the deletion is occurring as you describe, the operating system isn't managing the native lock correctly.
What operating system are you using? Is it a Unix variant? If so, the mount command may give you control over the enforcement of native locks on the mounted directory, and you may have these options set incorrectly. You might want to investigate that, because if the options are set incorrectly, there is no telling what types of locking problems you might see.
Nevertheless, I have written a one-line patch for you to test. I have added an additional check to the shutdown sequence, so the code won't rely on the operating system to enforce the deletion restrictions as described above. Could you download the following build, and let me know if it resolves the problem you are seeing?
http://www.processdash.com/download_mec/pdashBeta
Please let me know if this resolves the problem you've described. But once again, even if it does resolve your problem, if you are on a Unix/Linux/Mac system I would recommend that you investigate whether file locks are configured correctly on your mount point - because if they aren't, I can't provide any guarantees that locking will work at all.
Hi,
Ok, yes, with your patch, we are now seeing the same behavior we see with the 'WBS lock' as you described in the thread at https://sourceforge.net/projects/processdash/forums/forum/30753/topic/4622780. That is, it doesn't seem to be deleting the lock when I exit from read-only mode, but it does seem to be writing into the lock file sometimes (couldn't consistenly reproduce), and therefore getting things into a confused state.
To answer your questions, we are all using RedHat 5.5 Linux in a corporate environment. The mount options for nfs (enforced by IT) are all the same for everybody: rw,noacl,intr
If there is another option we should be using, I can try and do a test. I don't know of any other mount nfs options other than 'nolock' which explicitly says to not do locks (and we don't have set).
Anyway, my experience (we deploy a bunch of applications that rely on shared data directories to corporate customers on Unix variants who are mostly using NFS) is that you can't rely on this type of file locking at all, and that the general solution is just file/application based. Create a lock file (as you do), but rely on the contents to tell you if you are allowed to edit, rather than a lock bit. But as I said, I'm happy to experiment if there is a better way.
Thanks for all of the support and help.
Thank you very much for speaking with me on the phone yesterday. I would like to record some of the details from our conversation, so that others who read this thread later can benefit from the recommendations.
Based on the behavior you are describing, it is safe to say that file locks are not being honored correctly/consistently on the NFS shared directories that you are using.
A Google search of "NFS file locking" seems to suggest that this is not an uncommon problem with NFS. If your client settings are correct, it seems possible that a configuration problem might exist on the server (for example, the lock daemon might not be running). Unfortunately, I do not have a background in system administration for RedHat or NFS, so I can't immediately recommend a solution.
You might have better success if you use a Samba share instead. I have worked with teams that successfully use a Windows server for the files, and connect from Linux over SMB. The file locking behaviors worked correctly in that deployment scenario. If you don't have a Windows server, a Linux Samba server may also work well - but of course, that Samba server will need to have the correct file locking configuration. (For example, I know from experience that Mac OS servers can share files over Samba but do NOT honor file locks correctly, and must be avoided.)
Moving forward, my ultimate solution to this problem is the Process Dashboard Enterprise Server. It stores data in a relational database and does not use shared network directories. As a result, it can avoid problems like the one you're having with your NFS configuration.