# decompresser fichier situé dans sous dossiers.



## symbol (2 Septembre 2018)

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


----------



## macomaniac (2 Septembre 2018)

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) :

```
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*.


----------



## r e m y (2 Septembre 2018)

Qui est le tordu qui a créé l'archive en plaçant chaque segment dans un dossier spécifique???


----------



## symbol (2 Septembre 2018)

"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.

@*macomaniac*

*Nickel *
merci


----------



## macomaniac (2 Septembre 2018)

Content pour toi !


----------



## r e m y (2 Septembre 2018)

symbol a dit:


> "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.


----------



## symbol (2 Septembre 2018)

Si tu le dis.


----------



## r e m y (3 Septembre 2018)

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.


----------



## symbol (3 Septembre 2018)

Si tu le dis.


----------



## bompi (3 Septembre 2018)

macomaniac a dit:


> 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) :
> 
> ...


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  :

```
cp ~/Desktop/TOTO/ampmun??/amped.part??.rar  ~/Desktop/BROL
```
ou

```
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.



r e m y a dit:


> 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 !


----------



## symbol (3 Septembre 2018)

Merci de ton intervention.

Le .nfo n'est pas spécifique de usenet.


----------



## bompi (3 Septembre 2018)

J'ai dit (prudemment) que ça _ressemblait_


----------



## Locke (3 Septembre 2018)

symbol a dit:


> 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.


----------



## macomaniac (3 Septembre 2018)

Ça discute dans ce fil. Je remets une petite pièce alors pour alimenter la conversation.







bompi a dit:


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




extrait du *man* de *mv* :


```
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 ?


----------



## bompi (3 Septembre 2018)

macomaniac a dit:


> Ça discute dans ce fil. Je remets une petite pièce alors pour alimenter la conversation.
> 
> 
> 
> ...


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 ;

```
link src dst
```

je supprime la source en tant que lien physique :

```
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.


----------



## symbol (4 Septembre 2018)

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.


----------

