Lorsque j'essaie d'appeler System.IO.File.Encrypt() sur un fichier existant, il lève une exception d'E/S générique et le message est "Le paramètre est incorrect".File.Encrypt throwing "Le paramètre est incorrect"
System.IO.File.Encrypt ("C: \ Project \ StorageDirectory \ file.txt")
L'utilisateur actuel du processus est exécuté sous a un contrôle total sur le dossier "StorageDirectory" . Y a-t-il quelque chose qui me manque sur le plan des autorisations?
Le docs disent que cela pourrait être causé par
Une erreur E/S est survenue lors de l'ouverture la fichier. -ou- Cette opération n'est pas prise en charge sur la plate-forme actuelle.
Il se peut que le fichier soit verrouillé par un autre processus ou que vous ne soyez pas autorisé à le modifier. Vous pouvez exécuter ProcMon pendant que vous reproduisez cette erreur pour voir si c'est votre problème.
Je suppose que vous avez raison sur le fait que le fichier est verrouillé, mais par quoi, je ne sais pas. Je vais essayer votre suggestion. –
J'ai utilisé ProcMon, et d'après ce que j'ai vu, il a suggéré que l'utilisateur a besoin de certains droits sur le chemin entier. J'ai ajouté l'utilisateur au groupe d'administration local, mais j'ai toujours la même erreur. –
lecture bien the MSDN page,
Une erreur E/S est survenue lors de l'ouverture le fichier.
-ou-
Cette opération est pris en charge sur la plate-forme actuelle .
Il ne s'agit pas non plus d'une instruction particulièrement utile, mais elle devrait vous donner un point de départ.
Pouvez-vous lire le fichier? L'avez-vous testé depuis votre application?
Avez-vous effectué le chiffrement ailleurs? Je ne l'ai jamais vu le cryptage échouer comme ça avant (mais il y a toujours une première fois!)
Je vais donner une chance à votre suggestion. –
Juste essayé ... Je suis capable de lire les données du fichier juste avant d'essayer de crypter le fichier. –
Qu'en est-il de l'écriture? – Oli
Informations supplémentaires: J'utilise l'identité d'un utilisateur à ce bloc de code (l'usurpation d'identité fonctionne très bien) tout en faisant cela. En outre, puisque c'est ASP.NET, j'ai vérifié pour voir si l'utilisateur de service de réseau (aucune usurpation d'identité au niveau du code) a donné la même erreur, mais il a crypté le fichier très bien. –