Auf einen mit SharePoints freigegebenen Ordner kann, wie erwartet von einer Arbeitsgruppe, welche " Projektgruppe" heisst, zugegriffen werden. Die Rechte für diese Gruppe sind auf " lesen und schreiben" gesetzt . Der Eigentümer ist gleichzeitig auch Mitglied von "Projektgruppe" darf also als Eigentümer und als Gruppenmitglied lesen und schreiben. Alles funktioniert wie erwartet.

Dennoch gibt es ein Riesenloch:
Dateien,zB ein Textdokument kann von den Mitgliedern der Projektgruppe geöffnet und geändert werden, auch wenn ein anderes Gruppenmitglied dieselbe Datei bereits geöffnet hat.
Es kommt keine Fehlermeldung, man kann einfach das was der oder die anderen Benutzer gerade gemacht haben, überschreiben.
Das ist eigentlich eine Katastrophe, was hab ich da falsch gemacht.

Dateien,zB ein Textdokument kann von den Mitgliedern der Projektgruppe geöffnet und geändert werden, auch wenn ein anderes Gruppenmitglied dieselbe Datei bereits geöffnet hat.

Ist doch normal unter UNIX! Die Applikation muss ggf. mit einem Locking-Mechanismus den parallelen Zugriff ausschließen. Hilft dann aber auch nicht mehr bei mehreren Apps, die es unterschiedlich machen. Im UNIX-FS und NFS gibt es Exclusive-Locks ob CIFS/SMB so etwas hat ist mir aber unbekannt.

Ich kenn das Problem eigentlich nur von Excel, das immer sgat, dass das Dok von einem anderen User geöffnet ist, und deshalb nur im read-only modus geöffnet werden kann! Vielleicht ist das bei Textedit anders??? Welches Prg verwendest Duz, um die Daei zu öffnen???

Problem eigentlich nur von Excel

µ$ Office Programme legen in dem Verzeichnis der geöffneten Datei eine neue Datei mit einem seltsamen Präfix und dem Dateinamen an. Öffne mal eine Datei mit Office und gucke im einem ordentlichen Tool in das Verzeichnis (gemeint ist nicht der Windows-Explorer)! Das ist eine Möglichkeit des Lockings, die aber nur funktioniert, wenn alle Programme sich an das Verfahren halten... Ist aber nicht so!

Ich habe das mit TextEdit getestet. Hier wärs mir ja wurscht, aufgefallen ist mir das Problem in unserem Cad Programm VectorWorks. Da haben sich zwei Projektbearbeiter gegenseitig das Dokument kaputtgeschrieben ohne voneinander zu wissen. Da wirds natürlich wirklich haarig.

Also, ihr sagt das sei vom Grundsatz her in Ordnung( was die Unix seite angeht) und müsste programmseitig sichergestellt werden ?

So oder so! Ja, standardmäßig ist es Shared-Read! z.B. Kannst Du sogar eine Shared-Libary eines gestarteten Programmes löschen (Solaris, ...) oder zumindest umbenennen (HPUX). Die geöffneten Programme tangiert es nicht, neue können nicht gestartet werden, weil die Lib fehlt... Ist etwas anderes als bei Windows, wo alles alle Nase lang gesperrt ist, was mich regelmäßig nervt! (sick)

Entweder öffnet das Programm eine Datei exklusiv oder es wird ein Locking eingebaut. Das ist aber nicht einfach, da man in den Öffnen Vorgang es Programmes eingreifen müsste. Bei Cocoa-Programmen liesse sich das mit einer Application-Support-Routine machen, aber das ist außerhalb meiner praktischen Kenntnisse! Frag mal beim Hersteller von "VectorWorks" nach!

dieter
danke, jetzt weiss ich wenigstens dass es nicht an mir liegt. Soweit ich ich erinnere hat VectorWorks in der Vorgängerversion das Problem noch geregelt gehabt.Vermutlich ist das bei der neuen Version vergessen worden. Ist natürlich eine ziemliche Katastrophe bei einem Cad Programm wenn in Teams gearbeitet werden muss.

Ich habe zwischendurch mal etwas bei "Samba" herum geblättert. Und gefunden habe ich in den tausenden von Optionen. "locking", "opportunistic locking", "strict locking", "oplocks", "blocking locks"

Ein Auszug aus "man smb.conf" ... wie es aussieht hat Samba einige Mechanismen extra dafür ...


locking (S)
This controls whether or not locking will be performed by the
server in response to lock requests from the client.

If locking = no, all lock and unlock requests will appear to
succeed and all lock queries will report that the file in ques-
tion is available for locking.

If locking = yes, real locking will be performed by the server.

This option may be useful for read-only filesystems which may
not need locking (such as CDROM drives), although setting this
parameter of no is not really recommended even in this case.

Be careful about disabling locking either globally or in a spe-
cific service, as lack of locking may result in data corruption.
You should never need to set this parameter.

No default



strict locking (S)
This is a boolean that controls the handling of file locking in
the server. When this is set to yes, the server will check every
read and write access for file locks, and deny access if locks
exist. This can be slow on some systems.

When strict locking is disabled, the server performs file lock
checks only when the client explicitly asks for them.

Well-behaved clients always ask for lock checks when it is
important. So in the vast majority of cases, strict locking = no
is preferable.

Default: strict locking = yes



blocking locks (S)
This parameter controls the behavior of smbd(8) when given a
request by a client to obtain a byte range lock on a region of
an open file, and the request has a time limit associated with
it.

If this parameter is set and the lock range requested cannot be
immediately satisfied, samba will internally queue the lock
request, and periodically attempt to obtain the lock until the
timeout period expires.

If this parameter is set to no, then samba will behave as previ-
ous versions of Samba would and will fail the lock request imme-
diately if the lock range cannot be obtained.

Default: blocking locks = yes



oplocks (S)
This boolean option tells smbd whether to issue oplocks (opportunistic locks) to file open requests on this share. The oplock code can dramatically (approx. 30% or more) improve the speed of access to files on Samba servers. It allows the clients to aggressively cache files locally and you may want to disable this option for unreliable network environments (it is turned on by default in Windows NT Servers). For more information see the fileSpeed.txt in the Samba docs/ directory.

Oplocks may be selectively turned off on certain files with a share. See the veto oplock files parameter. On some systems oplocks are recognized by the underlying operating system. This allows data synchronization between all access to oplocked files, whether it be via Samba or NFS or a local UNIX process. See thekernel oplocks parameter for details.

Default: oplocks = no

Aber ich bin nicht sicher, ob es ohne Zutun des Programmes (Lock Request from Client) funktioniert wie Du es brauchen könntest!

dieter

das Problem tritt unter AFP auf, vielleicht auch unter Samba, bloß da stört es mich momentan nicht.
Interessanterweise verhalten sich die Dateien nicht immer so. Manchmal kommt auch die Meldung" ist in Gebrauch, wollen Sie eine Kopie öffnen" Wenn ich aber die Info aufrufe sind die Parameter bez. Rechte und Benutzer gleich gesetzt. Es muss also noch irgendeine "unsichtbare" Berechtigung geben.

Titel sagte "AFP" habe ich gesehen, aber Text sagte "SharePoints" und "Arbeitsgruppe", daraus entnahm ich SMB, also Samba ...


Die Dateien oder die Programme?

Wenn ein Programm ein Locking macht (s. Office) oder eine Datei "exklusiv" öffnet und nicht schließt, solange es in Bearbeitung ist, kann das entsprechende "Programm" so reagieren ... in Fall des "exklusiven Lock" sogar alle Programme!

Vorgehensweise ist so:
Programm wird gestartet,zb Text edit, Dokument auf den Fileserver in einen zum Filesharing freigegebenen Ordner gesichert . Programm Beenden, Dokument öffnen , ändern etc. Dann von einem anderen Rechner aus dasselbe Dokument öffnen, ändern, sichern etc. Es gibt kein Problem ausser dass das Dokument das User 1 angelegt hat, obwohl er es selbst geöffnet hält, überschrieben wurde. Der der zuerst sichert bestimmt den Inhalt, und zerstört damit die Arbeit des anderen, und zwar ohne Meldung.
Ich habe noch nicht rausgefunden, warum, trotz gleich gesetzter und angezeigter Rechte, manchmal das Öffnen eines schon offenen Dokumentes verweigert wird, oder aber nicht. beides kommt vor.

Das Prinzip ist klar! Die selbe Datei ist geöffnet und der als letzter speichert gewinnt. Das ist auch so, wenn man nicht mit der selben Datei startet und beide nacheinander die Datei mit dem selben Namen speichern.

Ist es immer das selbe Programm, dass die Datei als erstes öffnet, wenn das zweite Programm, das selbe ein anderes(?) die geöffnete Datei öffnen will? Kann es bei längeren Dateien sein, dass der zweite Öffnen-Versuch in den Vorgang des Öffnens des anderen liegt, wo die Datei noch offen ist und gelesen wird? Dann Meldung? Hat das erste Öffnen den lesenden Vorgang abgeschlossen und schließt die Datei, wird der nächste dies ohne Meldungen öffnen können.

BTW: er es selbst geöffnet hält

Ist das so? Ist die Datei wirklich noch geöffnet (aus Sicht des Filesystems!) oder wird die Datei (aus Sicht des Filesystems!) göffnet, gelesen und wieder gschlossen?

In der Applikation sieht beides gleich aus. Die Datei ist geladen und kann bearbeitet werden ... Unter Linux gibt es einen Befehl "ofiles" (list open files) ein Äquivalent in Mac OS X (Darwin) kenne ich leider nicht!

Dabei liegt es so Nahe: "lsof" (LiSt Open Files)

Ja es ist so. Die Datei die User 1 geöffnet hält, wird von User 2 überschrieben, falls dieser sichert. Für User 1 der das Dokument bearbeitet hat, gesichert hat, aber es nicht geschlossen hat, ist dann die Überraschung gross wenn User 2 zwischenzeitlich weitergemacht und gesichert hat.
Das Problem liegt ausschliesslich darin, dass ein Dokument von mehreren gleichzeitig geöffnet werden kann.
Das war nicht immer so,ich denke mir ist das est seit Tiger aufgefallen.