[linux-l] NFS file locking: es geht einfach nicht...

[Peter Ross]

Steffen Dettmer sagte:
> Es haben aber alle drei Testmaschinen SuSE 8.2, also keine
> anderen Betriebsysteme.

"Anders" als SunOS;-)

> Wenn ich das richtig verstanden hab, ist flock laut POSIX (oder
> weiss ich was)

(BSD 4.2 und hoeher)

> local-only

unter linux, nicht nach Standard!

> - was IMHO schon ein Bug ist, Files sollten Files sein!

Ja, nu teer und feder die Linux-NFSler dafuer;-)

> Nach dieser Festlegung jedenfalls gehe ich davon aus, dass jemand
> der flock benutzt nur lokal locken möchte (wir wissen, dass das
> sicherlich meistens anders gemeint war ;)). Jetzt kommt flock
> (was lokal arbeitet) mit einem Fehler zurück (der vom "Netz"/NFS
> kommt), was doch falsch ist? Er kann das Teil doch lokal locken?

Er kann das File, was auf dem NFS-Server liegt, unter Linux nicht locken -
das es einen Fehler zurueckgibt, ist in Ordnung - was Dein
Anwendungsprogramm damit macht, istDir ueberlassen.

> Wie es ein Linux 2.2 ja auch gemacht hat
glaube ich nicht, zuerst ist mir das unter einem Linux 2.2 (Debian potato)
aufgefallen.

Aber Du darfst ja unter Linux auch zwischrn User- und
Kernel-NFS-Implementierung waehlen..erstere ist auch weird..


> Ach so. Also ist lockf das, was man benutzen soll, ja? Was mich
> bei man lockf wundert:
>
> 	lockf - apply, test or remove a POSIX lock on an open file
> [...]
> CONFORMING TO
>        SYSV
>
> ist das nun eigentlich POSIX? Soll man auf "allen" (POSIX-)
> Architekturen lockf in solchen Fällen verwenden?

Vielleicht, aber die Semantik ist anders.

>> Zumal POSIX-lockf und BSD-flock nicht das Gleiche sind - das
>> eine machts mit einem Filenamen, das andere mit einem Inode.
>
> BSD-flock arbeitet mit einem Dateinamen?! Komisch, mein man flock
 sagt,
> CONFORMING TO 4.4BSD [...] als int flock(int fd, int operation).

Entschuldigung, mit Files statt mit Filedeskriptoren, das war Schlamperei
von mir:

http://www.freebsd.org/cgi/man.cgi?query=flock&apropos=0&sektion=2&manpath=FreeBSD+5.2-RELEASE+and+Ports&format=html

NOTES
   Locks are on files, not file descriptors.	That is, file descriptors
   duplicated through dup(2) or fork(2) do not result in multiple instances
   of a lock, but rather multiple references to a single lock.  If a process
   holding a lock on a file forks and the child explicitly unlocks the file,
   the parent will lose its lock.

> Was mich wundert, dass google recht wenig zu dem Thema sagt. Man
> könnte ja annehmen, dass viele die Distri-Defaults (gar keinen
> lockd/statd starten) verwenden, und denen daher sowas gar nicht
> so auffällt? Nein, darüber möchte ich jetzt nicht weiter
> nachdenken ;-)

Ganz einfach: Schlamperei ist hier der Default, da das Ganze ohnehin
wacklig ist..

> Danke für den lockf-Tipp und die ganzen Infos!!

Prima. viel Spass!

Gruss
Peter