java.nio.file.Files.isWriteable non è d'accordo con java.io.File.canWrite()

Question

Ho codice Java nel seguente modo:

1. Creare un file vuoto temporaneo con estensione ZIP utilizzando File.createTempFile()
2. Cancellare con File.delete() (abbiamo solo voluto che generare un nome file temporaneo)
3. Copiare un "modello" file ZIP per lo stesso percorso con com.google.commons.io.ByteStreams.copy() utilizzando un nuovo OutputSupplier dato lo stesso nome del file
4. Modificare la ZIP archivio (rimuovi un diretto ORY) utilizzando TrueZIP 7.4.3

Su un sistema specifico, il passaggio 4 non riesce coerentemente con FsReadOnlyArchiveFileSystemException - "This is a read-only archive file system!" (vedi http://java.net/projects/truezip/lists/users/archive/2011-05/message/9)

Debug del codice di TrueZIP, ho notato quanto segue:

• C'è nessun handle di file aperto su questo file tra uno qualsiasi dei passaggi precedenti e in particolare non prima del passaggio 4
• Controllare lo stesso file con File.canWrite() anziché NIO restituisce allo stesso tempo (usando un debugger), mostra quella è scrivibile

Ecco quello che si vede nella lista di espressioni del debugger:

fn => "C:/myworkdir/temp/myfile4088293380313057223tmp.zip" 
java.nio.file.Files.isWritable(java.nio.file.Paths.get(fn)) => false 
new java.io.File(fn).canWrite() => true 

Utilizzando JDK 1.7.04

Tutte le idee?

Answer 1

Eviterei di utilizzare entrambe le API e invece di fare affidamento sulle eccezioni generate da es. new FileOutputStream(). Almeno sono reali e di reale preoccupazione. L'utilizzo delle API menzionate è del tutto inutile e introduce finestre temporali e codice ripetuto. Devi prendere lo IOException in ogni caso: perché scrivere tutto quel codice due volte?

Answer 2

Il risultato finale non è troppo sorprendente:

java.nio.file.Files.isWritable(java.nio.file.Paths.get(fn)) => false 
new java.io.File(fn).canWrite() => true 

File.canWrite non presta attenzione alle ACL a tutti e controlla solo il MS-DOS attributo di sola lettura.

Files.isWritable presta attenzione agli ACL ma per qualsiasi motivo (per mantenere i programmi interrotti non funzionanti?) Hanno lasciato File.canWrite non risolto. Questo risulta essere fortunato, perché in alcune situazioni sembra che possa restituire false anche quando è possibile aprire il file senza problemi.

Davvero, vorrei riassumere i metodi come questo:

• File.canWrite a volte restituisce true quando non si può effettivamente scrivere sul file.
• Files.isWriteable a volte restituisce false quando è possibile scrivere sul file.

Non sono sicuro di quale sia il punto di entrambi i metodi in questo momento. Dal momento che tutti coloro che li utilizzano, alla fine, devono scrivere un equivalente non-broken che in realtà tenta di aprire il file, ci si chiede perché non hanno semplicemente aperto il file per fare il controllo da soli.

Answer 3

C'è un errore in java.nio.file.Files.isWritable sotto windows: non prenderà in considerazione le autorizzazioni implicite. java bug #7190897