Software: Apache/2.0.54 (Unix) mod_perl/1.99_09 Perl/v5.8.0 mod_ssl/2.0.54 OpenSSL/0.9.7l DAV/2 FrontPage/5.0.2.2635 PHP/4.4.0 mod_gzip/2.0.26.1a 

uname -a: Linux snow.he.net 4.4.276-v2-mono-1 #1 SMP Wed Jul 21 11:21:17 PDT 2021 i686 

uid=99(nobody) gid=98(nobody) groups=98(nobody) 

Safe-mode: OFF (not secure)

/usr/lib/jed/doc/txt/   drwxr-xr-x
Free 318.38 GB of 458.09 GB (69.5%)
                            Encoder    Tools    Proc.    FTP brute    Sec.    SQL    PHP-code    Update    Feedback    Self remove    Logout    

Viewing file:     filelock.txt (1.08 KB)      -rw-r--r--

On Unix systems, JED locks files in a way that is consistent with
Emacs, which is also consistent with Interleaf.  It made no sense to
implement a different incompatible locking system because that would
render it useless when interacting with other programs.

Whenever a buffer that is attached to a file gets modified, JED will
attempt to lock the file.  When the buffer is no longer modified (via
getting saved to disk or changes discarded via undo), JED will unlock
the file.

The lock is made by creating a symbolic link in the file's directory
with a name that is derived by prefixing the buffer file's name with
`.#'.  The value of the link is given by USER@HOST.PID.  If there is
already a lock but owned by another process, then JED will prompt the
user for one of the following actions: 

     steal the lock
     ignore the lock and proceed anyway
     abort the operation

If the user elects to steal the lock, then the symbolic link will be
recreated with the value appropriate for the current process.  It is
probably best to abort the operation and contact the person who has
the file locked.