TL;DR
Si vous souhaitez prendre en charge Windows, vous devez utiliser java.nio.file.Files.isWritable
.
Je ne connaissais rien à Internet, alors j'ai écrit une note pour moi-même.
Il est destiné au processus d'enregistrement de fichiers dans Java / Kotlin, en particulier au processus permettant à l'utilisateur de sélectionner un répertoire et de le sauvegarder.
Je parle de classes Java, mais comme j'ai fait Kotlin, l'exemple de source suit cela.
Il existe deux façons de vérifier. L'ancienne méthode et la méthode relativement nouvelle.
java.io.File.canWrite
java.nio.file.Files.isWritable
est une méthode d'instance de la bonne vieille classe java.io.File
.
est une méthode statique de classe relativement nouvelle ajoutée dans Java 1.7 appelée java.nio.file.Files
.
En premier lieu, la classe java.nio.file.Files
ne gère que les méthodes statiques.
On dit qu'il est plus sûr d'utiliser 2. pour Windows. J'expliquerai les détails ci-dessous.
java.io.File.canWrite Encore une fois, c'est une méthode d'instance.
Voici un exemple.
sample.kt
val file = File("Chemin de fichier arbitraire")
val canWrite = file.canWrite() //Vrai si inscriptible
Très facile.
Cela ne regarde que si le fichier a l'attribut accessible en écriture. Pour Linux, les autorisations dites Linux, et pour Windows, l'attribut en lecture seule des propriétés de fichier.
En d'autres termes, il n'est pas possible de vérifier si le processus Java en cours d'exécution a autorité sur le système d'exploitation. Plus spécifiquement, il ne prend pas en charge la vérification des autorisations Windows UAC. ** **
Par conséquent, si le répertoire ne peut pas être écrit sans les privilèges d'administrateur du système d'exploitation, comme directement sous le lecteur C, même si canWrite
est vrai, ʻIOException` sera lancée sans pitié lors de l'écriture du fichier, ce qui est un échec (processus Java). Bien sûr, ce n'est pas le cas si fonctionne avec des privilèges d'administrateur)
java.nio.file.Files.isWritable C'est là que cette méthode entre en jeu. Comment écrire est comme ça.
sample.kt
val file = File("Chemin de fichier arbitraire")
val canWrite = Files.isWritable(file.toPath()) //Vrai si inscriptible
Cela vérifiera si le processus Java dispose d'autorisations en écriture, y compris **. Ce qui suit est une citation de la documentation Oracle JDK. https://docs.oracle.com/javase/jp/8/docs/api/java/nio/file/Files.html#isWritable-java.nio.file.Path-
Cette méthode vérifie que le fichier existe et ** cette machine virtuelle Java dispose des privilèges appropriés pour permettre l'ouverture du fichier en écriture **.
Donc, ici, vous pouvez vérifier y compris UAC.
Par ailleurs, les autorisations de lecture et d'exécution peuvent être vérifiées de la même manière avec des méthodes telles que ʻisReadable et ʻisExecutable
.
D'après ce que j'ai vérifié, il n'y avait que des articles liés à l'UAC qui ont été perturbés par le programme d'installation à l'époque de Vista, et il n'y avait vraiment aucune information autre que la référence Oracle. N'est-il pas coincé ici de manière inattendue? Ou y a-t-il un petit nombre de cas d'applications natives en premier lieu? ??
J'espère que cela aide les gens qui sont coincés dans le même événement.
Recommended Posts