Kill erreur 70 Permission denied

Herve_be
Messages postés
947
Date d'inscription
mercredi 4 août 2010
Statut
Membre
Dernière intervention
8 avril 2022
- 10 juin 2020 à 12:01
Herve_be
Messages postés
947
Date d'inscription
mercredi 4 août 2010
Statut
Membre
Dernière intervention
8 avril 2022
- 4 sept. 2020 à 11:38
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

NHenry
Messages postés
14930
Date d'inscription
vendredi 14 mars 2003
Statut
Modérateur
Dernière intervention
27 mai 2022
161
10 juin 2020 à 17:23
Où se situe le fichier ?
0
Herve_be
Messages postés
947
Date d'inscription
mercredi 4 août 2010
Statut
Membre
Dernière intervention
8 avril 2022
2
8 août 2020 à 11:07
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
0
vb95
Messages postés
2639
Date d'inscription
samedi 11 janvier 2014
Statut
Modérateur
Dernière intervention
27 mai 2022
151
10 août 2020 à 16:01
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 .
0
Whismeril
Messages postés
17349
Date d'inscription
mardi 11 mars 2003
Statut
Modérateur
Dernière intervention
28 mai 2022
596
8 août 2020 à 11:38
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
0
Herve_be
Messages postés
947
Date d'inscription
mercredi 4 août 2010
Statut
Membre
Dernière intervention
8 avril 2022
2
8 août 2020 à 15:15
Bonjour,
Que pourrait faire l'utilisateur pour "déprotéger" le répertoire qu'il a lui-même créé ?
0
Whismeril
Messages postés
17349
Date d'inscription
mardi 11 mars 2003
Statut
Modérateur
Dernière intervention
28 mai 2022
596
8 août 2020 à 15:37
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?
0

Vous n’avez pas trouvé la réponse que vous recherchez ?

Posez votre question
vb95
Messages postés
2639
Date d'inscription
samedi 11 janvier 2014
Statut
Modérateur
Dernière intervention
27 mai 2022
151
Modifié le 8 août 2020 à 16:54
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\"


0
Herve_be
Messages postés
947
Date d'inscription
mercredi 4 août 2010
Statut
Membre
Dernière intervention
8 avril 2022
2
Modifié le 9 août 2020 à 10:26
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 ?
0
vb95
Messages postés
2639
Date d'inscription
samedi 11 janvier 2014
Statut
Modérateur
Dernière intervention
27 mai 2022
151
Modifié le 9 août 2020 à 14:59
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 ?

0
Herve_be
Messages postés
947
Date d'inscription
mercredi 4 août 2010
Statut
Membre
Dernière intervention
8 avril 2022
2
10 août 2020 à 09:55
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 ?
0
Whismeril
Messages postés
17349
Date d'inscription
mardi 11 mars 2003
Statut
Modérateur
Dernière intervention
28 mai 2022
596
10 août 2020 à 12:17
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

0
vb95
Messages postés
2639
Date d'inscription
samedi 11 janvier 2014
Statut
Modérateur
Dernière intervention
27 mai 2022
151
10 août 2020 à 14:49
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 !
0
Herve_be
Messages postés
947
Date d'inscription
mercredi 4 août 2010
Statut
Membre
Dernière intervention
8 avril 2022
2
Modifié le 10 août 2020 à 18:36
"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.
0
Herve_be
Messages postés
947
Date d'inscription
mercredi 4 août 2010
Statut
Membre
Dernière intervention
8 avril 2022
2
12 août 2020 à 16:38
Bonjour,
Le fait d'exécuter le programme en mode administrateur ne résoudrait-il pas le problème ?
0
vb95
Messages postés
2639
Date d'inscription
samedi 11 janvier 2014
Statut
Modérateur
Dernière intervention
27 mai 2022
151
12 août 2020 à 18:24
Très bonne idée à laquelle personne n'avait pensé
Reste à tester !
0
Herve_be
Messages postés
947
Date d'inscription
mercredi 4 août 2010
Statut
Membre
Dernière intervention
8 avril 2022
2
1 sept. 2020 à 11:19
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
0
Whismeril
Messages postés
17349
Date d'inscription
mardi 11 mars 2003
Statut
Modérateur
Dernière intervention
28 mai 2022
596
1 sept. 2020 à 11:27
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
0
Herve_be
Messages postés
947
Date d'inscription
mercredi 4 août 2010
Statut
Membre
Dernière intervention
8 avril 2022
2
1 sept. 2020 à 12:09
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.
0
Herve_be
Messages postés
947
Date d'inscription
mercredi 4 août 2010
Statut
Membre
Dernière intervention
8 avril 2022
2
1 sept. 2020 à 13:56
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 ?
0
Whismeril
Messages postés
17349
Date d'inscription
mardi 11 mars 2003
Statut
Modérateur
Dernière intervention
28 mai 2022
596
1 sept. 2020 à 14:33
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.

0
Herve_be
Messages postés
947
Date d'inscription
mercredi 4 août 2010
Statut
Membre
Dernière intervention
8 avril 2022
2
1 sept. 2020 à 15:59
- 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é !
0
Herve_be
Messages postés
947
Date d'inscription
mercredi 4 août 2010
Statut
Membre
Dernière intervention
8 avril 2022
2
1 sept. 2020 à 16:22
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 !
0