Reprise du message précédent :
Je commence a avoir des remords d'avoir crée ce topic  

Tu l'as restauré comment ce fichier ?

 
Les PEBKAC resteront les PEBKAC.

t'en fait pas le mystere sera tjs présent quand a al disparition soudaine de ce fichier situé a la racine de mon dique dur... mais ça faisait des années que j'utilise truecrypt sans aucun soucis

 
Abandonne pas pour les essais de restauration
Tente Restorer 2000 Pro v2 qui m'a sauvé la vie plusieurs fois

merci du conseil paradox
 
il faut obligatoirement scanner tous le disque dur avec restorer2000, pour retrouver les fichiers supprimés ?

Le problème aussi c'est que plus tu utilise ton disque dur et moins tu as de chance de récupérer le fichier (car de nouveau fichier écraseront des morceaux de ton conteneur)...

je sais limdul, c pour ça que je l'ai debrancher et que je n'ai rien ecrit depuis, c un externe 2,5".
 
bon, la, 2 heure de scan, 50% pour 465 go... c lonnnngggg restorer2000

bon meme avec retaurrer 2000 le ficheir ne fait que 4 go, et une fois monté truecrypt me dit qu'il contien 398 go, donc irrécupérable je suppose
 
qui plus ai il m'a restaurer le fichier en mode caché et impossible a supprimer donc, meme dans les options de dossier sur les fichiers cachés, pourtant il est bien présent

Et avec un scandisk avant ?

scandisk sur le disque dur ou le fichier a était suprimé ? je pense au contraire que ca va chambouler les clusters nan ?

Faut tjrs cloner le disque qu'on veut sauver. Ensuite, tu fais ce que tu veux avec

Je me disais que j'allais retenter TC après les problèmes que j'ai eu avec lui. Je repasserai plus tard Vraiment inquiétant cette histoire de fichier qui disparait.

Il n'y a pas forcément de rapport avec TC en même temps. C'est quand même un disque dur, ça a des soucis. Et en plus en USB, interface moyennement fiable s'il en est.

C'est vrai que le lien est discutable mais depuis que je sais qu'un container sur clé USB ne s'ouvre pas forcement sur une autre machine que celle qui l'a créé je suis devenu très méfiant envers TC.

Le probleme doit venir d'ailleurs qd meme

Faut arrêter les amalgames là.
 
L'informatique c'est pas magique. Si il y a un problème il faut lire les logs, si il n'y a pas de logs, ben c'est moche, mais vous pouvez pas accusé tel appli ou tel autres sur du vent !

Après, tu peux tenter un service payant de récupération de data si le contenu disparu est vraiment précieux. Reste que ces services sont plutôt efficaces en cas de panne électro-mécanique sur les disques magnétiques. (faut voir avec eux quoi).

 
?
 
Problème de droits sur le fichier, peut-être ? Depuis que j'ai mon PC en 7, je galère à chaque fois que j'envoie un fichier sur le PC familial (en XP) car il n'a même pas le droit de lecture.

Merci bien!    
C'est un programme que je ne connaissais pas, que je viens de tester et d'adopter! Même sans parler de truecrypt, il est super pour faire des backups fiables.
Les autres programmes qui sont livrés avec sont du même ordre? Quand j'ai téléchargé, le monsieur de chez windows m'a dit qu'il y avait des problèmes de compatibilité avec Seven. Cela n'a pas l'air d'être le cas avec robocopy.
 
Enfin bref. Merci!  

C'est vrai qu'à la base c'est fait pour du serveur 2003 et du XP.
Pour le moment avec robocopy je n'ai pas eu de problème, mais je n'ai pas testé les autres programmes livrés avec.
Faudrait aller voir du coté de serveur 2008 pour savoir s'il y a le même "pack" qui serai pour win7.
 
Par contre robocopy ne peut pas copier les fichiers [EDIT] déjà [/EDIT] ouverts en écriture.
Je sais que ça fait un moment que je dis que je vais proposer quelques scripts de sauvegarde, vas vraiment falloir que je m'y mette...

 
J'en doute car je n'ai pas ce problème sur les fichiers en clair. Ca devrait être pareil pour le container. Je vais quand même refaire un test en pretant une attention particulière à ce point. Merci pour l'idée.

Heu... Je ne comprends pas, là.    
Y'aurait pas une coquille quelque part?

Un fichier peut être ouvert de deux façon: en lecture seule (et donc plusieurs processus peuvent l'ouvrir en même temps puisque le fichier ne sera pas modifié) ou en écriture (et donc un seul processus l'ouvre de façon exclusive pour pouvoir le modifier et éviter les conflits).
 
Et sauf à utiliser des fonctions de windows pour la copie de fichiers ouverts en écriture il n'est pas possible de lire un fichier déjà ouvert en écriture.
Ce que ne fait pas robocopy.
 
Eventuellement j'aurai pu ajouter un "déjà" pour être plus clair.

Ah d'accord là je comprends mieux, c'est effectivement plus clair maintenant.
Merci!  

Bonjour
 
Voilà j'ai quelques questions concernant Truecrypt.
 

• Alors d'après l'aide en ligne, il n'y a pas de risque de corruption de donné si le PC plante pour diverses raisons.

Est-ce vraiment vrai? C'est les différents fichiers qui sont cryptés en soit, pas le volume en lui même?  
(Si c'est le volume entier qui est crypté j'imagine que si le PC plante au mauvais moment tout le volume est corrompu, alors que si le cryptage se fait au niveau des fichiers le problème reste isolé)
 

• Peut-on utiliser un volume crypté via réseau? La aussi aucun risque de corruption? Pas de risque si 2 PC y accède en même temps,...,...? (Il y a des types de fichiers dont l'usage via réseau est fortement déconseillé, genre les fichiers PST d'Outlook)

• J'ai des lecteurs d'empreintes UPEK (Protector Suite 2009) sur mes PC, ca fonctionne assez bien, ca peut également à l'image de Truecrypt gérer des volumes cryptés. Or je n'arrive pas à trouver quel algo il utilise (je crois que c'est du 3DES). Quelqu'un a déjà utilisé ces deux software? Lequel conseilleriez-vous?

 
Voilà voilà, ca fait beaucoup de questions    
 
Je vous remercie

 
Raté, c'est le volume qui est chiffré et donc tout ce qui si trouve dedans l'est aussi. Le risque de corruption des données est le même que pour un fichier non chiffré. C'est simplement la capacité de récupéré les données perdus en cas de corruption qui est faible. Lit les post de ces dernières pages tu comprendras.
 
 
 
Même réponse.
 
 
 
Ce n'est pas comparable. UPEK est une solution propriétaire et donc du fait de sa nature on ne sait pas vraiment comment sont chiffrés les donnés. Donc ils peuvent dire ce qu'ils veulent, ils affirment qu'ils implémentent de l'AES mais c'est invérifiable à moins de dé-compiler le code source et d'enfreindre la licence. Du bon SnakeOil des familles. Et puis bon la biométrie seul c'est pas terrible et plutôt risqué en cas de panne/rayure/usure du périphérique de biométrie.
 
Contrairement à Truecrypt qui est une solution Opensource dont le code source est accessible à tout un chacun qui a même était éprouvé par le FBI
 
EDIT : Ah oui j'oubliais... On ne dit pas crypter mais chiffrer en français.

Sauf que si c'est le volume qui est chiffré, ben le fait qu'un unique fichier corrompu va corrompre tout le volume du coup, alors que l'inverse non.
C'est comme l'EFS, chaque fichier est chiffré individuellement, pas de problème, par contre si c'est du bitlocker, la ca se complique le risque est de perdre tout le volume d'un coup (c'est ce qui se lit en tout cas concernant l'EFS et Bitlocker).  
Non?
 
Vais lire le reste

Ben c'est pas un problème que le lecteur d'empreinte tombe en panne, on peut définir plusieurs niveau de sécurité:
- empreinte
- empreinte + clés unique propre au lecteur d'empreinte
- empreinte + mot de passe
-...
 
Et de toute façon il y a moyen d'ouvrir les archives chiffrées avec un mot de passe si ca ne marche pas avec l'empreinte, respectivement exporter les info d'empreinte et les réimporter sur un autre PC pour l'utiliser avec un autre lecteur

 
Pourquoi tu me parle de système de fichier ? On n'est pas dans le même niveau d'abstraction là.
Truecrypt est une surcouche au système de fichier (FAT32 ou NTFS pour Windows).  
 

 
Cela n'enlève en rien le reste de mon argumentation La seule chose que je pourrais tolérer c'est "empreinte + mot de passe".

Ca n'a rien avoir avec le système de fichier ce que je dis.
 
Imagine. T'as un volume, si c'est les différents fichier qu'il contient qui sont individuellement chiffrés, c'est pas la même chose que si c'est le volume tout entier qui l'es.
 
Dans le premier cas, si le chiffrement d'un fichier foire, ca ne pas pas corrompre les autres fichiers chiffrés dans le même volume.
Alors que si c'est le volume en lui même qui est chiffré s'il y a un bit quelque part qui déconne ben c'est tout le volume qui est perdu et pas seulement le fichier correspondant au bit.
 
D'où ma question initiale.

Non, pour corrompre tout le volume il faut que l'en-tête soit atteinte.
Donc que ton PC plante au moment précis où tu change ton mot de passe, ou alors qu'un logiciel écrive/modifie les octets où est localisé l'en-tête (défragmenteur, outil de gestion des partitions, virus etc etc...).

Si ton PC plante alors que tu est en train d'écrire un fichier dans un conteneur seul ce dernier est corrompu.
Exactement comme pour un fichier vidéo, quand un certain moment de ton "flux" est corrompu tu as alors des carrés anormaux mais le reste de ton fichier est utilisable.
Là c'est pareil.

Et on peut faire un back-up du header.

Après, il est possible que la table des fichiers puisse être altérée et te donne l'impression que ton conteneur est corrompu.
Mais ce n'est pas le cas.
Il faut imaginer  une partition à l'intérieur d'un conteneur. L'en-tête te permet d'accéder à cette partition.
Après il peut lui arriver beaucoup de chose: corruption de la table des partition ou de la table des fichier (la MFT).
Et tout ces problèmes sont en général "réparables" une fois que ton conteneur est monté.
La difficulté étant qu'en général les outils t'aidant ne sont pas sous Windows et demande le plus souvent de démarrer sur un support externe ce qui empêche dans la majorité des cas de monter ton volume.

C'est ca que je voulais savoir.
Donc en gros il y a peu de risques de perte de donnés. Suffit juste de bien s'y prendre.

Oui.
Mais comprend bien qu'avec un programme de chiffrement comme TC tu ajoute une étape dans l'accès à la donnée, et que chaque étape peut être une source de problème.
Classiquement la suite des étapes c'est (sauf erreur de ma part mais c'est pour faire comprendre): gestion matérielle du support, gestion logique des partitions (MBR de BIOS ou GPT d'UEFI), gestion logique de la partition voulue (FAT, NTFS), puis accès au fichiers.
Avec un fichier-conteneur tu as ceci: gestion matérielle du support, gestion logique des partitions (MBR de BIOS ou GPT d'UEFI) ou , gestion logique de la partition voulue (FAT, NTFS), puis accès au fichier (le conteneur TC), gestion matérielle du support via un pilote de disque virtuel, gestion logique des partitions (MBR de BIOS ou GPT d'UEFI), gestion logique de la partition voulue (FAT, NTFS via MFT), puis accès au fichiers protégés.
 
Tu comprendra donc que le risque de perte de données est donc plus grand (car plus d'étapes), mais de l'autre coté pour corrompre tout le contenu d'un conteneur TC il faut soit toucher l'en-tête, soit les octets qui contiennent la gestion de la partition.

bonsoir
j'ai fais des essais de TC recement
J'ai une premiere remarque a faire, il laisse des traces sur window ce qui enleve du crédit je trouve
les concepteurs devraient donner une liste de choses à faire et a ne pas faire dans l'OS pour qu'on ne puisse pas savoir qu'il a été utilisé
Et c'est en version portable en plus
Cas de figure :
encrysté un disque dur entier puis mounté
Ensuite j'ai sorti le cable USB, bin dans l'oberservateur d'evenement du window c'est resté !
En plus y a une liste de " mounted devices " dans le regedit
Et surement plein d'autres choses que je connais pas
 
Y a des remedes ou alors c'est la réponse habituelle ( linux etc... )
le support microsoft aide t il a configurer zin dans ces cas de figure ? c'est un OS légal version boite

 
de toute façon, pour des données standard avec un risque inférieur, il faut quand même organiser des backup réguliers, donc un choix de chiffrement avec risque supérieur de corruption/perte n'est pas une contrainte ou n'entraine pas une prise de risque supplémentaire.

@kemika:
En effet, j'ai pu moi aussi constater une clef de registre: HKLM\SYSTEM\MountedDevices
avec des clefs binaire ayant pour nom: \DosDevices\X:
avec pour X les lettres de lecteurs que j'ai déjà pu monter.
Chez-moi j'ai A: qui correspond à un lecteur de disquette usb, C:D:E: des disque dur, F:G: des lecteurs optiques, H:I:J:K: des clefs usb et des disque dur usb et enfin Z: qui correspond à mon volume TC.
 
Je pense que c'est en fait l'historique des lettres de lecteur de tout support en demandant une.
Accompagné, je pense, d'une signature permettant d'attribuer la même lettre de lecteur a un support qui a déjà été connecté.
 
Bref je n'y vois pas de danger car je n'ai trouvé aucune référence à TC ou à un cryptage lors d'une recherche sur le terme "mounted".
Je pense même qu'il est possible de pouvoir supprimer les clefs de lettres non utilisées sans trop de risque, mais je préfèrerai que des experts en BDR le confirment avant.

De toute façon pour ne vraiment laisser aucune trace, il faut tout chiffer (OS compris, qui peut être windows dans le cas de TC).