open-files.com/KGB-Archiver-le-meilleur.html
fonctionne tres bien sous etch
mais
il faudra une machine guerre
c’etait juste une info.
j’ai testé sur debian et windows xp
les 2 systemes mettrons le meme temps pour decompresser mais xp je pourrais pas lancer plein d’app. contrairement à debian
C’est bon à savoir! Merci 
Ca à l’air lourd quand même d’après les avis.
Une question au passage au fait, est-il possible d’avoir de l’AES avec d’autres formats un peu plus “normaux” genre tar, bzip/2, lzop, etc… ?
Ben l’AES, peut crypter n’importe quel suite de bits donc tu peut même crypter des vidéo ou des musiques.
Ah
Je vais me renseigner comme il faut là dessus, car j’aimerais bien tester 
en fait c’etait une info et j’ai pas trop testé
j’ai une archive d’office2007 en us qui tient 1.47mo et decompressé en 8h qui donne 463 mo
malgré mon p4 2.8 intel .
je testerais sur une machine de guerre pour voir si c’est bon
en tout cas j’espere qu’à l’avenir il y aura des progrès .
@+
Hum ça fait beaucoup là quand même…
il faut vraiment une bonne machine
mais je testerais avec une tres bonne machine bien balaise…
mais 463mo en 1.47mo c’est balaise aussi
Ouais, pour être balaise ça l’est…
J’ai du mal à y croire d’ailleur 
Hébien télécharge juste ça
tu m’en diras des news
d’ailleurs d’autres personnes ont reussit à faire entrer 40 go sur un 700 mo
http://rapidshare.com/files/60501318/KGB___Office_2007.rar.html
Je suis en train de décompresser ton fichier, j’avoue que si c’est bien fonctionnel, franchement…
(Il me reste 5h de décompression, je laisse tourner )
ça a pas l’air libre le machin donc ça vaut pas un clou, ya meme des chances que ça soit un virus le machin
Un long temps de compression n’est pas gênant mais un temps de décompression long est redhibitoire surtout vu le faible gain sur rar ou bzip2.
Je sais pas trop ce que ça va donner, et je pense qu’une telle compression est techniquement impossible, mais bon…
Comment ça ?
Bon bein en tout cas ça a fonctionné, le dossier initial fait bien plus de 400Mo.
Je n’irais pas jusqu’à installer Office, je fais confiance, mais bon je suis sur les fesses.
[quote=“ymer”]Je sais pas trop ce que ça va donner, et je pense qu’une telle compression est techniquement impossible, mais bon…
Comment ça ?[/quote]Tu gagnes 10-15% sur la taille du fichier final pour une attente gigantesque dans la décompression. À l’heure des clefs à 4G, l’intérêt est très limité voire nul notamment parce que cela interdit la décompression à la volée…
Qu’on ne me parle pas d’archivage: Une bonne archive est une archive non compressée qui, même dégradée, est utilisable.
Très intéressant je n’avais jamais réfléchie comme ça, mais c’est tout à fait exacte.
J’aurais une question. ar et tar sont ils assez peut sensible à la dégradation ?
(Au passage bzip2 avec son système en morceau peut être utilisable pour de l’archivage, non?)
Ok
J’y vais de ma petite question également:
Quelqu’un aurait une méthode “simple” pour protéger des archives “tar.gz” avec un mot de passe ?
Ark -> Non
Karchiver -> Non plus
Q7z/k7z -> Impossible à installer…
Ok
J’y vais de ma petite question également:
Quelqu’un aurait une méthode “simple” pour protéger des archives “tar.gz” avec un mot de passe ?
Ark -> Non
Karchiver -> Non plus
Q7z/k7z -> Impossible à installer…[/quote]
Tous:
gpg.
Très intéressant je n’avais jamais réfléchie comme ça, mais c’est tout à fait exacte.
J’aurais une question. ar et tar sont ils assez peut sensible à la dégradation ?
(Au passage bzip2 avec son système en morceau peut être utilisable pour de l’archivage, non?)[/quote]
En fait si tu comprimes par blocs (même assez gros) identifiable, c’est envisageable. Pour le voir, tu prends un fichier texte compressé, tu modifies un octet et tu essaye de voir ce que tu peux récupérer.
Sur un fichier texte de 5287904 octets, on obtient une archive bz2 de 1449586 octets. Je modifies un bit sur un octet au hasard. J’utilise bzip2recover, ça me récupère 5 blocs sur 6 ce qui au final me permet de récupérer 4365972 octets. La perte a été de 20% pour une erreur sur 1bit par 1million500000. Ça fait quand même beaucoup de pertes.
tar ne fait que concaténer les fichiers et mettant des drapeaux. tar (sans compression) est impeccable pour l’archivage.
Pour gzip c’est beaucoup mieux (et j’en suis surpris): la même manoeuvre donne
1 seule différence entre le fichier d’origine et le fichier obtenu:
[quote]
francois@totoche:/tmp$ diff -urN gros.txt gras.txt
— gros.txt 2007-10-06 11:56:15.000000000 +0200
+++ gras.txt 2007-10-06 12:06:37.000000000 +0200
@@ -1079,7 +1079,7 @@
struct pci_pool *pool;
pool = pci_pool_create(name, dev, size, align, alloc);
pool = pci_pool_create(name, dev, size, align) alloc);
The “name” is for diagnostics (like a kmem_cache name); dev and size
are as above. The device’s hardware alignment requirement for this
[/quote] ) au lieu de ,
C’est assez étonnant et montre qu’une archive compressée avec gzip est un excellent compromis. Mon point de vue de départ est excessif (en fait je n’avais jamais testé complètement comme je viens de le faire). Il faudrait affiner en dézinguant 5 ou 6 bits au hasard. En tout cas:
bzip2 à éviter pour l’archivage
gzip est envisageable visiblement. Vu le gain de place, c’est une bonne idée.