2012-01-10 16 views
8

Sto riscontrando un problema ricorrente in un'applicazione che tiene traccia del contenuto dei file all'interno di una directory, in base all'API Java 7 WatchService. Quando il file system sottostante attiva un evento di modifica su un file, voglio calcolare immediatamente il suo SHA-256.I/O Java: assicurarsi che un file non sia bloccato da un altro processo prima di qualsiasi operazione di r/w

Ma spesso si verifica che un altro processo abbia il file aperto (ad esempio Word), trattenendo così un blocco esclusivo e impedendo alla mia app di eseguire operazioni di lettura/scrittura. Se una qualsiasi stream/canale è stato creato contro il file aperto, un FileNotFoundException o un FileSystemException per NIO API è gettato con un messaggio del tipo:

Il processo non può accedere al file perché è utilizzato da un altro processo

Non sono riuscito a venire con una soluzione in grado di rilevare tali casi senza mascherare una "reale" FileNotFoundException quando il file non esiste effettivamente sul file.

Mi è venuta l'idea di controllare l'esistenza tramite File.exists e quindi se viene generata un'eccezione FileNotFoundException quando apro un flusso, sarei in grado di dedurre che il file è bloccato. Sono aperto a qualsiasi input su questo!

Grazie!

+0

mai trovare una soluzione a questo? –

+0

Ho finito per usare l'euristica menzionata, se File.exists restituisce true nel blocco catch di FileNotFoundException, lo interpreto come un file bloccato. – sylvain

risposta

1

Hai provato a bloccare il file da solo? Suppongo che tu possa acquisire un lucchetto solo se non è bloccato ed esiste.

http://docs.oracle.com/javase/7/docs/api/java/nio/channels/FileChannel.html#tryLock%28%29

+0

Non è stato possibile chiamare tryLock() poiché le eccezioni menzionate vengono generate quando tento di ottenere un FileChannel tramite RandomAccessFile o FileOutputStream. – sylvain

+0

In questo caso sembra che devi controllare l'eccezione che viene generata quando tenti di accedere a questi file. Non vedo il punto di tryLock se non riesci a chiamarlo se il file è bloccato. –

+1

La mia ipotesi è che le applicazioni native possano avere blocchi più restrittivi rispetto a quelli disponibili all'interno della JVM. – sylvain

0

la condivisione di documenti accross processi è difficile soprattutto quando non si utilizza file system dedicati (come GFS possono essere) .. non credo che Java API di blocco può aiutare molto, credo che siete su nel modo giusto con la tua idea della strategia try/fail ... Usando java 7 potresti usare un WatchService per monitorare le modifiche ai file e agire come stabilito dai tuoi requisiti aziendali ... Che tipo di sistema usi? Windows tiene maniglie sul file durante l'eternità ...

HTH Jerome

+0

Infatti, ho già un thread WatchService in ascolto per eventi FS, in esecuzione solo su Windows per ora. Ad ogni modo sapevo che non ci sarebbe stato un modo per accedere a quei file bloccati, ma sono sorpreso che non ci sia un'API all'interno di java.io o java.nio per testare la loro accessibilità. – sylvain