File locking supported on all platforms?

[Stefan Reich]

Thanks to Peter's suggestion, here's my working code for a crash-safe
FileBasedLock in my own fancy Java dialect (JavaX).

http://code.botcompany.de/1029788
(Transpiled Java version:
http://code.botcompany.de:8081/tb-int/get-transpiled.php?id=1029788&raw=1)

I'm happy with this result. I actually don't use NFS and probably never
will, but it's still a good feeling knowing even this case will be
supported. Unless the clocks on your machines are badly out of sync. Yes I
worry too much.

Greetings
Stefan




On Mon, 14 Sep 2020 at 14:27, Stefan Reich <
stefan.reich.maker.of.eye at googlemail.com> wrote:

> Thanks Peter, that sounds pretty cool actually.
>
> Stefan
>
> On Mon, 14 Sep 2020 at 11:58, Peter Levart <peter.levart at gmail.com> wrote:
>
>> Hi Stefan,
>>
>> You can always use the "create file exclusively" feature that should work
>> on any POSIX compliant filesystem (NFS included):
>>
>> Files.createFile(path)
>>
>> ...you could implement an "exclusive lock" mechanism with this by
>> creating and then updating a lock file periodically so that its "last
>> modified" time is kept recent. Unlock would just remove the file. Observing
>> the file with expired timestamp will give you permission to remove it even
>> if you are not the lock owner.
>>
>> Regards, Peter
>>
>> On 7/11/20 12:13 PM, Stefan Reich wrote:
>>
>> Hmm that's what I feared. So to be really sure I should do an actual
>> test. Maybe I can get away with doing two locks on the same file within one
>> JVM for testing the feature? I should try that.
>>
>> Thanks
>>
>> On Sat, 11 Jul 2020 at 12:10, Jonas Konrad <me at yawk.at> wrote:
>>
>>> I think it should just fail silently / without error, that's what fcntl
>>> does at least. I'm not sure if there's a good way to determine whether
>>> locking will actually work.
>>>
>>> - Jonas
>>>
>>> On 7/11/20 11:47 AM, Stefan Reich wrote:
>>> > Hi Jonas,
>>> >
>>> > what would happen if I try to lock a file on these platforms? Can I
>>> > reliably detect this case? That would already help a lot.
>>> >
>>> > The use case is ensuring a database's consistency which I now do over
>>> a
>>> > socket protocol, but file locks would be faster and more reliable.
>>> >
>>> > Stefan
>>> >
>>> > On Sat, 11 Jul 2020 at 11:45, Jonas Konrad <me at yawk.at
>>> > <mailto:me at yawk.at>> wrote:
>>> >
>>> >     Hey,
>>> >
>>> >     Some file systems on Linux, eg old NFS, do not support locking at
>>> all.
>>> >
>>> >     - Jonas
>>> >
>>> >     On 7/11/20 11:36 AM, Stefan Reich wrote:
>>> >      > Hi,
>>> >      >
>>> >      > a quick question regarding file locks in Java. I seem to
>>> remember
>>> >      > reading somewhere that this feature isn't guaranteed to work on
>>> all
>>> >      > platforms. However, I can now find no mention of that e.g. here
>>> >      >
>>> >     <
>>> https://docs.oracle.com/javase/7/docs/api/java/nio/channels/FileLock.html
>>> >.
>>> >      >
>>> >      > The page does list that numerous special assumptions may fail,
>>> for
>>> >      > example that programs which /don't/ lock a file are prevented
>>> from
>>> >      > changing it when it is locked by another program.
>>> >      >
>>> >      > However, I only care about the basic feature, namely that one
>>> >     local file
>>> >      > cannot be locked by two Java programs at once and will cause one
>>> >     of them
>>> >      > to throw an exception.
>>> >      >
>>> >      > Is this guaranteed to work everywhere?
>>> >      >
>>> >      > Many greetings
>>> >      > Stefan
>>> >      >
>>> >      > --
>>> >      > Stefan Reich
>>> >      > BotCompany.de // Java-based operating systems
>>> >
>>> >
>>> >
>>> > --
>>> > Stefan Reich
>>> > BotCompany.de // Java-based operating systems
>>>
>>
>>
>> --
>> Stefan Reich
>> BotCompany.de // Java-based operating systems
>>
>>
>>
>
> --
> Stefan Reich
> BotCompany.de // Java-based operating systems
>


-- 
Stefan Reich
BotCompany.de // Java-based operating systems
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/nio-dev/attachments/20200917/a4ef91cd/attachment.htm>