Newsgroup: it.comp.programmare.win32
Titolo: rilasciare il lock sui file

Ciao,
c'e' qualcuno che conosce quale API bisogna chiamare per rilasciare un
file in uso da un'altra applicazione ???
Esempio : il file .exe di un processo in esecuzione, oppure come opera
lo stesso windows quando si applica un aggiornamento per sostituire i
file lockati dal sistema operativo.
Grazie, ciao.

xyz*
wpa...@jumpy.it
 wrote in 
news:3c4da714...@192.168.118.118
:

Per costringere un'applicazione a rilasciare i file in uso (e visto che 
parli di aggiornamento, credo tu intenda exe e dll) puoi soltanto 
terminarla in modo più o meno "grazioso" (inviando un WM_SYSCOMMAND o 
WM_CLOSE alla finestra principale, un WM_QUIT al loop dei messaggi o 
con TerminateProcess).
Con windows NT/2000 puoi usare MoveFileEx per forzare la copia al 
reboot. Su windows 9X lo stesso comportamento si ottiene inserendo i 
path (solo nel formato short) dei file da spostare nella sezione 
"rename" del file "WININIT.INI" che verrà eseguito al successivo 
reboot. 
-- 
Valter Minute
min...@inwind.it
 (the reply address of this message is invalid)

 con TerminateProcess).
Il messaggio giusto e' o WM_SYSCOMMAND con SC_CLOSE o
WM_CLOSE.  WM_QUIT no.
-- 
Posted via Mailgate.ORG Server - 
http://www.Mailgate.ORG

 
Ho elencato le alternative in ordine di "delicatezza".
Sicuramente WM_SYSCOMMAND con SC_CLOSE e WM_CLOSE sono la soluzione 
migliore per interrompere un programma.
Se nessuno dei due messaggi sortisce l'effetto desiderato, credo che 
postare un WM_QUIT al thread principale possa essere un metodo meno 
brutale del TerminateProcess nel caso in cui il programma non 
risponda alle due precenti richieste non perchè sia bloccato, ma 
perchè (ad esempio) è attiva una dialog modale che non permette di 
essere chiusa, oppure nel caso in cui la chiusura della finestra 
principale non provochi la chiusura del programma (può capitare con 
programmi che usano finestre invisibili).
In questo modo dovrebbero essere rilasciate in modo "pulito" 
perlomeno le risorse allocate da oggetti dichiarati "staticamente" 
(che sfruttano il distruttore per rilasciare le risorse) e comunque 
viene eseguita una parte del codice di shutdown.


 e comunque viene eseguita una parte del codice di shutdown.
Credo che, generalmente, gran parte del codice di shutdown 
venga eseguita all'elaborazione del WM_DESTROY (che con il 
WM_QUIT diretto verrebbe saltata).  In ogni caso, siamo
sicuri che spedire WM_QUIT consenta di svincolare i lock 
su file ?


 su file ?
I file aperti dovrebbero comunque essere chiusi dal S.O. alla 
chiusura del processo. Alcune tipologie di handle invece (handle 
TAPI, per esempio) soprattutto con windows 9X, se non vengono 
rilasciati correttamente creano problemi, ma questi problemi li 
avresti anche con TerminateProcess.


falliscono.
Il mio problema e' che il file dell'eseguibile residente sul server
viene lanciato da diversi client che lockano il file, e vorrei evitare
di lanciare un WM_QUIT ad ogni istanza client.
Ciao.

 di lanciare un WM_QUIT ad ogni istanza client.
Ovviamente killare l'applicazione non e' la soluzione
al tuo problema.  Non capisco, pero', a cosa ti serve
forzare il rilascio del lock (ammesso che si possa 
fare), se il lock c'e' vuol dire che il server, con
quei file, ci sta lavorando...  forse se specifichi
meglio il problema si puo' trovare una soluzione migliore...


 
Ma devi sostituire l'eseguibile o dei file di dati?




No, forse non mi sono spiegato correttamente...
Il file e' un eseguibile che risiede sul server ma viene lanciato da
diversi client e quindi viene lockato.
Non e' quindi in esecuzione sul server.
Siccome non posso confidare nella chiusura delle istanze su ciascun
client volevo segare i lock e copiare le nuove versioni
dell'eseguibile in maniera automatica.
Ciao e grazie.

 
Non sò se è possibile "chiudere" brutalmente le connessioni a un file 
condiviso e comunque questo causerebbe errori sui client dove è in 
esecuzione il programma e conseguenti perdite di dati.
Una soluzione alternativa potrebbe essere implementata tramite un 
programmino che lancia l'eseguibile vero e proprio prendendo il nome da 
un file di configurazione.
In questo modo non è necessario cancellare il vecchio eseguibile e i 
client che eseguirano l'applicazione dopo l'update passeranno ad 
utilizzare la nuova versione in modo trasparente.
Il programmino di lancio potrebbe anche restare attivo fino alla 
chiusura dell'exe principale e controllare se nel frattempo è stata 
installata una nuova release. 
In caso affermativo dovrebbe provare a cancellare il vecchio exe. 
In questo modo alla chiusura dell'ultimo client vecchia versione il 
relativo exe sarà rimosso (questo potrebbe esseere utile, oltre che a 
risparmiare spazio su disco, anche per controllare se ci sono ancora 
client non aggiornati).
Ovviamente questa soluzione è valida solo se i client accedono a dati 
locali o comunque non condivisi, altrimenti una nuova versione che 
prevede anche delle modifiche alla struttura dei dati potrebbe creare 
problemi ai client vecchia versione ancora attivi e viceversa.
