Kill erreur 70 Permission denied

Question

Bonjour, 
Je ne comprends pas pourquoi sur certains PC j'obtiens parfois une erreur 70 sur ceci

Dim oFile As New Scripting.FileSystemObject
If oFile.FileExists(BakFile) Then Kill BakFile
BakFile est OK sinon il n'essaierai pas de la supprimer.
Que puis-je faire pour éviter cette erreur ?

NHenry · Answer

Où se situe le fichier ?

Herve_be · Answer

Bonjour,
J'ai remplacé kill par
Dim oFile As New Scripting.FileSystemObject
DeleteFile = oFile.FileExists(sFullPath)
If DeleteFile Then oFile.DeleteFile (sFullPath)

même chose : Erreur : 70 : Permission denied

Mes excuses NHenry, je n'avais pas vu ta question, ici
C:\ReefTools\VerCheck.par

Whismeril · Answer

Bonjour

selon les options de sécurité tout ce qui est sur C est protégé sauf ce qui se trouve dans AppData.

Tu peux donc essayer de mettre tes données ailleurs sur les PC où ça ne marche pas

Herve_be · Answer

Bonjour,
Que pourrait faire l'utilisateur pour "déprotéger" le répertoire qu'il a lui-même créé ?

vb95 · Answer

Bonjour 
Pourquoi ne pas utiliser comme base de chemin la variable Environ$("APPDATA") qui permet d'accéder au répertoire des applications comme dit Whismeril  .
Et faire de façon que l'utilisateur crée le répertoire dans le répertoire  donné par la fonction Environ$("APPDATA")
Ce qui donnerait

Dim RepertoireApplication as String
RepertoireApplication = Environ$("APPDATA") & "\ReefTools\"

Herve_be · Answer

Bonjour,
Les utilisateurs ont le choix du répertoire lors de l'installation comme ceci
Dim objFolder, objShell
Set objShell = CreateObject("Shell.Application")
Set objFolder = objShell.BrowseForFolder(0, "Sélectionner un répertoire", 1, "")

je pourrais utiliser Environ$("APPDATA") comme dernier paramètre mais
The user cannot browse higher in the tree than this folder.
Je viens d'essayer, Environ$("APPDATA") contient "C:\Users\RCL\AppData\Roaming"
pourquoi Roaming ?
j'ai une autre erreur lors de la création d'un répertoire dans ce répertoire :
"Cette action ne peut pas être réalisée car le dossier est ouvert dans un autre programme" !

D'une part sur plus de 4.800 utilisateurs, la plupart du temps ça fonctionne.
J'avais de temps en temps une erreur 70 sur "Kill" que j'ai remplacé par FSO .DeleteFile
qui semblait fonctionner jusqu'à ce que j'aie à nouveau une erreur 70.

Je ne peux pas demander aux 4.800 utilisateurs de déplacer le logiciel.
Que faire pour les rares utilisateurs qui rencontrent ce problème ?

vb95 · Answer

Bonjour Herve_be
Ne confondrais-tu pas répertoire d'installation de l'application et répertoire des DATA d'une application  ?
Pour une installation propre sous Windows le répertoire d'installation est généralement C:\Program Files .
 Environ$("APPDATA") contient "C:\Users\RCL\AppData\Roaming"
pourquoi Roaming ? C'est tout à fait normal .

Local et LocalLow sont réservés au système d'exploitation . Roaming est le répertoire des DATA réservé à l'utilisateur .
Maintenant que faire ?

Herve_be · Answer

Bonjour,
Je conseille aux utilisateurs de créer un répertoire pour l'application à la racine de C:
Depuis que cette application existe (2003) j'ai toujours mis les données organisées en sous répertoires dans le même répertoire que l'application, et tout fonctionne très bien,
à de très rares exceptions près où il y a un problème d'accès.
Chambouler cette organisation pour 4.800 utilisateurs n'est pas une solution acceptable.
Est-il vraiment compliqué pour ces quelques utilisateurs qui rencontrent ce problème de supprimer cette restriction d'accès ?

Whismeril · Answer

Je ne suis pas sûr que ça vienne de ça, le seul moyen simple à ma connaissance c'est d'essayer un autre répertoire que Microsoft laisse "libre" (AppData, Mes Documents).

W10 qui n'existait pas en 2003 est très restrictif, et je ne suis pas spécialiste de la sécurité sous windows et encore moins de cet OS.
W8 j'en sais rien jamais eu
W7 c'était déjà possible de restreindre les droits

vb95 · Answer

Bonjour 
Entre 2003 et maintenant Windows a bien changé .
Et de plus VB6 n'est plus mis à jour par Microsoft depuis 2008 je crois .
Le mieux serait de passer à VB Net en dernière version . Ce n'est que mon avis .
C'est toi qui vois !

Herve_be · Answer

"le seul moyen simple à ma connaissance c'est d'essayer un autre répertoire que Microsoft laisse "libre""
Le problème se produisant de façon occasionnelle (chez 2 utilisateurs sur 4800 depuis juin), essayer un autre répertoire n'est pas si simple.

"Le mieux serait de passer à VB Net"
J'ai déjà envisagé cette possibilité, les "convertisseurs" ne fonctionnent pas, il faudrait complètement réécrire toute l'application, c'est au delà de mes possibilités.

Herve_be · Answer

Bonjour,
Le fait d'exécuter le programme en mode administrateur ne résoudrait-il pas le problème ?

vb95 · Answer

Très bonne idée à laquelle personne n'avait pensé
Reste à tester !

Herve_be · Answer

Bonjour,
Pas facile de contraindre les utilisateurs à travailler en mode admin, on a tellement l'habitude de cliquer sur un .exe ... donc j'ai à nouveau le problème : erreur 70 sur kill.
Voyons les choses autrement.

Je souhaite télécharger un fichier en étant certain que, si je n'y parviens pas, je garde l'ancienne version.
Je procède comme ceci : le fichier que j'essaye d'obtenir doit s'appeler xxx.par
je télécharge le fichier en l'appelant xxx.bak
si le téléchargement a fonctionné
- je supprime xxx.par <= c'est là que ça coince
- je copie xxx.bak dans xxx.par
- je supprime xxx.bak

Je peux donc télécharger un fichier mais pas supprimer l'ancien !
Voyez-vous une autre manière de faire pour ne pas supprimer xxx.par ?
Merci

Whismeril · Answer

Peut-être faut il 2 logiciels.

Au moment où tu effectues cette mise à jour, le logiciel principal lance le secondaire et s’éteint => normalement plus d’accès au fichier.

Le logiciel secondaire effectue le téléchargement, supprime l'ancien fichier, renomme  le nouveau, relance le logiciel principal et s’éteint

Herve_be · Answer

Pourquoi un autre logiciel aurait-il plus de chance dans la suppression du fichier ?

Je cherche une méthode différente de la mienne pour télécharger une nouvelle version d'un fichier.

Herve_be · Answer

Que pensez-vous de remplacer
- je supprime xxx.par <= c'est là que ça coince
- je copie xxx.bak dans xxx.par
par l'API CopyFile qui permet d'écraser le fichier destination donc d'éviter de le supprimer avant ?

Whismeril · Answer

Pourquoi un autre logiciel aurait-il plus de chance dans la suppression du fichier ? 
Je connais 2 raisons principales pour lesquelles il est interdit de supprimer un fichier

c’est un fichier protégé pour une raison ou une autre, je pense qu’on a écarté cette hypothèse
un logiciel a la main dessus, en l’occurrence probablement ton logiciel. Quand tu fais un « close file », ça n’arrive pas toujours de suite, je suppose que pour windows c’est pas prioritaire, et il faut éventuellement mettre à jour des métadonnées (taille, date de modification, etc...) et il y a toujours la possibilité que de la façon dont l’utilisateur ait agit sur le logiciel (un enchaînement que tu n’as pas imaginé par exemple) le fichier soit toujours en lecture. En éteignant le logiciel, tu n’as plus accès au fichier (sauf dans certains cas de multi thread) et tu obliges windows à « lâcher » le logiciel

D’autre part, si tu n’as pas le droit de supprimer, tu n’auras pas le droit d’écraser non plus.

Herve_be · Answer

- c’est un fichier protégé pour une raison ou une autre, je pense qu’on a écarté cette hypothèse
Je pense au contraire que c'est l'hypothèse la plus probable, je n'ai pas vu où "on" l'aurait écartée; la difficulté est de savoir comment il serait protégé et surtout comment le déprotéger.

- un logiciel a la main dessus, en l’occurrence probablement ton logiciel.
La première chose que le logiciel fait est télécharger ce fichier qui contient des paramètres, le lire puis le fermer; il ne l'ouvre plus ensuite; à moins que 2 cessions soient démarrées pratiquement simultanément je ne vois pas ce qui pourrait monopoliser ce fichier.

- si tu n’as pas le droit de supprimer, tu n’auras pas le droit d’écraser non plus.
Peut-être mais le logiciel ne se plantera pas.
Dans la doc de l'API CopyFile je lis qu'on peut, en cas d'erreur, appeler  GetLastError (Visual Basic:  Applications should call err.LastDllError instead of GetLastError) pour savoir où est le problème et le communiquer via msgbox.
Actuellement l'utilisateur reçoit Erreur 70 : Permission denied et le logiciel s'arrête, il est bien avancé !

Herve_be · Answer

Je viens d'essayer d'ouvrir le fichier avant de l'écraser
FileNum = FreeFile: Open ParFile For Output As #FileNum
lRet = CopyFile(BakFile, ParFile, False)lRet = 1 donc la copie fonctionne !

Whismeril · Answer

Et bien tu as peut-être ta solution.

Xav · Answer

Salut Hervé,

Tu peux envisager de placer ton code en début d’exécution de l’exécutable, ce qui fera la mise à jour lors du démarrage du programme... au car où le fichier téléchargé est présent. 
Est n'oublie pas la commande "Reset" qui purge les "handle"s de fichiers déjà ouverts.

Sinon, la solution de la boucle sur l'erreur avec un burinage en cas d'erreur, n'est pas envisageable, cas cela provoque parfois des gels de l'application, pour divers raisons (Anti-virus, téléchargement en attente...)

Donc, pour plus de sécurité, tu télécharges deux fichiers, la mise à jour "PAR" et un tout petit fichier de validation juste après le premier, l'un après l'autre.
Si le second est présent, c'est que le premier est entièrement téléchargé, tu peux donc renommer ton fichier téléchargé car complet.

Tu ne testeras que ce fichier de quelques octets qui te dira si la mise à jour est prête à être installée, puis tu effaces.

Tu peux même mettre la version de la mise à jour dans ce petit fichier... le principale, c'est qu'il soit téléchargé après le plus gros.

JeuDuTaquin..

Herve_be · Answer

Bonjour,
Le téléchargement de ce fichier de paramètres a lieu tout au début du programme.
Je retiens l'astuce du second fichier pour savoir si le premier est complètement téléchargé.
Mais je vais toujours essayer l'API CopyFile qui écrase le fichier destination
ce qui évite de devoir le supprimer (c'est cette suppression qui pose problème).

Kill erreur 70 Permission denied

23 réponses

Votre réponse

Discussions similaires