Le file.copy du fso est-il plus sur que le Filecopy ?Résolu

Question

Bonjour,
j'utilise un petit serveur NAS (de la Cie) que je partage sur plusieurs machines dont une de test et sur lequel j'installe mes applications pour les tester en réseau. Ce serveur semble "perdre un peu le pédales" depuis quelque temps, sans doute du fait du trop grand nombre de (petits) fichiers dans la FAT. Bref, rien de bien gênant (si ce n'est qu'il n'est plus capable de m'afficher les fichiers dans l'ordre habituel, c'est à dire les répertoires en premier puis les fichiers : répertoires et fichiers sont mélangés et apparaissent dans l'ordre alphabétique - un répertoire perdu au milieu des fichiers).
Ce qui est plus embêtant, c'est que, sur ma machine de test qui est sous XP familial (mais pas sur ma machine de développement qui est sou XP Pro), mes programmes plantent désormais chaque fois qu'est rencontré un Filecopy (alors que jusqu'à présent tout allait bien).
Une erreur 53 est renvoyée. A noter que le fichier est tout de même copié (le plantage s'effectue en sortie de traitement mais je suis certain que ce n'est pas sur les lignes suivantes puisque j'ai ajouté un msgbox juste après la copie et il n'est pas exécuté). Je pourrais bien sûr mettre un traitement d'erreur mais j'ai plutôt essayé d'utiliser le fso (je sais, ça ne plaira pas à  EBArtSoft !) et là... plus de problème ! J'ai d'ailleurs écrit une petite fonction pour remplacer facilement tous mes filecopy :
Public Sub CopieFic(ByVal Ch_NomficSource$, ByVal Ch_NomficDestination$)
    Dim fso, nomfic
    Set fso = CreateObject("Scripting.FileSystemObject")
    Set nomfic = fso.GetFile(Ch_NomficSource$)
    nomfic.Copy (Ch_NomficDestination$)
    Set fso = Nothing
End Sub
Les questions sont donc : quelqu'un a-t-il déjà rencontré ce type de problème sur FileCopy (ou Kill) ?
Le fso garantit-il une meilleure compatibilité avec les SE qui gèrent les serveurs réseaux (ce qui dans la situation particulière dans laquelle se trouve mon serveur NAS semble être le cas) ?

JMC70

PCPT · Accepted Answer

précision importante : NTFS uniquement !

explication de l'utilisation de l'outil ici :
http://www.commentcamarche.net/faq/sujet-2785-windows-xp-familial-rajouter-l-onglet-securite-manquant

PCPT · Answer

salut,

en effet sous win xp HOME il faut ajouter l'onglet sécurité pour palier à ce bug

l'outils adéquat pour ce faire :

ftp://ftp.microsoft.com/bussys/winnt/winnt-public/tools/scm/scesp4i.exe




++

<hr size="2" width="100%" />
Prenez un instant pour répondre à [sujet-SONDAGE-POP3-POUR-CS_769706.aspx ce sondage] svp

JMC70 · Answer

Merci à PCPT. Effectivement l'onglet de sécurité n'apparaît pas sur cette machine de test.
Il est cependant difficile de demander aux utilisateurs d'ajouter systématiquement le correctif scesp4i, c'est pourquoi  j'ai préféré passer par le fso pour la copie. Comme je devais corriger les sources, j'ai fait de même pour le "kill" sans être certain que ce soit indispensable.
Mon post est davantage une info de mise en garde qu'une vraie question et la situation est tout à fait particulière (directory qui résiste au tri), mais parfois on cherche longtemps avant de trouver pourquoi un programme qui a fonctionné très bien pendant des années "plante" brutalement sans raison sur un instruction de base du langage (la probabilité de plantage est alors non négligeable sur les machines des utilisateurs). Je serais curieux de savoir si le problème a déjà été rencontré.

JMC70

Le file.copy du fso est-il plus sur que le Filecopy ?

3 réponses

Votre réponse

Discussions similaires