Hello Hizo,
bien, là je comprends mieux ! 😃
Alors pour répondre à tes questions :
-1) Nom des fichiers avec .xtm
=> En effet, le script cherche des fichiers se terminant par .xtm ou .exe (lignes 410 à 420 du script)
=> Pourquoi : encore une fois, c'est un défaut du format xtm !.. Il n'y a rien dans l'entête des fichiers qui indique le nommage de la suite de fichiers. On est donc obligé d'utiliser un "algorithme externe", c'est à dire quelque chose d'implicite pour réaliser la fonction de chainage de la liste des fichiers. Et tout ce qui est "implicite" te fait perdre la liberté de faire autrement. Par conséquent, il est exact qu'avec le scriipt il faut respecter le "pattern" implicite que j'ai codé :
fichier001.xtm
fichier002.xtm
...
fichierNNN.xtm
Lorsque c'est un "exécutable", on remplace simplement la première extension par .exe, le reste est inchangé.
On peut coder une infinité de "patterns" pour retrouver la liste de fichiers, mais de toute façon ils seront tous implicites vu que, comme expliqué plus haut, rien de donne le nom réel des fichiers dans l'entête. Il est donc possible, selon la façon dont tu as nommé les fichiers, que ça fonctionne avec le programme tartempion (car il aura codé ton pattern) et pas avec mon script qui n'a qu'un seul "pattern" (en principe le plus commun).
Pour donner un exemple extrême on pourrait s'amuser à coder ça :
fichier_I.xtm
fichier_II.xtm
fichier_III.xtm
fichier_IV.xtm
fichier_V.xtm
... et dire : "ah ben tiens, ça fonctionne pas... pourtant la suite est logique, c'est juste écrit en chiffre romains !.." :lol:
Alors désolé de te décevoir, je ne fais pas les suites en chiffres romain non plus !.. :rolleyes:
-2) Nom des fichiers avec "caractères spéciaux"
"En principe" ça devrait marcher...
... sauf bug, j'en ai corrigé un juste plus haut, en effet il faut prendre certaines précautions avec les scripts, notamment :
- s'assurer que tout est bien "quoté" comme il faut
- des trucs étranges comme quand le nom de fichier commence par un '-' (caractère 'moins'), il faut penser à mettre '--' au bon endroit dans les commandes pour que ça ne soit pas considéré comme une option
Enfin il y a aussi le fait que 95% des utilitaires GNU ne sont pas conformes à l'UTF-8 : cut, head, wc...
Du coup, si les noms de tes fichiers comportent des caractères au delà de l'ASCII 7 standard, il y a des risques de bug.
Un jour je ferai une page sur ça... avec ouverture de bugs sur le launchpad.
Donc là, si le nom de fichiers comporte de tels caractères, par exemple si tu y a mis des caractères chinois parce que ton film raconte tes souleries à Pékin et que tu écris couramment le chinois... bah c'est une très mauvaise idée parce qu'il y a toutes les chances que les utilitaires GNU donnent des résultats erronés.
La seule parade à ça, pour le moment, est de renommer les fichiers avec des "caractères ASCII", là ça fonctionne moyennant les 2 précautions signalées plus haut.
-3) Si ton fichier ne se rassemble pas, c'est qu'il n'est pas un xtm, du moins il ne correspond pas à la documentation qui se trouve là :
Documentation du format XtremSplit
Pour le tester, tu prends ton premier fichier et tu fais ça (en mettant bien sûr le nom de ton fichier à la place du nom de l'exemple !) :
$ hd -n 104 fichier_de_test_pour_tuXtremMerge.001.xtm
00000000 0a 58 74 72 65 6d 73 70 6c 69 74 00 00 00 00 00 |.Xtremsplit.....|
00000010 00 00 00 00 00 03 31 2e 31 00 00 00 00 00 00 00 |......1.1.......|
00000020 00 00 00 00 00 f0 e3 40 21 66 69 63 68 69 65 72 |.......@!fichier|
00000030 5f 64 65 5f 74 65 73 74 5f 70 6f 75 72 5f 74 75 |_de_test_pour_tu|
00000040 58 74 72 65 6d 4d 65 72 67 65 00 00 00 00 00 00 |XtremMerge......|
00000050 00 00 00 00 00 00 00 00 00 00 00 01 04 00 00 00 |................|
00000060 a0 70 3d 1e 00 00 00 00 |.p=.....|
00000068
On voit bien dans l'entête la chaine de marquage Xtremsplit au début
On voit aussi le nom par défaut du fichier résultat.
Les 12 deniers octets donnent le nombre de fichiers (DWORD sur 4) et la taille du fichier reconstitué (QWORD sur 8)
Là c'est donc :
00 | 00 | 00 | 04 = 4 fichiers
00 | 00 | 00 | 00 | 1e | 3d | 70 | a0 = 507 343 008 octets
S'il s'agit d'un exe, on peut faire la même chose en enlevant l'entête de l'exe, la commande à passer est alors :
hd -n 104 -s 305664 fichier_de_test_pour_tuXtremMerge.001.exe
Si aucune des deux commandes ci-dessus ne te donne quelque chose qui ressemble à ça, c'est qu'en réalité
ton fichier n'est pas un xtm... ou correspond à un ancien format de xtm dont je n'ai pas la documentation et qui n'est donc pas programmé dans le script !
Tu dis que ça fonctionne avec GnomeSplit, mais
GnomeSplit fait plein d'autres formats que les .xtm, il est donc tout à fait vraisemblable que ce ne soient tout simplement pas des xtm.
En effet, tu vois que le script trouve un nombre de fichier par milliards, en lisant les 4 caractères à l'offset où se trouve en principe le nombre de fichiers. C'est un indice que vraisemblablement on n'est pas en présence d'un fichiers ayant un entête XtremSplit valide (d'ailleurs le fait que tes fichiers n'aient pas un nom en .xtm est un deuxième indice).
Et donc si c'est bien ce que je soupçonne (ce ne sont pas des xtm)... désolé, mais mon script ne fait que les xtm !..
