Dysfonctionnement aléatoire de l'option "écraser si plus récent"

Aidez Ultracopier/Supercopier en postant vos bug ici
Post Reply
LeReveur
Posts: 16
Joined: Tue Sep 03, 2019 2:53 pm

Dysfonctionnement aléatoire de l'option "écraser si plus récent"

Post by LeReveur » Mon Feb 03, 2020 11:57 am

Bonjour,

Il m'a fallu du temps pour l'identifier, celui-là. Car sans raison apparente, le copieur "décide" aléatoirement que certains des fichiers factuellement plus récents que leur équivalent à destination ne le sont pas (de son point de vue). Et difficile de déterminer le pourquoi du comment, car rien ne semble lier les fichiers ignorés, encore moins lorsqu'on les compare aux fichiers qui ne le sont pas : taille, format, ou différence d'horodatage avec les cibles, dans une même liste de copie j'ai eu de tout, aussi bien parmi ceux qui remplacent correctement leur versions antérieures, que parmi ceux qui ne le sont pas. Le seul truc que je crois avoir identifié (mais difficile d'en être sûr), c'est que dans une même liste, ceux qui sont ignorés semblent être parmi les plus récents (mais pas tous, évidemment). J'ajoute que si après une liste incomplètement copiée je sélectionne uniquement les fichiers manquants, ils ne sont toujours pas copiés si je tente à nouveau avec l'option activée, par contre ça marche si je copie sans option, ou avec l'option "remplacer si la date est différente". C'est vraiment très bizarre…
Le PC hôte est un HP ProBook 430 G6 sous Windows 10 Pro 64bits, et la destination est un serveur de fichiers sur réseau local lié comme lecteur distant.
J'essayerai d'avoir un log dès que possible, mais étant donné le côté aléatoire, et le fait que ce soit lié à l'horodatage, ça ne va pas être simple.
D'autant moins que j'en ai l'usage en milieu professionnel, que les fichiers que je manipule sont considérés comme confidentiels, et que ce bug étrange ne me permet de toute façon pas de continuer d'utiliser UltraCopier en l'état - je ne peux pas me permettre d'avoir des fichiers qui ne sont pas tenus à jour, je suis déjà passé à deux doigts de l'incident "diplomatique" avec mon patron, parce que je n'ai pas repéré ce bug plus tôt et qu'on a failli travailler sur des données obsolètes… :?

User avatar
alpha_one_x86
Site Admin
Posts: 1429
Joined: Sun Oct 26, 2008 9:09 am
Contact:

Re: Dysfonctionnement aléatoire de l'option "écraser si plus récent"

Post by alpha_one_x86 » Mon Feb 03, 2020 12:39 pm

Bonjour,

Premiérement je tiens à m'excuser, je fait toujours tout mon possible pour fiabiliser le transfére de donnée.
Il me faut un cas reproductible pour pouvoir corriger le bug.
Voila les pistes que je peu donner:
- Les caractéres spéciaux dans le chemain peuvent avoir un impacte
- L'imposibilité de lire la date (donc ca devrai être fix sur certain fichiers)
- Le NAS, j'ai déjà vu passé beaucoup de bug lié aux NAS
Tu peu tester:
http://ultracopier.first-world.info/temp/ultracopier-windows-x86-2.2.3.0.zip
Et voir si des lignes readFileMDateTime() sont correcte avec https://www.epochconverter.com/ et si ne sont pas 0 ni -1.
Tu peu me transmettre le rapport pas email: ultracopier@first-world.info c'est confidenciel.
Developer of ImageUltracopier/ImageSupercopier and of the game ImageCatchChallenger

LeReveur
Posts: 16
Joined: Tue Sep 03, 2019 2:53 pm

Re: Dysfonctionnement aléatoire de l'option "écraser si plus récent"

Post by LeReveur » Wed Feb 12, 2020 11:24 am

Bonjour,

Bon, déjà, pour info la raison pour laquelle je n'arrivais pas à me connecter sur le forum, c'est que le lien par défaut enregistré par mon navigateur n'était pas en https - je le dis pour savoir quoi vérifier en premier au cas où quelqu'un d'autre mentionnerait le message d'erreur à la connexion que j'ai eu. ;)

Comme expliqué par mail, c'est à mon bureau que j'ai le souci, il ne m'est donc pas permis d'installer un environnement spécifique, mais il faudrait peut-être juste une option de log permettant d'ajouter les indicateurs d'horodatage quand l'une ou l'autre option de date est activée, on y verrait déjà plus clair, non ?
Je n'ai pas pu conduire de tests plus avancés depuis la dernière fois (on est un peu sous le feu en ce moment, c'est pas gagné de trouver du temps), mais je pense que ce bug n'a rien à voir avec les noms de fichiers, ou alors je vois pas pourquoi, ci-dessous le tout dernier log sur six des quelques fichiers qui ne passaient pas en première copie parmi d'autres (avec l'option date plus récente, donc) et que j'ai retenté de copier seuls, avec la même option, toujours sans succès (j'ai remplacé les lettres des noms de dossiers par des X, mais j'assure que ce sont exclusivement des majuscules non accentuées) :

Code: Select all

[Copy] [%12.02.2020 12:29:57%] C:/XXXXXXXXXX/XXXXXX/XXXXX 2020/_VERIF.TXT (18228233) W:/XXXXXXXXXX/XXXXXX/XXXXX 2020/_VERIF.TXT
[Copy] [%12.02.2020 12:29:57%] C:/XXXXXXXXXX/XXXXXX/XXXXX 2020/compteur.ind (3) W:/XXXXXXXXXX/XXXXXX/XXXXX 2020/compteur.ind
[Copy] [%12.02.2020 12:29:57%] C:/XXXXXXXXXX/XXXXXX/XXXXX 2020/Crea_Excel_1.crex (3828) W:/XXXXXXXXXX/XXXXXX/XXXXX 2020/Crea_Excel_1.crex
[Copy] [%12.02.2020 12:29:57%] C:/XXXXXXXXXX/XXXXXX/XXXXX 2020/wtrait.opt (116) W:/XXXXXXXXXX/XXXXXX/XXXXX 2020/wtrait.opt
[Copy] [%12.02.2020 12:29:57%] C:/XXXXXXXXXX/XXXXXX/XXXXX 2020/VERIF1.exe (515584) W:/XXXXXXXXXX/XXXXXX/XXXXX 2020/VERIF1.exe
[Copy] [%12.02.2020 12:29:57%] C:/XXXXXXXXXX/XXXXXX/XXXXX 2020/_VERIF.html (69988284) W:/XXXXXXXXXX/XXXXXX/XXXXX 2020/_VERIF.html
[Stop] [%12.02.2020 12:30:6%] C:/XXXXXXXXXX/XXXXXX/XXXXX 2020/compteur.ind (3) W:/XXXXXXXXXX/XXXXXX/XXXXX 2020/compteur.ind
[Stop] [%12.02.2020 12:30:6%] C:/XXXXXXXXXX/XXXXXX/XXXXX 2020/wtrait.opt (116) W:/XXXXXXXXXX/XXXXXX/XXXXX 2020/wtrait.opt
[Stop] [%12.02.2020 12:30:6%] C:/XXXXXXXXXX/XXXXXX/XXXXX 2020/Crea_Excel_1.crex (3828) W:/XXXXXXXXXX/XXXXXX/XXXXX 2020/Crea_Excel_1.crex
[Stop] [%12.02.2020 12:30:6%] C:/XXXXXXXXXX/XXXXXX/XXXXX 2020/_VERIF.TXT (18228233) W:/XXXXXXXXXX/XXXXXX/XXXXX 2020/_VERIF.TXT
[Stop] [%12.02.2020 12:30:6%] C:/XXXXXXXXXX/XXXXXX/XXXXX 2020/VERIF1.exe (515584) W:/XXXXXXXXXX/XXXXXX/XXXXX 2020/VERIF1.exe
[Stop] [%12.02.2020 12:30:12%] C:/XXXXXXXXXX/XXXXXX/XXXXX 2020/_VERIF.html (69988284) W:/XXXXXXXXXX/XXXXXX/XXXXX 2020/_VERIF.html
(je précise que c'est avec la version 2.2.3.1 poussée récemment)

Et je veux bien croire qu'il y a un souci de date, mais c'est quand même étrange qu'il n'y ait aucun point commun entre les fichiers ignorés, ni aucun point de distinction entre les fichiers qui passent sans souci et ceux qui sont ignorés : des deux côtés j'ai des horodatages similaires, tant en source qu'en destination, il n'y a même pas d'ordre ni de fréquence particulière, genre sur une liste de 20 fichiers il va y en avoir 3 qui passent, 3 qui passent pas, puis respectivement 7, 1, 2, 1, 2, et 1. Et pas de point commun entre eux, par exemple dans ceux qui ne sont pas passé à mon dernier essai, il y des binaires (ci-dessus, en plus du .exe, c'est le cas des .ind et .opt), du texte (ci-dessus, en plus des .html et .txt, c'est le cas du .crex), et des très petits (une poignée d'octets) à raisonnablement grands (quelques dizaines, voire centaines de Mio). Mais j'ai la même variété du côté de ceux qui passent…
Pourtant, ceux qui ne passent pas dans une même liste ne passent toujours pas si je ré-essaie de les copier en gardant l'option, donc tout porte à croire que ce n'est pas non plus une "sélection" aléatoire (par exemple comme si la liste "sautait" de temps à autres), qu'il y a bien un point qui les distingue des autres, reste à trouver lequel, parce qu'il y a vraiment de quoi devenir dingue avec ce genre de bug, en tant que programmeur c'est ce style de mauvaise blague qui m'effraie le plus, je crois. :roll:

User avatar
alpha_one_x86
Site Admin
Posts: 1429
Joined: Sun Oct 26, 2008 9:09 am
Contact:

Re: Dysfonctionnement aléatoire de l'option "écraser si plus récent"

Post by alpha_one_x86 » Wed Feb 12, 2020 12:01 pm

Ok, déjà sur cette version les controles sur ce bug sont + strict. Ca veux dire qu'il arrive bien à obtenir une date.
Maintenant dans le rapport de la version debug tu as: readFileMDateTime qui donne le timestamps du fichiers avant la prise de décision d'écrasement, ce qui permet de savoir si la date du fichier est lu correctement ou si le bug est + tard.
Si tu peu me donner cette info, ca m'aider a y voir + claire (idéalement tout le log debug).

Sur un fichier qui ne marche pas, quelle est la date de la source et quelle est la date de la destination?
Developer of ImageUltracopier/ImageSupercopier and of the game ImageCatchChallenger

LeReveur
Posts: 16
Joined: Tue Sep 03, 2019 2:53 pm

Re: Dysfonctionnement aléatoire de l'option "écraser si plus récent"

Post by LeReveur » Thu Feb 13, 2020 11:56 am

OK. Alors je pense que soit c'est ça l'origine du bug, soit il va falloir une version corrigée pour trouver le bug. Parce qu'avec la dernière version de debug, les readFileMDateTime donnent des TS de type 3157715931, ‎2604192646, ou encore 3486788099. Je te laisse les convertir sur le site que tu as mentionné plus haut pour constater le souci. :D

(edit : je précise que ça, peu importe que ce soit en source ou en dest, donc en local ou sur le NAS)

User avatar
alpha_one_x86
Site Admin
Posts: 1429
Joined: Sun Oct 26, 2008 9:09 am
Contact:

Re: Dysfonctionnement aléatoire de l'option "écraser si plus récent"

Post by alpha_one_x86 » Thu Feb 13, 2020 1:50 pm

Bon,
Plusieurs heures passé la dessus, pas de résultat.
J'ai pu reproduire le bug, je cherche une solution.
Developer of ImageUltracopier/ImageSupercopier and of the game ImageCatchChallenger

User avatar
alpha_one_x86
Site Admin
Posts: 1429
Joined: Sun Oct 26, 2008 9:09 am
Contact:

Re: Dysfonctionnement aléatoire de l'option "écraser si plus récent"

Post by alpha_one_x86 » Thu Feb 13, 2020 3:35 pm

http://files.first-world.info/temp/t.zip
Teste avec cela, verifie que les dates correspondes bien aux dates détectés, je vais intégrer ce code a ultracopier.
Ensuite vois si ultracopier avec ce code marche:
http://ultracopier.first-world.info/temp/ultracopier-windows-x86-2.2.3.2.zip
Apprament les temps sont exprimé en UTC GTM+0
Developer of ImageUltracopier/ImageSupercopier and of the game ImageCatchChallenger

LeReveur
Posts: 16
Joined: Tue Sep 03, 2019 2:53 pm

Re: Dysfonctionnement aléatoire de l'option "écraser si plus récent"

Post by LeReveur » Fri Feb 14, 2020 12:27 pm

J'ai testé avec une nouvelle liste de copie, et cette fois les timestamp indiqués dans le log de debug correspondent. Enfin, ils en ont globalement l'air, et pour celui que j'ai vérifié il correspondait parfaitement à l'horodatage du fichier concerné. Et surtout, ma liste de copie a été traitée en entier. :D

Post Reply