Newsgroup: it.comp.programmare.win32
Titolo: file lock - c++

Salve a tutti.
Ho un problema.
Sto programmando in ambiente windows, in linguaggio c++.
Devo creare 2 applicazioni differenti: la prima di queste deve scrivere
dei file su disco. L'altra, periodicamente, verifica la presenza di questo
file e, se presente, lo legge.
Il problema č questo: come faccio a fare in modo che il file venga letto
dalla seconda applicazione solo dopo che la prima applicazione abbia
terminato la write? Cioč, chi mi dice che la seconda applicazione non vada
a leggere il file appena dopo che l'applicazione che crea il file abbia
eseguito la fopen e non ancora terminato la fwrite?
Grazie a tutti.
Valeria
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

terminato la write?
Cercando, periodicamente, di aprire il file con un lock esclusivo.
La funzione OpenFile di Windows ti consente di impostare un flag
chiamato OF_SHARE_EXCLUSIVE.  La documentazione riporta:
"Opens a file with exclusive mode, and denies both read/write access
to other processes. If a file has been opened in any other mode for
read/write access, even by the current process, the function fails."
Fintanto che la funzione fallisce, vuol dire che il file è ancora
"impegnato" da altri processi.

 chiamato OF_SHARE_EXCLUSIVE.  La documentazione riporta:
Non ho modo di utilizzare la "fopen" del C?


Non ho modo di utilizzare la "fopen" del C?
No, la fopen() non prevede meccanismi legati specificamente alla
piattaforma, devi rifarti all'API del sistema operativo.

 
Saluti  Manlio Perillo

il nome del file che usi.
Questa è una buona soluzione, anche se non mi piace tantissimo
(preferirei il polling sul tentativo d'apertura).

Ci sono due soluzioni.
Terza:
Cambiare l'attributo del file. (e scommetto che a Laforgia piace
di piu'...)

 (preferirei il polling sul tentativo d'apertura).
Si, ma la libc non prevede questa funzionalità, ne mi sembra ci sia
qualche standard multipiattaforma.
Leggendo la reference della GNU libc ci sono i flag O_SHLOCK e O_EXLOCK ma
solo su sistemi BSD.
Valeria__ ha comunque detto di lavorare su piattaforma Windows, però dice
che preferirebbe usare solo la sola libc.
P.S.
Una delle cose che più odiavo di Windows è che di default un file viene
aperto in modalità esclusiva.
Quindi se ho un file di log aperto e lo tento di aprire con WordPad,
non mi era permesso...
Saluti  Manlio Perillo



Quale attributo?
Saluti  Manlio Perillo

Non ho modo di utilizzare la "fopen" del C?
puoi usare la  _sopen ( simile alla fopen ) e supporta l'uso esclusivo
dei files .

 aperto in modalitÃ  esclusiva.
Non è mica vero.


 di piu'...)
Eh?


 
Non ho mai approfondito ma i vari Notepad/Wordpad avevano questa "feature".
Se aprivo i file con Emacs, ad esempio, non avevo problemi.
Quindi presumo che Wordpad apra il file in modalità esclusiva *assumendo*
che l'utente stia per fare qualcosa di male al file.
Saluti  Manlio Perillo

 problemi, potrebbe portare a disallineamenti.
i files temporanei sono giustamente risorse più facilmente leakabili, e il
disallineamento di cui parli avviene solo in caso di leak. per ovviare
puoi creare il file passando alla CreateFile il flag
FILE_FLAG_DELETE_ON_CLOSE. inoltre sarebbe anche bene marcarlo con
FILE_ATTRIBUTE_SYSTEM nonché FILE_ATTRIBUTE_TEMPORARY e
FILE_ATTRIBUTE_HIDDEN.


 Se aprivo i file con Emacs, ad esempio, non avevo problemi.
Ma quindi è un problema di determinate applicazioni (non mi sembra,
comunque, che Notepad sia tra queste; Wordpad mai usato), non è la
modalità di default di apertura dei file sotto Windows.  E' possibile che
alcune applicazioni cerchino di aprire i file in modo esclusivo, ma sotto
Windows, per default, un file aperto in scrittura è apribile in lettura da
un'altra applicazione.


Grazie a tutti!!!
siete stati utilissimi...oltre che velocissimi!!!!


Quale attributo?
Si usa l'attributo del file come "semaforo", con le API
SetFileAttributes (e GetFileAttributes). Ad esempio il file
leggibile ha un attributo NORMAL o ARCHIVE, lo si setta a SYSTEM
o HIDDEN durante la scrittura.

eseguito la fopen e non ancora terminato la fwrite?
Ricorda che esiste anche il problema inverso, cioe' la prima
applicazione non deve scrivere il file mentre esso viene letto.

 o HIDDEN durante la scrittura.
fa schifo


fa schifo
Adoro lo critiche dirette.

 FILE_FLAG_DELETE_ON_CLOSE. 
Sembra interessante questo flag, però il fatto che non sia presente nel
kernel di Linux o freeBSD mi lascia da pensare.
Saluti  Manlio Perillo

 fa schifo
Concordo.
Tipico esempio di come NON fare le cose.  Gli attributi vanno usati per
ciò che rappresentano, non come scappatoie per altre operazioni.  Già
immagino la situazione in cui, anche causa bug, il file rimane "hidden". 


 kernel di Linux o freeBSD mi lascia da pensare.
vuoi che ti faccio un elenco minimale di quello che manca negli Unix? :)))


 vuoi che ti faccio un elenco minimale di quello che manca negli Unix? :)))
Provo a indovinare: tutto ciò che è inutile? :-)


 Provo a indovinare: tutto ciņ che č inutile? :-)
che risposta fulminante :O
per curiositą: sei un professore universitario, vero? :P
perché professore universitario al giorno d'oggi č sinonimo di MacOS, e
quindi automaticamente Unix-sfegatated-fan,
possibly-with-little-or-no-technical-reasons(-even-if-this-is-not-the-case)
PS: no, hai sbagliato.


PS: no, hai sbagliato.
Non c'è che dire, anche la tua risposta è fulminante.
Ora aspetto di sentire le tue many-and-very-technical-reasons,
preannunciandoti che ho lavorato con tutti i tipi di Windows e molti
Unix tra cui SCO, IBM AIX, HP-UX e Tru64 (mi sembra doveroso
puntualizzarlo).

 puntualizzarlo).
non ho mica tutto questo tempo :)
non sono capace a fare discorsi così generici, ma che i kernels dei
Windows NT-based abbiano molte più features di molti Unix mi sembra
evidente, posto che certi *nix cercano anche di rimediare, come SELinux
per le ACL e come certi progetti per il registry e come tante altre pezze
per tante altre funzionalità che Windows NT ha da parecchio.


evidente
Evidente? a me non sembra cosě evidente. A me ciň che sembra piuttosto
evidente, invece, č che i kernel NT-based abbiano scopiazzato un bel
po' (e pure male) dai cuginoni Unix. Sarei curioso di conoscere queste
"molte piů features", ma non hai il tempo, peccato.

 "molte più features", ma non hai il tempo, peccato.
intanto due te le ho già citate: sistema di sicurezza ACL-based e
registry. erano solo le più evidenti, imho.


registry. 
Registry? Dio ce ne scampi e liberi.

 Registry? Dio ce ne scampi e liberi.
vedi cosa intendo con la storia delle little-or-no-technical-reasons? :)


vedi cosa intendo con la storia delle little-or-no-technical-reasons? :)
Veramente chi non sta dando motivazione alle proprie affermazioni sei
tu, non io e rimbalzi, peraltro, le domande sugli altri, anziché
rispondere.
Bah, ti lascio perdere... (anche perché non siamo su
it.comp.os.dibattiti e non voglio giocare a tira e molla con un
windows-sfegatated-fan).

 windows-sfegatated-fan).
infatti lo trovo un po' sterile anche io come flame, ma mi sembrava
comunque doveroso rispondere; sebbene l'atteggiamento mi faccia comunque
passare la voglia.
