Newsgroup: it.comp.os.linux.sys
Titolo: SAMBA - Accesso contemporaneo ad un file

Buongiorno ragazzi,
Ho un problema con Samba.. magari mi sto perdendo in un bicchier d'acqua.
 
E' possibile accedere allo stesso file in piï¿œ di un utente ?
Al momento il secondo utente si ritrova il file in sola lettura.. oppure
gli compare un messaggio d'errore.
 
E' il comportamento corretto o ï¿œ possibile ovviare ?
Come funziona (nel caso fosse prevista) la gestione degli accessi
concorrenti ?
 
Grazie a tutti!
YUS


 
Suppongo che piu utenti devono poter leggere/scrivere lo stesso file
 
Occorre avere due punti di vista, uno da unix (se serve) e l' altra da samba
 
Da unix si mette in comune il gruppo e imposti una umask di 002 per 
tutti gli utenti dello stesso gruppo
Questo permette di mettere in lettura/scrittura i file creati da 
ambiente unix
 
Nel file di configurazione di samba si fa in modo che gli utenti samba 
coincidano con le controparti unix appartenenti allo stesso gruppo
 
 
Nelle condivisioni si imposta le maschere di creazione:
    create mask = 0664	
    directory mask = 0775
 
 
Questo fa in modo che la creazione di file/directory sia in comune
 
Spero di non avere dimenticato niente
 
 
 
 

 Spero di non avere dimenticato niente
 
Forse sbaglio io ma mi pare che l'OP intendesse l'apertura (e la
modifica) in contemporanea dello stesso file da parte di piu' utenti.
Credo che dipenda pi� dal programma e dal tipo di file.
 
Un file di puro testo credo sia modificabile da semplici editor
contemporaneamente ma credo pure che alla fine il file sara' quello
salvato l'ultimo utente che chiude il lavoro salvando, cancellando
eventuali altre modifiche.
 
Invece il primo utente che apre un file ODT con libreoffice potra'
apportare le modifiche direttamente mentre gli altri utenti (che
possono aprirlo in sola lettura) dovranno prima salvarne una copia in
locale e lavorare su quella. Ovviamene se dopo salvano sulla
condivisione samba senza le opportune cautele annulleranno il lavoro
fatto da altri.
-- 
Ciao
Andrea Malfatti


 
 
Se è cosi allora ho compreso male le sue parole
Sui lock hai ragione
In unix la gestione dei lock è ha carico dell' applicativo usando le 
apposite chiamate di sistema
 
 

 fatto da altri.
 
Esattamente, questa � la situazione tipica in cui mi sono sempre ritrovato.
 
Essendo subentrato ora nella gestione di un piccolo ufficio ed avendo
sostituito il server (ho migrato da RH a Debian), mi si presenta questo
'problema' che fin'ora problema non � mai stato.
 
Il proprietario mi dice per� che prima era possibile accedere
contemporaneamente agli stessi file, cos� che non ho modo di verificare
se non fidandomi. Pur avendo replicato la stessa configurazione di
samba, non riesco ad ottenere il risultato desiderato, ovvero accessi
concorrenti allo stesso file.
 
Ho preferito mettere prima in dubbio le mie conoscenze della parola del
cliente. In effetti a logica, non mi era ben chiaro come OpenOffice o
altri tool da ufficio potessero gestire la cosa, ma ho preferito sondare
l'esperienza del gruppo.
 
Direi quindi che il comportamento della rete non presenta nessuna
anomalia.. a meno che qualcuno non abbia qualcosa da aggiungere!
 
Grazie!
YUS


 
Si, ma non è meglio adesso ?
Se piu utenti modificano contemporaneamente un file (prendendo come 
esempio Office) solo l' ultimo salvataggio va in porto, gli altri 
andranno persi
In questo modo un utente crede di avere salvato il suo lavoro e non si 
accorge che in realtà è andato perso
Non mi sembra una buona idea
 
 

 andranno persi
 
Non sempre ciò che è meglio e ciò che vuole il cliente coincidono.
=)
 
YUS


Allora indottrinalo :)
Fagli capire che la soluzione attuale (con i lock) è la migliore per lui
 

 Fagli capire che la soluzione attuale (con i lock) è la migliore per lui
 
Ti do l'indirizzo così ci parli direttamente tu!
=)
 
YUS
 


No, grazie
Le beghe piu grandi in un progetto informatico sono proprio i clienti.
Non certo lo sviluppo di sw
Lo so bene
 


volentieri, sono qui.. :-)
 
S.

anomalia.. a meno che qualcuno non abbia qualcosa da aggiungere!
 
Direi di no, nessuna anomalia.
 
In teoria ci sarebbe la possibilit� di bloccare solo alcune parti del
file, ma non conosco nessuna applicazione che lo faccia.
 
Comunque non dovrebbe essere difficile spiegare al cliente la
questione: come fa uno ad auspicare una situazione in cui scrive A
dentro a un file e poi ci trova B perch� un'altro ha salvato dopo di
lui?
 
 
-- 
Ci sono 10 tipi di persone al mondo: quelle che capiscono il sistema binario
e quelle che non lo capiscono.

 contemporaneamente agli stessi file,
 
 
lol
se per ogni "prima era possibile e lo facevo tranquillamente" non 
veritiero prendessi 1 euro a quest'ora avrei la villa alle bahamas.
 
 
penso che mi manchi solo "prima del cambio degli switch lo sciacquaone 
del cesso non usava acqua ma idrogeno".
 


 
Si, ma il sistema di versioning dovrebbe essere trasparente all' utente
Lo vedi un utente comune che per accedere ai file remoti si fa un svn 
up, modifica in locale, e poi fa un svn commit ?
 
Piuttosto un file system con versioning, so che ne esiste qualcuno, ma 
personalmente non ne ho mai usati
 


 
Dipende, un file system a versioning potrebbe fare un branch automatico 
in caso di conflitto ma poi si avrebbero piu versioni dello stesso file 
che occorre saper gestire.
 
Se i conflitti devono essere gestiti manualmente immagino già la fila
di utenti davanti all' informatico di turno che vengono a lamentarsi del 
fatto che non possono salvare il loro file.
 
Mi sa che la soluzione migliore resta sempre quella classica del lock
 
 
 
 
 

 
]zac[
 
Potenzialmente i problemi sono ben maggiori se capita il caso della 
scrittura contemporanea (che prima o poi capita), il risultato probabile e' 
che il contenuto del file diventi inutilizzabile.

che il contenuto del file diventi inutilizzabile.
 
Ma quanto dev'essere contemporanea la cosa?
Non dovrebbe prendersi un rifiuto uno dei due salvataggi?



Non saprei per l' ambiente win32/64, ma per i sistemi posix occorre 
gestire la concorrenza con i lock
 
 

 lui?
 
No in realtà non è difficile da spiegare, ci stavo scherzando un pò su.
Ovviamente il cliente è stato messo al corrente della questione.
 
L'unica cosa che mi perplime è che Lotus Organizer prima era utilizzata
da tutti 'in contemporanea', mentre ora presenta appunto il problema del
lock fin'ora descritto.
 
Qualche idea ?
Grazie
 
G.

 
 
In windows i file si possono aprire in uso esclusivo (a livello di sistema), 
qualsiasi altro tentativo di apertura del file fallirebbe.
 
 
In linux ogni programma deve/dovrebbe chiamare una funzione (la medesima) di 
''lock'' dei file e gestirne il risultato (ci sono anche delle opzioni per 
il mount per avere qualcosa di simile a windows, ma e' poco usabile/utile).
 
In pratica si puo' prendere vi aprire il file di un 'database' e scriverci 
sopra mentre il motore del database ha stralocckato le tabelle, i record, 
ecc. e ci sta scrivendo sopra anche lui.
 


 
 
 
Ovvio, un gestore di database, in quanto un insieme di processi aventi 
lo stesso leader, non fa certamente una open con lock sui file fisici
Potrebbe usare flock per i lock sui record ma non è detto, anzi dubito
 
 

qualsiasi altro tentativo di apertura del file fallirebbe.
 
Il blocco note non funziona cos�.


 Il blocco note non funziona così.
 
Giusto ieri, la cancellazione di una directory su di un Windows Server 2008 
falliva miseramente. Motivo? Avevo un file aperto con il blocco note
 
Enrico

falliva miseramente. Motivo? Avevo un file aperto con il blocco note
 
Prova perň a aprirlo da due postazioni diverse: l'ultima che salva
vince.



Mah... qui su una macchina XP se apro un file in locale con notepad 
posso cancellare il file e la directory senza problemi.
 


Non è proprio la stessa cosa
Un conto è il lock su un file che è affettuato dall' applicativo, l' 
altro è il lock sulla directory che contiene il file; probabilmente la 
directory corrente era quella che conteneva il file e automaticamente il 
kernel effettua il lock
Il lock sulla directory ovviamente non è un obbligo, dipende dal design 
del kernel, infatti in ambienti posix il kernel non mette nessun lock 
sulla directory corrente
 
 


Ovvio, notepad fa una open sul file, legge il file e lo chiude
Il lock era dovuto in quanto la directory corrente era quella che 
conteneva il file
 


In questo caso non e' l'accesso esclusivo al file la causa, ma la directory 
che e' lockkata dal un qualsiasi accesso ad un suo contenuto (e' simile al 
caso dell'umount di linux).

 Potrebbe usare flock per i lock sui record ma non è detto, anzi dubito
 
No.
 
 
Cortesemente dovresti documentarti sulle specifiche posix per i lock che 
segue linux e le specifiche per i lock che segue windows.
 
 

 
 
Cortesemente puoi rileggere la sesta parola che ho scritto?


Non ho bisogno di documentarmi, sono cose che conosco benissimo
Se ritieni che abbia detto delle cazzate sii più specifico
 
 


Ma ti sei alzato male oggi o hai proprio il PH basso ?
=)
 
YUS