[NETBEANS-4962] Adding ability to disable hard-locking files using lock files.

[lahodaj]

NetBeans FileSystems have a notion of file locking. And, when two (or more) files with the same name, but different paths, are locked, there are lock file written next to the files on the OS file system. Investigating this, it seems the reason is to detect multiple lock for the same "real" file available under multiple paths. That may happen e.g. by using symbolic links, mount --bind or network files. Materializing the lock files on the OS file system should allow to detect multiple lock attempts for the same "real" file.

Not sure how important this is, but I don't recall any complaints about this while running a NB platform app or NB-based IDE, so keeping the behavior for these usecases would make sense to me. Note the NB FileSystems don't model the lock files at all, so they are invisible when using the NB FS, and hence mostly invisible inside the IDE.

But, in the context of an VS Code extension, the lock files are problematic. It is fairly easy to produce them, and they are visible to the user. So, preferably, the lock files should not be created in the extension(s). Please see:
#4962

So, my proposal herein is to abstract the hard-lock creation, and create either the lock files, or keep hard-locks in memory only. Where NB would use the former, and the VS Code extension(s) the latter.

This means the VS Code extension(s) won't be able to detect some double-locking of the same file using different paths, but I think that is OK/acceptable. I've used Path.toRealPath(), so symbolic links are resolved, and hence double-locking across sym-linked directories should still work. We'll see how that goes, if this proves to be too resource intensive, we might need to drop that. Double-locking a file that is mounted multiple times won't be detected.

For the record, I am not a real expert on NB FS, and so this patch is fairly dangerous. It may need some baking time on master, at least for NB IDE.

[neilcsmith-net]

For the record, I am not a real expert on NB FS, and so this patch is fairly dangerous. It may need some baking time on master, at least for NB IDE.

This makes me inclined to bump the milestone early! 😄