decompresser fichier situé dans sous dossiers.

symbol

Membre actif
13 Octobre 2004
536
25
Bonjour

Il y a pas mal de softs pour gérer les compression/decompression.
Softs qui font tous la même chose.

Au lieu de faire des clones sans fin de choses déjà existantes, aucun developpeur ne peut avoir une idée originale parfois ????

Bref...,
Comment merger une archive .rar quand chaque segment est dans un sous-dossier différent ?

merci

Capture_d_e_cran_2018_09_02_a_17_28_47.jpg
 
Salut symbol

Un procédé poilant peut être le suivant. Suppose que tous tes sous-dossiers ampmun* soient contenus dans un dossier parent TOTO présent sur ton Bureau et constituant la source. Tu crées sur ton Bureau encore (par exemple) un dossier de destination vide BROL. Puis tu passes la commande (qui tient compte de ces adresses farfelues) :
Bloc de code:
find ~/Desktop/TOTO -iname 'amped.part*rar' -exec cp -av {} ~/Desktop/TOTO \;

  • les archives intitulées amped.part*rar seront copiées dans BROL. Tu pourras exercer ton désarchiveur sur le dossier BROL.
 
Qui est le tordu qui a créé l'archive en plaçant chaque segment dans un dossier spécifique???
 
"Qui est le tordu qui a créé l'archive en plaçant chaque segment dans un dossier spécifique???"

La question n'est pas la.

Elle se pose tout de même!
Car soit c'est une anomalie qui ne se reproduira jamais (si on enferme son responsable... [emoji17]) et je ne vois pas pourquoi un développeur s'embêterait à développer un utilitaire traitant ce type d'archive (comme tu le réclamais avec insistance dans le 1er message),
Soit c'est courant, et là il faudrait effectivement que les utilitaires de décompression soient mis à niveau.
 
Bon je vois que le sujet ne t'intéresse plus.
Je passe donc mon chemin.
J'ai d'autres développements en cours, je ne vais donc pas perdre mon temps sur ce cas exotique.
 
Salut symbol

Un procédé poilant peut être le suivant. Suppose que tous tes sous-dossiers ampmun* soient contenus dans un dossier parent TOTO présent sur ton Bureau et constituant la source. Tu crées sur ton Bureau encore (par exemple) un dossier de destination vide BROL. Puis tu passes la commande (qui tient compte de ces adresses farfelues) :
Bloc de code:
find ~/Desktop/TOTO -iname 'amped.part*rar' -exec cp -av {} ~/Desktop/BROL \;

  • les archives intitulées amped.part*rar seront copiées dans BROL. Tu pourras exercer ton désarchiveur sur le dossier BROL.
Dans la mesure où tous les dossiers sont au même point de l'arborescence, on peut se contenter d'une commande plus directe.
Je reprends les hypothèses TOTO et BROL :
Bloc de code:
cp ~/Desktop/TOTO/ampmun??/amped.part??.rar  ~/Desktop/BROL
ou
Bloc de code:
cp ~/Desktop/TOTO/ampmun*/amped.part*.rar  ~/Desktop/BROL
(la première commande est plus précise et permet d'éviter de copier des scories).
En remplaçant cp par mv on déplacera les fichiers et ce sera plus rapide.

Elle se pose tout de même!
Car soit c'est une anomalie qui ne se reproduira jamais (si on enferme son responsable... [emoji17]) et je ne vois pas pourquoi un développeur s'embêterait à développer un utilitaire traitant ce type d'archive (comme tu le réclamais avec insistance dans le 1er message),
Soit c'est courant, et là il faudrait effectivement que les utilitaires de décompression soient mis à niveau.
Comme ça, cela ressemble fortement à un téléchargement dans les newsgroups. (p.ex. la présence d'un fichier .nfo).
D'habitude les divers .rar sont regroupés en un seul téléchargement. Mais si la personne qui a constitué les paquets s'est trompée dans ses scripts elle peut avoir créé un paquet unitaire par morceau de RAR...
Comme dirait le commandant Turbo,
Commandant Turbo a dit:
J'ai déjà vu ça !
 
J'ai dit (prudemment) que ça ressemblait :)
 
Le .nfo n'est pas spécifique de usenet.
Non, mais principalement des Teams de cracks dont Amped fait partie. Et ce type d'archivage est typique des forums de warez pour éviter que les hébergeurs ne découvrent trop rapidement que le contenu est illégal.
 
Ça discute dans ce fil. Je remets une petite pièce alors pour alimenter la conversation.
361608_original.png


En remplaçant cp par mv on déplacera les fichiers et ce sera plus rapide.

  • extrait du man de mv :
Bloc de code:
mv uses cp(1) and rm(1) to accomplish the move.  The effect is equivalent to:

           rm -f destination_path && \
           cp -pRP source_file destination && \
           rm -rf source_file

  • il s'ensuit que mv [= rm > cp > rm] est plus lent que cp - non ?
 
Ça discute dans ce fil. Je remets une petite pièce alors pour alimenter la conversation.
361608_original.png




  • extrait du man de mv :
Bloc de code:
mv uses cp(1) and rm(1) to accomplish the move.  The effect is equivalent to:

           rm -f destination_path && \
           cp -pRP source_file destination && \
           rm -rf source_file

  • il s'ensuit que mv [= rm > cp > rm] est plus lent que cp - non ?
Ce n'est pas exactement ça. Il aurait fallu faire débuter l'extrait au début de la phrase.
Soit :
As the rename(2) call does not work accross file systems, mv uses cp(1) and rm(1) to accomplish the move.
(c'est moi qui souligne).

Au plus simple, mv renomme les fichiers. Cependant, la méthode employée ne fonctionne qu'à l'intérieur d'un même système de fichiers (FS pour faire plus court).
Grosso modo l'idée est la suivante :
  • si la source et la destination sont sur le même FS, alors :
    • si la destination existe, je la supprime ;
    • je crée la destination comme lien physique (hard link) vers la source ;
      Bloc de code:
      link src dst
    • je supprime la source en tant que lien physique :
      Bloc de code:
      unlink src
      => aucune donnée n'a été copiée de la source vers la destination mais je me suis contenté de modifier les métadonnées, c'est-à-dire les références présentes dans le FS.
  • si la source et la destination ne sont pas sur le même FS, alors :
    • je ne peux pas créer de lien physique de la destination vers la source ;
    • donc je mets de côté la destination (par précaution) ou la supprime ;
    • je copie la source vers la destination ;
    • en cas de succès, je supprime la source et l'ancienne destination le cas échéant
      => toutes les données ont été lues et recopiées d'un FS à l'autre.
Pour revenir au cas qui nous occupait : étant dans le même FS, il s'agit de simples renommages de fichiers, ce qui est pratiquement instantané.

Au passage on voit tout l'intérêt des liens physiques, moins utilisés que les liens symboliques mais assez pratiques.
 
En parlant de team de crack...

Après un rapide coup d'oeil sur le net, on voit une grosse production de crack, patch, Keygen des mêmes team. Cette production est continuelle et stable. De plus, il est nécéssaire d'avoir un niveau élevé (voir très élevé) en analyse, programmation.

Je vois mal une / des personne(s), toute la journée/nuit, pendant des années produire(nt) pour la beauté du geste ce genre de code.
Il y a des règles immuables, il faut manger, se loger, payer les factures. Ce n'est pas en faisant du bénévolat, que l'argent arrive.

Règle N°1 : Quand on fait quelquechose c'est qu'on en tire un profit d'une manière ou d'une autre.

Par prudence je reprends la formulation D"Alien Theory".
- Serait-il possible que des teams de crack (Amped, HLM, etc...) soient en réalité des groupes financés par un/des gourvernement(s) afin de déstabiliser l'économie numérique de certains pays producteurs ?

Selon ce qui traine sur internet, les logiciels cibles sont surtout d'origine américaine, européenne (+UK). En tête de la liste Adobe, Windows.

Si quelqu'un a des connaissances sur le sujet.
 
Dernière édition: