On Apr 4, 2016, at 10:51 AM, Andrey Repin <anrdae...@yandex.ru> wrote:
> 
>> BSD file locks created via flock are only propagated to the direct parent
> 
> that's a showstopper. In short, it makes the function literally useless.

Nonsense.  That’s only true if “literally” every program that uses BSD locks 
creates grandchildren that also need to use those same locks.

I know of one program for certain that uses BSD locks under Cygwin that doesn’t 
create grandchildren, and its extensive test suite passed with Cygwin/BSD locks 
the last time I ran it.

> Why they aren't real locks? What's use for "advisory locks”?

“Real” locks are generally not what you want when running purely Unix/Linux 
software under Cygwin, because that’s not what you get by default on Linux or 
Unix.  You have to go out of your way to get mandatory locking on POSIX 
systems, as a rule.

Mandatory locks aren’t purely positive.  They’re the single biggest reason 
Windows still needs a reboot for many kinds of upgrades, while Linux generally 
only has to be rebooted for kernel or glibc upgrades, and the latter is, 
strictly speaking, optional.

> "I think I may
> have a use for this file, but you are free to delete it, if you wish” ?

Among cooperating processes, that’s perfectly fine.

Consider SQLite.  On a system where SQLite decides to use some form of advisory 
locking, the primary risk of damage isn’t rm or dd, it’s another copy of SQLite 
coming along and writing to the DB while the first is in the middle of a 
transaction,.

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Reply via email to