Kill erreur 70 Permission denied

Signaler
Messages postés
823
Date d'inscription
mercredi 4 août 2010
Statut
Membre
Dernière intervention
20 septembre 2020
-
Messages postés
823
Date d'inscription
mercredi 4 août 2010
Statut
Membre
Dernière intervention
20 septembre 2020
-
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 ?

23 réponses

Messages postés
14725
Date d'inscription
vendredi 14 mars 2003
Statut
Modérateur
Dernière intervention
22 septembre 2020
144
Où se situe le fichier ?
Messages postés
823
Date d'inscription
mercredi 4 août 2010
Statut
Membre
Dernière intervention
20 septembre 2020
2
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
Messages postés
2236
Date d'inscription
samedi 11 janvier 2014
Statut
Contributeur
Dernière intervention
21 septembre 2020
114
bonjour
que ce soit
Kill
ou
oFile.DeleteFile
cela ne change rien car ils utilisent tous les 2 les mêmes APIS dans Kernell32.dll .
Messages postés
14778
Date d'inscription
mardi 11 mars 2003
Statut
Non membre
Dernière intervention
25 septembre 2020
435
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
Messages postés
823
Date d'inscription
mercredi 4 août 2010
Statut
Membre
Dernière intervention
20 septembre 2020
2
Bonjour,
Que pourrait faire l'utilisateur pour "déprotéger" le répertoire qu'il a lui-même créé ?
Messages postés
14778
Date d'inscription
mardi 11 mars 2003
Statut
Non membre
Dernière intervention
25 septembre 2020
435
Avant de bidouiller les options de sécurité de windows, faire un test ailleurs pour voir si ça vient de ça serait, il me semble, une bonne idée non?
Messages postés
2236
Date d'inscription
samedi 11 janvier 2014
Statut
Contributeur
Dernière intervention
21 septembre 2020
114
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\"


Messages postés
823
Date d'inscription
mercredi 4 août 2010
Statut
Membre
Dernière intervention
20 septembre 2020
2
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 ?
Messages postés
2236
Date d'inscription
samedi 11 janvier 2014
Statut
Contributeur
Dernière intervention
21 septembre 2020
114
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 ?

Messages postés
823
Date d'inscription
mercredi 4 août 2010
Statut
Membre
Dernière intervention
20 septembre 2020
2
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 ?
Messages postés
14778
Date d'inscription
mardi 11 mars 2003
Statut
Non membre
Dernière intervention
25 septembre 2020
435
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

Messages postés
2236
Date d'inscription
samedi 11 janvier 2014
Statut
Contributeur
Dernière intervention
21 septembre 2020
114
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 !
Messages postés
823
Date d'inscription
mercredi 4 août 2010
Statut
Membre
Dernière intervention
20 septembre 2020
2
"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.
Messages postés
823
Date d'inscription
mercredi 4 août 2010
Statut
Membre
Dernière intervention
20 septembre 2020
2
Bonjour,
Le fait d'exécuter le programme en mode administrateur ne résoudrait-il pas le problème ?
Messages postés
2236
Date d'inscription
samedi 11 janvier 2014
Statut
Contributeur
Dernière intervention
21 septembre 2020
114
Très bonne idée à laquelle personne n'avait pensé
Reste à tester !
Messages postés
823
Date d'inscription
mercredi 4 août 2010
Statut
Membre
Dernière intervention
20 septembre 2020
2
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
Messages postés
14778
Date d'inscription
mardi 11 mars 2003
Statut
Non membre
Dernière intervention
25 septembre 2020
435
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
Messages postés
823
Date d'inscription
mercredi 4 août 2010
Statut
Membre
Dernière intervention
20 septembre 2020
2
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.
Messages postés
823
Date d'inscription
mercredi 4 août 2010
Statut
Membre
Dernière intervention
20 septembre 2020
2
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 ?
Messages postés
14778
Date d'inscription
mardi 11 mars 2003
Statut
Non membre
Dernière intervention
25 septembre 2020
435
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.

Messages postés
823
Date d'inscription
mercredi 4 août 2010
Statut
Membre
Dernière intervention
20 septembre 2020
2
- 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é !
Messages postés
823
Date d'inscription
mercredi 4 août 2010
Statut
Membre
Dernière intervention
20 septembre 2020
2
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 !