Client lourd Swing et default permissions

Bonjour,

J'ai fait un applicatif en Swing (j'ignore si le terme "applicatif" est le bon) il manipule des fichiers (renommage et suppression/copies).

En local, avec les fichiers du filesystem, tout fonctionne bien. J'en ai déduis que java utilisait les droits du user qui lançait l'application (si l'utilisateur a des droits sur un répertoire alors mon application java aussi).

J'ai voulu utiliser mon application pour agir sur un serveur de fichier de mon réseau. L'utilisateur a bien les droits sur le répertoire distant.

Par contre java refuse de renommer/supprimer les fichiers sur le réseau.

Je ne connais pas du tout ces histoires de droits. Et je le découvre sur le tard.
J'ai juste besoin de confirmations pour voir si je pars dans la bonne direction concernant mes recherches.

Suis-je confronté à des limites fixées par les default policy de java ?
Interdiction d'agir sur un répertoire distant par exemple.

Lorsque mon application manipule des fichiers, cela fonctionne t'il bien comme je l'ai supposé ?
C'est à dire droit de l'utilisateur + default policies

J'ai l'intention d'étendre les droits de mon application (il y aurait une classe policy). Est-ce que je pars sur la bonne voie ou mon problème viendrait juste des droits sur la machine distante (Je rappelle que mon utilisateur peut créer et supprimer des fichiers sur cette machine distante)?

(Pour information je suis dans un environnement Windows xp/vista)

J'ai juste besoin d'un peu d'orientation. Je découvre cette problématique d'un bloc, je suis un peu paumé. Je ne sais pas si cette histoire de policy est la bonne piste.

Merci d'avance.

edit: correction de quelques erreurs.

Citation:

---

Envoyé par herotic

Par contre java refuse de renommer/supprimer les fichiers sur le réseau.

---

Quel est l'erreur ?

et plus important encore, qu'utilise tu pour te connecter en distant à cette machine?

Citation:

---

et plus important encore, qu'utilise tu pour te connecter en distant à cette machine?

---

Rien de spécial. J'utilise JFileChooser pour consulter un lecteur réseau. Désolé si je n'étais pas clair sur ce point dans mon premier message. Je passe donc entièrement à travers l'explorateur de Windows.

L'erreur viendrait de File.renameTo() elle n'est pas garantie de fonctionner si j'en crois la JavaDoc :

java.io.File

Citation:

---

Many aspects of the behavior of this method are inherently platform-dependent: The rename operation might not be able to move a file from one filesystem to another, it might not be atomic, and it might not succeed if a file with the destination abstract pathname already exists. The return value should always be checked to make sure that the rename operation was successful.

---

J'ai ajouté des contrôles vérifiant l'existence du fichier, que je sauvegarde dans un autre File, je supprime le fichier existant puis crée un nouveau avec le nom qui m’intéresse. Je pensais contourner le problème mais ça ne marche pas plus.

renameTo() marche sur mon Windows 7, sur mon filesystem local.
Il ne marche pas sur un poste Windows XP du réseau.
Et je ne peux pas accéder à un lecteur réseau depuis ce Windows XP.

Je regarde des frameworks qui pourraient me garantir le fonctionnement de ces fonctionnalités (renommer/supprimer/copier un fichier)

edit : du coup je pense que ce problème de renameTo() a déjà été traité dans le forum. Sur le coup il y avait beaucoup de choses nouvelles à intégrer pour moi.

il s'agit d'un montage réseau (mappé vers une lettre de lecteur) ou d'un File avec un nom du style \\machine\dosssier partage\blablabla?

Dans le second cas, tu aura plus de chance je pense de travailler avec la librairie JCIFS pour gérer le protocole de partage windows directement.

Citation:

---

il s'agit d'un montage réseau (mappé vers une lettre de lecteur) ou d'un File avec un nom du style \\machine\dosssier partage\blablabla?

---

Et bien c'est un chemin du style \\machine\dosssier partage\blablabla? qui est monté en lecteur.
Je ne connais vraiment rien à ces histoires de réseau Windows.

J’accède au lecteur F qui monte un partage de la forme \\machine\dosssier partage\blablabla

JCIFS est-t'il toujours d'actualité ?

J'ai lu que quelqu'un conseillait commons.io.

C'est ce sur quoi je me concentrais depuis hier.

Merci en tout cas pour les réponses, je suis moins paumé qu'au début là.

que je sache commons io n'a rien à vous avec les protocoles réseau.

Commons.io ne fonctionne pas en effet (Je pensais vraiment que le problème venait de java.io).

Mais je ne comprends pas pourquoi mon problème est lié à des protocoles réseau. Je manipule le filesystem de Windows, s'il monte un lecteur réseau, n'est t'il pas censé s'occuper de tout pour moi ?

Si je comprends bien ce que je dois faire :

Avant de renommer/supprimer etc je dois m'assurer si je suis sur le filesystem local ou sur un disque dur distant.

Si j'suis en local j'utilise File.renameTo() etc
Si je suis sur un lecteur distant j'utilise JCIFS

Suis-je sur la bonne piste ou j'suis encore dans les choux pour cerner mon problème ?

Le problème c'est surtout l'api File de java qui est assez catastrophique quand il s'agit de te remonter les cause d'erreur :)

Oui le filesystem devrait tout gérer pour toi, mais comme java refuse de dire ce qui foire (droit d'acces, lecture seule, coupure réseau, verrou, ...).


Si tu utilise java 7, regarde plutotdu coté de java.nio avec toutes ses nouvelles méthodes de gestion des fichiers:

http://docs.oracle.com/javase/7/docs...CopyOption...)

Quel serait le mieux finalement?

Passer à java7 ou utiliser JCIFS comme tu me l'a conseillé plus tôt ?

Je pense que java7 me permettrait d'aller plus vite. Sans compter que je ne connais rien à ce fameux protocole Windows.

En espérant effectivement que cela m'assure que mes renommages de fichiers fonctionne ^^

ben test, l'upgrade de la version de java, c'est pas du perdu :)

Je viens de passer en java7. Effectivement maintenant j'ai des messages d'erreur qui ont du sens pour moi.

Citation:

---

java.nio.file.FileSystemException: Y:\test\toto.pdf: Le processus ne peut pas accéder au fichier car ce fichier est utilisé par un autre processus.

---

Et en effet dans mon application java je fais un aperçu du fichier. Voilà pourquoi, je suppose, il n'est pas capable de renommer le fichier.

Voila probablement mon erreur.

edit: étrange car en local cela ne posait aucun problème.