linux user group brescia

In data 30/07/2008 08:46:58, Cesare Poinelli ha scritto:
> Ciao a tutti,
> in questo periodo mi sono scontrato con un problema di non poco conto
> in 
> relazione al locking dei file openoffice all'interno di condivisioni 
> samba o nfs.
> 
> La situazione è questa:
> Una rete aziendale con un server samba e nfs, con installato ubuntu
> 8.04 
> server,
> una decina di client ubuntu 8.04 desktop e un paio di macchne windows
> xp 
> home.
> 
> Il problema sorge quando due pc linux aprono il medesimo file .doc
> .ods 
> (o qualsiasi altro tipo di file apribile con openoffice); entrambi 
> ottengono i permessi di lettura e scrittura sul file, anche se il 
> comportamento corretto sarebbe impedire l'accesso al secondo pc che
> apre 
> il file o meglio ancora accedervi in sola lettura.
> 
> I client windows in questo caso si comportano correttamente, ovvero 
> il
> 
> primo che arriva accede in lettura e scrittura il file, mentre il 
> secondo vi accede in sola lettura.
> 
> Ho già provato ad eliminare le voci di samba che abilitano l'oplock,
> ma 
> non è cambiato nulla. A mailncuore il problema esiste anche con le 
> condivisioni nfs ...
> 
> Qualcuno ha già avuto esperienze simili? C'è un modo per risolvere la 
> situazione o almento aggirarla?
> 
> Per saperne di più in relazione al problema citato direi che questi
> link 
> sono abbastanza eloquenti:
> 
> http://osdir.com/ml/linux.file-systems.cifs/2006-12/msg00006.html
> 
> http://www.openoffice.org/issues/show_bug.cgi?id=57712
Finisce cos'i':
	
------- Additional comments from hro Tue Apr 18 15:59:21 +0000 2006 
-------

@dbw: Your desired behaviour reflects the DENY_xxx modes used by the 
Windows file API. UNIX does not support such DENY_xxx modes which are a 
kind 
of locking on Windows. Instead file locking is implemented (and OOo 
does so) by 
f_cntl() calls to set a write lock, while on Windows clients it's done 
by setting the 
share mode to DENY_WRITE when opening a file for writing.

Your first provided SMBD log output shows that the share mode is not 
set when 
accessing the files from linux clients. OOo does not know anything 
about the file 
system it accesses, it just sets a write lock. Then it's up to the smb 
client to 
forward the write lock to the smb server and the smbd has to translate 
that into a 
share mode (and vice versa when a share mode is set by a Windows 
client).

oplocking has nothing to do with real locking it's just a hint wether 
the client is 
allowed to cache the files by assuming the client is the only one 
accessing the 
file. So enabling oplocking in smb.conf is a bad idea if you want to 
get the desired 
exclusive file access. I don't know which parameter in smb.conf might 
help but 
when taking a look into the manpages I guess playing around with "posix 
locking", "kernel oplocks",  "strict locking" might be the right 
switches.

The answer for the NFS problem is that locking is just faked if there's 
no lock 
deamon running on the NFS server.

So the answer to fix the problem is: Configure your file system servers 
and clients 
in a suitable manner to get the desired behaviour. It's not an OOo 
specific thing. 
And I don't know wether this is possible at all as I've not tested the 
smb.conf 
switches.


Se è come dice lui dovresti avere lo stesso problema ad aprire un file 
txt contemporaneamente con vi o altro editor su due pc linux client.
Così a naso direi che è un problema di client.

Ciao

Giorgio Di Giovambattista