CER> Dos could lock for write or read an area of a file, for instance. And
CER> those are mandatory locks. This feature is needed for databases that
CER> run without a centralized daemon, but sharing the database file itself
CER> instead.

Linux does have posix locks from what I remember.

---------------
user <candycane> is generated from /dev/urandom

.... "42? 7 and a half million years and all you can come up with is 42?!"
___ MultiMail/Linux v0.52

On 24/08/2023 09:12, candycane wrote:
> CER> Dos could lock for write or read an area of a file, for instance. And
> CER> those are mandatory locks. This feature is needed for databases that
> CER> run without a centralized daemon, but sharing the database file itself
> CER> instead.
>
> Linux does have posix locks from what I remember.
>
Linux has and had many forms of file locking AFAICR. No one uses them,
because file locking is itself a very unpleasant way to handle multiuser
access to a shared resource.

I spent too many hours removing file locks on files set by PCs running
windows that users had switched off, or which had crashed, without
exiting the applications that set the locks.

OTOH databases were designed from the outset to have robust multiuser
access to shared resources.

So if that is a requirement, you simply tend to use a proper SQL style
database.

> ---------------
> user <candycane> is generated from /dev/urandom
>
> ... "42? 7 and a half million years and all you can come up with is 42?!"
> ___ MultiMail/Linux v0.52
>

--
Karl Marx said religion is the opium of the people.
But Marxism is the crack cocaine.

The Natural Philosopher <tnp@invalid.invalid> writes:
> On 24/08/2023 09:12, candycane wrote:
>>> Dos could lock for write or read an area of a file, for instance. And
>>> those are mandatory locks. This feature is needed for databases that
>>> run without a centralized daemon, but sharing the database file itself
>>> instead.
>> Linux does have posix locks from what I remember.
>>
> Linux has and had many forms of file locking AFAICR. No one uses them,
> because file locking is itself a very unpleasant way to handle
> multiuser access to a shared resource.

It has advisory file locking and plenty of things use that; it’s
mandatory locking that it’s (now) missing.

> I spent too many hours removing file locks on files set by PCs running
> windows that users had switched off, or which had crashed, without
> exiting the applications that set the locks.

Unfortunately even advisory locks can result in things getting stuck
(the fact that it’s advisory doesn’t help if the thing you want to make
progress honors the advisory lock).

> OTOH databases were designed from the outset to have robust multiuser
> access to shared resources.
>
> So if that is a requirement, you simply tend to use a proper SQL style
> database.

Right. Those might be built on the advisory locking (as in the case of
SQLite) or some other strategy.

--
https://www.greenend.org.uk/rjk/

On 25/08/2023 09:38, Richard Kettlewell wrote:
> The Natural Philosopher <tnp@invalid.invalid> writes:
>> On 24/08/2023 09:12, candycane wrote:
>>>> Dos could lock for write or read an area of a file, for instance. And
>>>> those are mandatory locks. This feature is needed for databases that
>>>> run without a centralized daemon, but sharing the database file itself
>>>> instead.
>>> Linux does have posix locks from what I remember.
>>>
>> Linux has and had many forms of file locking AFAICR. No one uses them,
>> because file locking is itself a very unpleasant way to handle
>> multiuser access to a shared resource.
>
> It has advisory file locking and plenty of things use that; it’s
> mandatory locking that it’s (now) missing.
>
>> I spent too many hours removing file locks on files set by PCs running
>> windows that users had switched off, or which had crashed, without
>> exiting the applications that set the locks.
>
> Unfortunately even advisory locks can result in things getting stuck
> (the fact that it’s advisory doesn’t help if the thing you want to make
> progress honors the advisory lock).
>
>> OTOH databases were designed from the outset to have robust multiuser
>> access to shared resources.
>>
>> So if that is a requirement, you simply tend to use a proper SQL style
>> database.
>
> Right. Those might be built on the advisory locking (as in the case of
> SQLite) or some other strategy.
>

The best engineering approach is a cacheing daemon like MySQL: requests
are buffered, and honoured via a single sequential pipeline.

--
For every complex problem there is an answer that is clear, simple, and
wrong.

H.L.Mencken

On 2023-08-25 03:36, The Natural Philosopher wrote:
> On 24/08/2023 09:12, candycane wrote:
>>   CER> Dos could lock for write or read an area of a file, for
>> instance. And
>>   CER> those are mandatory locks. This feature is needed for databases
>> that
>>   CER> run without a centralized daemon, but sharing the database file
>> itself
>>   CER> instead.
>>
>> Linux does have posix locks from what I remember.
>>
> Linux has and had many forms of file locking AFAICR. No one uses them,
> because file locking is itself a very unpleasant way to handle multiuser
> access to a shared resource.
>
> I spent too many hours removing file locks on files set by PCs running
> windows that users had switched off, or which had crashed, without
> exiting the applications that set the locks.
>
> OTOH databases were designed from the outset to have robust multiuser
> access to shared resources.
>
> So if that is a requirement, you simply tend to use a proper SQL style
> database.

Meaning a central database engine aka daemon, which is a different
animal. A rogue application might still access the database (files)
directly bypassing the controls in the engine.

As I said, I have no argument about which is better or worse.

--
Cheers,
Carlos E.R.