Discussion :

[Bkoss]

Bonjour à tous,

Je sais que c'est assez contraire aux principes d'un forum, mais je me permets de créer un doublon d'un post que je pensais cohérent à la section Windows. A priori, le point de vue d'un programmeur JAVA est également essentiel à ce cas, car peut être l'un d'entre vous a déjà rencontré ce cas de figure. Voici le dit post (http://www.developpez.net/forums/d11...riete-disques/) :

Ma question est à la fois simple est compliquée =)
Je cherche à récupérer le type d'un disque (en JAVA notamment) pour construire une liste des disques amovibles connectés à l'ordinateur quelle que soit la langue d'installation de Windows.
Je m'explique, lorsque vous êtes dans l'explorateur et que vous ouvrez les propriétés d'un disque, vous obtenez ceci :



Le champ entouré en rouge est la valeur qui m'intéresse, car je suis capable de la récupérer dans mon programme. Pour savoir si le disque est bien amovible, je compare ce champ à une valeur (="Disque Amovible") que je crée moi même.

Or je veux m'affranchir de créer moi même cette valeur de comparaison car je suis limité à mon propre champ de langues, et surtout à l'alphabet latin. Mon but est de pallier à cela en récupérant si elle existe, par exemple un clé de registre, un valeur dans une DLL, qui a cette valeur par défaut. Ma question est donc : quelqu'un sait-il où Windows va chercher cette valeur?

Côté technique j'utilise File.listRoots() et je parcours cette liste en comparant la description de chaque File (FileSystemView.getSystemTypeDescription(file)) à deux String que je déclare comme valant "Removable disk" et "Disque amovible". Je suis donc limité à anglais et français. Cela ne fonctionnera pas sur un OS d'une autre langue.

[CheryBen]

Salut, je ne crois pas que ce soit possible de récupérer cette information directement en java.

Je vois 2 solutions :
1 - écrire toi même une dll qui appellera la méthode GetDriveType de l'api windows. Tu pourras appeler cette dll grâce à jni.
2 - en java, tu récupères le type du lecteur C: grâce à ta méthode précédente, et ensuite tu compares cette valeur avec les autres disques. Ce n'est pas optimale car tu dois connaitre à l'avance la lettre d'un lecteur local, le lecteur C: n'est pas forcément local. Mais cela pourrait être un paramètre de ton application. Ou en utilisant new File() tu récupèreras le répertoire d'exécution de ton application, la plupart du temps c'est un disque local...

[tchize_]

Si tu ne vise que du windows, pour moi le plus simple est d'utiliser une api native, il est assez facile en se documentant un peu de charger un dll via jna.

[adiGuba]

Salut,

Si tu ne vise que du windows, pour moi le plus simple est d'utiliser une api native, il est assez facile en se documentant un peu de charger un dll via jna.

+1
A partir du moment où la librairie native utilises des types simples (pas de structures trop complexe), JNA et son "Direct Mapping" permet de faire cela en un rien de temps sans avoir à toucher la moindre ligne de code natif.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
public class Kernel32 {
	static {
		Native.register("Kernel32"); // nom de la librairie native
	}
 
	public static native int GetDriveTypeA(String rootPathName);
}

En plus on peut facilement cacher cela en private pour faire une joli surcouche Java plus propre



a++

[Bkoss]

Salut à tous !

Merci d'avoir pris le temps de me réponde. Effectivement j'ai pensé à ces solutions, mais nous aurions voulu éviter de faire appel à JNA ou une DLL perso. J'avais également regardé du côté de JNI si vous connaissez qui me semble être relativement sympa.

Je vais faire quelque chose de propre et je vous tiendrai au jus. J'ai cru comprendre que l'appli devra être portée sous UNIX à terme donc je risque de devoir faire autrement.

A plus et bonne journée

[tchize_]

La notion que vous cherchez à capter n'existe pas vraiment sous linux. De ce coté la vous allez devoir jouer avec les fichiers dans /proc pour analyser les disques, les partitions et leur point de montage.

[adiGuba]

Effectivement j'ai pensé à ces solutions, mais nous aurions voulu éviter de faire appel à JNA ou une DLL perso.

Malheureusement il s'agit d'une notion très spécifique à l'OS hôte, ce qui introduit donc du code natif à un moment où à un autre...

J'avais également regardé du côté de JNI si vous connaissez qui me semble être relativement sympa.

JNA permet surtout d'appeler directement le code natif, sans avoir à coder quoi que ce soit en natif... contrairement à JNI.

Je vais faire quelque chose de propre et je vous tiendrai au jus. J'ai cru comprendre que l'appli devra être portée sous UNIX à terme donc je risque de devoir faire autrement.

Je ne pense pas qu'il existe d'API commune pour cela, même en natif. Donc tu vas devoir avoir plusieurs implémentations (une par type de système supporté).


a++