Odd Global .lockfile problem

[Silas Martinez]

Laura Brody wrote:
....
> 
>     Your lockfile issues appear to be self-inflicted.
> 
>     What you are doing is TOTALLY not recommended. Turn off
> this cron job, get everyone out of the system, delete all of
> the lockfiles (I will happily bet some serious money that more
> than half of them are corrupted right now) and then let
> everyone get back to work. Now, leave the lockfiles alone
> unless they appear to be corrupted! (see above for the
> proper clearing method). Also, instruct your users that
> they should never use Ctrl-\ to exit out of filePro and/or
> set the env var PFQUIT=OFF to disable the Ctrl-/ (only
> for filePro, not for the system).
> 
>     Have a great day, and "stop doing that"! <G>

Thanks for the input, Laura. Here is the thing - users are getting 
locked out of files that have an empty .lockfile in them. It doesn't 
appear to be a simple permissions issue - I've verified permissions, and 
had filepro do the same. I've verified that it isn't a case of someone 
else using the file - there are no users on the system except myself, as 
root, checking the issue (not running any filepro apps), and the single 
user experiencing the problem which I had logged in to troubleshoot. I 
verified that there were no stale logins, `ps aux` revealed only the 
expected user's single session.

The users are aware of the 'how not to log out' issues, and are quite 
careful to not just randomly exit out of the ssh session, instead 'x'ing 
out to a shell prompt, and then using ctrl+d or typing exit.

I've disabled the cron job again, and will check the contents of any and 
all lockfiles again - but I'll note that I had checked this before, and 
indeed .lockfile for the file the user was unsuccessfully trying to 
access was empty.

I feel like a filepro noob all over again .... *sigh* Then again, it has 
been nearly a year since I last had to administer any filepro based system.

Thanks again,

Silas Martinez