In POSIXy land, it would suffice to do a
That's neat, but it implies "unix" usage, and what about windows?
Very difficult, because Windows simply wasn't designed for multiple concurrent users. The problem is that in Windows, the analogous byte-range locks (
LockFileEx) are
enforced/
mandatory: the lock prevents access by any other process. Everywhere else, they're
co-operative/
advisory only, they don't affect any I/O operations.
The one "portable" approach limits file sizes to less than 2 GiB-1 bytes: use the byte at offset 2³¹-1 as a lock indicator, locking and examining the lock at that single byte only. Because the byte does not actually exist in the files (assuming editable files are shorter than that), whether the lock is mandatory (Windows) or advisory (Unix/POSIX) does not matter, as the byte won't ever be accessed. (Byte-range locks
can be placed at any offset in the file, regardless of whether the file is that long or whether a sparse file has data at that offset. The choice of 2 GiB-1 is not random: although irrelevant for current Samba and NFSv4, with any other shared filesystem it has the best chance of actually being supported, but as far above actual content in human-edited files as possible.)
In C and C++ code it is trivial,
#ifdef _WIN32 ...
#else ...
#endif selecting between Windows and POSIX/Unix. Similarly, in Python, one can at runtime use either
msvcrt or
fcntl module. In both cases you can easily wrap the functionality to an OS-specific source file, and make this cleanly, without much red tape at all.
In Java, byte-range locks are accessible via
FileLock, but I'm not sure if Java Runtimes correctly map it to LockFileEx/fcntl() byte-range locks.
I do not personally use Eclipse, but its documentation implies it uses rather wonky "file locking" schemes, including a file named
.lock in the project configuration directory, which is often read-only for unprivileged users, leading users to disable file locking in Eclipse. It all sounds utterly crazy to me. I do not believe those who developed Eclipse in the first place had worked on shared filesystems or multi-user environments before – or at least considered those irrelevant or an afterthought.