Bonjour à tous et toutes, je viens demandé votre aide pour un ptit problème qui me turlupine.
Je vous explique, je voudrais tester si un répertoire existe avant de m'y placer dedans.
Mon logiciel tourne à un endroit particulier et le répertoire ou je voudrais être n'est bien sûr pas un sous dossier à côté du logiciel.

Je fais donc un Directory.exist("C:\\FTP\\" ) (ou même Directory.exist("C:\\FTP" ) , un dossier qui existe bien sur C: mais il me répond que ce dossier n'existe pas.  

Si je ne teste pas exprès et que j'essaie de m'y placer, il lève une exception et en fait je me rend compte qu'il fait:

...\Chemin_vers_mon_application\C:\FTP

On fait comment donc pour tester plus haut dans l'arborescence (pas question de faire des .. pour remonter je ne sais pas ou sera l'application)??? C'est bizarre que le .net ne sache pas interpréter un chemin absolue et pas relatif.

Hum à priori faudrait un @
http://msdn.microsoft.com/en-us/li [...] ctory.aspx

Moué ça marche pas plus, si je fais un directory.exist avec le @ devant ça ne marche pas plus...

EDIT: je ne comprends vraiment pas.
Je fais précisément ça:
http://msdn.microsoft.com/en-us/li [...] ctory.aspx

Et chezmoiçamarchepas.com
Pourtant je suis sûr du chemin d'accès puisque je vais dans le dossier depuis l'explorateur et je le récupère avant de le coller. Mais qu'est ce qui bloque

et avec "file:///c:/FTP" ?
 
ça change rien?

Pour un répertoire?

EDIT: Testé non ça change rien

ah... le con :(
edit1: remarque, y'a pas de raisons que ça fonctionne pas: si tu tappes  
file:///c:/FTP dans la barre d'adresse de l'explorer... ça t'affiche le dossier
edit2: merde :(

Ben j'ai testé dans le programme ça ne marche pas
affiche_Console(Directory.Exists(@"file:///C:\FTP" ).ToString()); ==> m'affiche false

Mon programme est éxécuté depuis T ça ne pose pas de problème que je sache non plus? Si c'était convenablement bien construit...
Edit j'ai testé avec un répertoire qui existe dans T c'est pareil...

c'est pas un probleme de droit? peut etre que le programme ne prend pas l'utilisateur courant comme identité, et que cette identité n'a pas les droit sur c: ? ça m'est déjà arrivé sur des appli web (l'identité monlogin\ASPNET n'avait pas d'autorisations...)

Ben c'est pas ce qu'il me dit en tout cas. Je me prends déjà la tête avec les truc de sécurité sur Vista, mais là j'ai mis programme de confiance dans le projet et droit de tout exécuter.
Et je viens de tester: Exécuté en temps qu'administrateur, idem ça me répond false.

Je vois vraiment pas quoi faire.

Edit: Merci déjà pour tes débuts d'aide.

tu as essayé dans un autre appli? genre, histoire de voir si ça se comporte comme ça pour tous tes programmes, ou pas
 
edit: pas de probleme, en ce moment je glande au taf

Ben je vois pas trop ce que ça changera.
Tous mes programmes sont développés en C# avec visual studio 2008 express, avec .net 3.5 d'installé et toutes les mises à jours.
Je peux rien faire de plus Et la seule info que j'ai c'est que pour lui le répertoire n'existe pas.
Mais il me semble que si je fais setcurrentDirectory en forçant il me lève une exception en me disant que blabla répertoire n'existe pas et le chemin, c'est "Le_chemin_de_mon_appli\ce_que_je_mets"

Alors là je ne comprends plus rien!
Si je fais un Directory.SetCurrentDirectory(@"C:\FTP" );

EDIT: en gros sans le set:

La même chose mais avec le set:

Edit: ah non c'est normal c'est moi qui est mis ce message d'erreur lors du catch.
Donc en gros le Set ne marche pas.

L'erreur est bien une question de droit encore:
" Échec de la demande d'autorisation de type 'System.Security.Permissions.SecurityPermission, mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089'"
Je fais comment moi. C'est vraiment le bordel vista niveau droits

franchement, avec vista... je sais pas trop
désolé

Je vais voir ce qu'il me dit sous XP.
Edit: MÊme message...

là ça devient louche.
regarde les autorisations sur le répertoire c:FTP (voire sur C, et regarde qui 'pilote' ton appli (System.Security.WindowsIdentity.GetCurrent() ... ou un truc dans le genre), c'est la seule piste que j'entrevois

Je vais regarder.  
Par contre si j'exécute mon application depuis visualStudio en mode débug (F5 tout cours quoi) ça marche. Mais dès que je fais CTRL+F5 donc mode normal ou que j'exécute directement l'exécutable paf.

System.Security.WindowsIdentity.GetCurrent() y a pas

EDIT: j'ai trouvé comment faire.
EDIT2: je peux pas le faire je me prends la même exception quand je l'éxécute normalement sans débugage.

au final, c'est pas System.Security c'est System.Principal désolé.
Franchement, je n'ai aucune idée de là ou ça peux venir. Je ne suis pas assez calé sur les différences que peuvent engendrer une compilation en debug par rapport a release. Surtout à propos de gestion de droits. Peut etre que, lorsque tu lances en mode debug, le programme hérite des memes droits que VS, alors qu'en le lançant en release, il en prend un autre, avec moins d'autorisations. Enfin je dis ça... j'en sais absolument rien !

Si ça doit être ça mais je comprends pas pourquoi en exécutant en temps qu'administrateur ça ne passe pas.
Merci pour ton aide.

Mais le truc c'est que même en exécutant mon programme compilé depuis vista, depuis un compte administrateur sous xp, ça ne passe toujours pas.

Risque pas de marcher ton code avec string et existe dans le try.
Enfin bon en arrangeant ce petit détail j'ai droit à:

Sans rajouter les droits dans le projet. Bon maintenant je les rajoutes.

En mode débug:
Rien d'affiché, en mode exécution normal ==> même problème que plus haut.
Les droits ne sont pas rajouté au programme en soit, c'est là que je ne comprends pas.

Ah effectivement j'avais déjà eu ce genre de problème, ça doit effectivement venir de ça. Mais reste à voir si depuis C:, je peux écrire dans T et autre lecteur virtuel
 
 
Bon je viens de tester, effectivement c'était ça!
Et bien vraiment super pratique ce truc. Je capte pas trop pourquoi ça fait quoi Me reste plus qu'a espérer que je puisse quand même écrire dans T ou tout lecteur partagé....
 
Merci beaucoup pour ton aide!
 
Et merci aussi à Marty_McFly.