Contenu | Rechercher | Menus

Annonce

Si vous avez des soucis pour rester connecté, déconnectez-vous puis reconnectez-vous depuis ce lien en cochant la case
Me connecter automatiquement lors de mes prochaines visites.

À propos de l'équipe du forum.

#1 Le 02/01/2017, à 19:10

Vincent Valentine

[problème] table de partition vide d'une clef USB

Bonsoir,

pendant le déplacement de données d'une clef USB à une autre, la clef source a planté : le déplacement s'est arrêté et depuis il est impossible de la monter.

Elle est vu par FDISK. Mais les tailles ne correspondent pas : il n''y avait qu'une seule partition et la clef fait 8 Go.

sudo fdisk -l
Périphérique Amorçage      Start        Fin   Secteurs Size Id Type
/dev/sdj3             2542625089 6736601408 4193976320   2T  0 Vide
/dev/sdj4                      0          0          0   0B  0 Vide

Partition table entries are not in disk order.
J'ai fais une copie avec ddrescue :

sudo ddrescue -d -r3  /dev/sdj /media/Tetsuo/clef2.img /home/vv666/dd/suivi6.log
GNU ddrescue 1.19
Press Ctrl-C to interrupt
rescued:     8086 MB,  errsize:       0 B,  current rate:    9830 kB/s
   ipos:     8086 MB,   errors:       0,    average rate:   22462 kB/s
   opos:     8086 MB, run time:       6 m,  successful read:       0 s ago

Maintenant, j'essaie de vérifier l'image mais impossible :

sudo fsck -y /media/Tetsuo/clef.img
fsck de util-linux 2.26.2
e2fsck 1.42.12 (29-Aug-2014)
ext2fs_open2: Numéro magique invalide dans le super-bloc
fsck.ext2 : Superbloc invalide, tentons d'utiliser les blocs de sauvetage...
fsck.ext2: Numéro magique invalide dans le super-bloc lors de la tentative d'ouverture de /media/Tetsuo/clef.img

Le superbloc n'a pu être lu ou ne contient pas un système de fichiers
ext2/ext3/ext4 correct. Si le périphérique est valide et qu'il contient réellement
un système de fichiers ext2/ext3/ext4 (et non pas de type swap, ufs ou autre),
alors le superbloc est corrompu, et vous pourriez tenter d'exécuter
e2fsck avec un autre superbloc :
    e2fsck -b 8193 <périphérique>
 ou
    e2fsck -b 32768 <périphérique>

Testdisk accède à l'image, mais ne trouve aucune table de partition, comme si elle n'avait jamais été formaté.

J'ai pensé à créer une tableau à la main, sans partitionnement spécifique ce n'est pas trop dur, mais il ne se passe rien.

J'ai testé Gpart mais sans succès.

Avez vous une idée de comment accéder aux données sauvées ?
merci

Dernière modification par Vincent Valentine (Le 02/01/2017, à 20:21)


PRO : Mon taf : https://www.webcaf.fr - Mes designs en vente : http://shop.mideel.fr
PASSION : Ocarina FR : http://www.partition-ocarina.fr/ - Mes peintures : https://www.mideel.fr - Mes photos : https://pix.diaspodon.fr/VV666

Hors ligne

#2 Le 02/01/2017, à 19:49

Nasman

Re : [problème] table de partition vide d'une clef USB

Que donne

sudo fdisk -l

et

sudo dd if=/dev/sdX bs=512 count=1 | hexdump -C

(en remplaçant le X de sdX par ce qui correspond à ta clé.)


PC fixe sous Bionic 64 bits et portable avec Focal 64 bits

Hors ligne

#3 Le 02/01/2017, à 20:21

Vincent Valentine

Re : [problème] table de partition vide d'une clef USB

Le résultat de la première commande est celle de sudo fdisk -l

Pour dd :

sudo dd if=/dev/sdj bs=512 count=1 | hexdump -C
00000000  70 00 00 00 00 00 00 0a  00 00 00 00 00 00 00 00  |p...............|
00000010  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
000001e0  00 00 00 00 72 72 41 61  8d 97 00 00 fb f9 06 00  |....rrAa........|
000001f0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 55 aa  |..............U.|
1+0 enregistrements lus
1+0 enregistrements écrits
512 octets (512 B) copiés, 0,000933178 s, 549 kB/s
00000200

Je l'ai fais en direct sur la clef.

Pour info, résultat de gpart :

sudo gpart /media/Tetsuo/clef2.img 

Begin scan...
End scan.

Checking partitions...
Ok.

Guessed primary partition table:
Primary partition(1)
   type: 000(0x00)(unused)
   size: 0mb #s(0) s(0-0)
   chs:  (0/0/0)-(0/0/0)d (0/0/0)-(0/0/0)r

Primary partition(2)
   type: 000(0x00)(unused)
   size: 0mb #s(0) s(0-0)
   chs:  (0/0/0)-(0/0/0)d (0/0/0)-(0/0/0)r

Primary partition(3)
   type: 000(0x00)(unused)
   size: 0mb #s(0) s(0-0)
   chs:  (0/0/0)-(0/0/0)d (0/0/0)-(0/0/0)r

Primary partition(4)
   type: 000(0x00)(unused)
   size: 0mb #s(0) s(0-0)
   chs:  (0/0/0)-(0/0/0)d (0/0/0)-(0/0/0)r

et testdisk me trouve un CHS différent entre la copie faite avec dd et la clef physique :

clef  :

TestDisk 6.14, Data Recovery Utility, July 2013
Christophe GRENIER <grenier@cgsecurity.org>
http://www.cgsecurity.org

Disk /dev/sdj - 8086 MB / 7712 MiB - CHS 1023 249 62
Current partition structure:
     Partition                  Start        End    Size in sectors

No partition is bootable

image faite avec ddrescue :

TestDisk 6.14, Data Recovery Utility, July 2013
Christophe GRENIER <grenier@cgsecurity.org>
http://www.cgsecurity.org

Disk /media/Tetsuo/clef2.img - 8086 MB / 7712 MiB - CHS 984 255 63
Current partition structure:
     Partition                  Start        End    Size in sectors

No partition is bootable

C'est bizarre non ?


PRO : Mon taf : https://www.webcaf.fr - Mes designs en vente : http://shop.mideel.fr
PASSION : Ocarina FR : http://www.partition-ocarina.fr/ - Mes peintures : https://www.mideel.fr - Mes photos : https://pix.diaspodon.fr/VV666

Hors ligne

#4 Le 03/01/2017, à 18:27

Vincent Valentine

Re : [problème] table de partition vide d'une clef USB

Up, une idée ?


PRO : Mon taf : https://www.webcaf.fr - Mes designs en vente : http://shop.mideel.fr
PASSION : Ocarina FR : http://www.partition-ocarina.fr/ - Mes peintures : https://www.mideel.fr - Mes photos : https://pix.diaspodon.fr/VV666

Hors ligne

#5 Le 04/01/2017, à 12:35

Nasman

Re : [problème] table de partition vide d'une clef USB

Poster le résultat complet de la commande

sudo fdisk -l

On doit avoir la taille de la clé à l'octet près, le nombre de secteurs et la taille de secteurs, physiques et logiques.


PC fixe sous Bionic 64 bits et portable avec Focal 64 bits

Hors ligne

#6 Le 06/01/2017, à 15:14

Vincent Valentine

Re : [problème] table de partition vide d'une clef USB

Et voilà !
C'est le disque sdi en fin de liste.
Merci :-)

~$ sudo fdisk -l
Disque /dev/ram0 : 64 MiB, 67108864 octets, 131072 secteurs
Unités : sectors of 1 * 512 = 512 octets
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes


Disque /dev/ram1 : 64 MiB, 67108864 octets, 131072 secteurs
Unités : sectors of 1 * 512 = 512 octets
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes


Disque /dev/ram2 : 64 MiB, 67108864 octets, 131072 secteurs
Unités : sectors of 1 * 512 = 512 octets
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes


Disque /dev/ram3 : 64 MiB, 67108864 octets, 131072 secteurs
Unités : sectors of 1 * 512 = 512 octets
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes


Disque /dev/ram4 : 64 MiB, 67108864 octets, 131072 secteurs
Unités : sectors of 1 * 512 = 512 octets
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes


Disque /dev/ram5 : 64 MiB, 67108864 octets, 131072 secteurs
Unités : sectors of 1 * 512 = 512 octets
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes


Disque /dev/ram6 : 64 MiB, 67108864 octets, 131072 secteurs
Unités : sectors of 1 * 512 = 512 octets
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes


Disque /dev/ram7 : 64 MiB, 67108864 octets, 131072 secteurs
Unités : sectors of 1 * 512 = 512 octets
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes


Disque /dev/ram8 : 64 MiB, 67108864 octets, 131072 secteurs
Unités : sectors of 1 * 512 = 512 octets
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes


Disque /dev/ram9 : 64 MiB, 67108864 octets, 131072 secteurs
Unités : sectors of 1 * 512 = 512 octets
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes


Disque /dev/ram10 : 64 MiB, 67108864 octets, 131072 secteurs
Unités : sectors of 1 * 512 = 512 octets
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes


Disque /dev/ram11 : 64 MiB, 67108864 octets, 131072 secteurs
Unités : sectors of 1 * 512 = 512 octets
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes


Disque /dev/ram12 : 64 MiB, 67108864 octets, 131072 secteurs
Unités : sectors of 1 * 512 = 512 octets
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes


Disque /dev/ram13 : 64 MiB, 67108864 octets, 131072 secteurs
Unités : sectors of 1 * 512 = 512 octets
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes


Disque /dev/ram14 : 64 MiB, 67108864 octets, 131072 secteurs
Unités : sectors of 1 * 512 = 512 octets
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes


Disque /dev/ram15 : 64 MiB, 67108864 octets, 131072 secteurs
Unités : sectors of 1 * 512 = 512 octets
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes


Disque /dev/sda : 139,8 GiB, 150039945216 octets, 293046768 secteurs
Unités : sectors of 1 * 512 = 512 octets
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x000768dd

Périphérique Amorçage  Start       Fin  Secteurs   Size Id Type
/dev/sda1    *          2048    206847    204800   100M  7 HPFS/NTFS/exFAT
/dev/sda2             206848 293044223 292837376 139,7G  7 HPFS/NTFS/exFAT


Disque /dev/sdb : 465,8 GiB, 500106780160 octets, 976771055 secteurs
Unités : sectors of 1 * 512 = 512 octets
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x5cfe4108

Périphérique Amorçage Start       Fin  Secteurs   Size Id Type
/dev/sdb1    *           63 976768064 976768002 465,8G  5 Étendue
/dev/sdb5               126 976768064 976767939 465,8G 83 Linux




Disque /dev/sdd : 119,2 GiB, 128035676160 octets, 250069680 secteurs
Unités : sectors of 1 * 512 = 512 octets
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xd7a26302

Périphérique Amorçage     Start       Fin  Secteurs   Size Id Type
/dev/sdd1    *             2048  39063551  39061504  18,6G 83 Linux
/dev/sdd2              39065598 250068991 211003394 100,6G  5 Étendue
/dev/sdd5             248117248 250068991   1951744   953M 82 partition d'échange Linux / Solaris
/dev/sdd6              39065600 248117247 209051648  99,7G 83 Linux

Partition table entries are not in disk order.


Disque /dev/sdc : 465,8 GiB, 500106780160 octets, 976771055 secteurs
Unités : sectors of 1 * 512 = 512 octets
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x0004809e

Périphérique Amorçage Start       Fin  Secteurs   Size Id Type
/dev/sdc1    *           63 976768064 976768002 465,8G  5 Étendue
/dev/sdc5               126 976768064 976767939 465,8G 83 Linux


Disque /dev/sdi : 7,5 GiB, 8086618112 octets, 15794176 secteurs
Unités : sectors of 1 * 512 = 512 octets
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x00000000

Périphérique Amorçage      Start        Fin   Secteurs Size Id Type
/dev/sdi3             2542625089 6736601408 4193976320   2T  0 Vide
/dev/sdi4                      0          0          0   0B  0 Vide

Partition table entries are not in disk order.

Dernière modification par Vincent Valentine (Le 06/01/2017, à 15:14)


PRO : Mon taf : https://www.webcaf.fr - Mes designs en vente : http://shop.mideel.fr
PASSION : Ocarina FR : http://www.partition-ocarina.fr/ - Mes peintures : https://www.mideel.fr - Mes photos : https://pix.diaspodon.fr/VV666

Hors ligne

#7 Le 06/01/2017, à 19:12

Nasman

Re : [problème] table de partition vide d'une clef USB

Dans ton post#3, j'ai reconnu la chaine de caractères rrAa comme faisant partie d'un en-tête de partition fat. Malheureusement cette chaine de caractères n'a rien à faire à l'emplacement de la table des partitions.

On dirait que ce qui a été recopié ne l'a pas été au bon endroit (genre copier sdX1 sur sdY).

Je pense qu'il doit être possible de retrouver (mais pas immédiatement) les données - j'espère que ce n'est pas urgent !
Il va falloir reconstituer les en-têtes des partitions (sans doute "à la mano") et cela peut prendre du temps.

En attendant :
- donner le maximum d'informations sur :
- ce qui a été fait, comment la copie a été faite et avec quels outils (ma boule de cristal est cassée)
- afficher le contenu du début de la clé, on va dire 10 secteurs.

sudo dd if=/dev/sdi bs=512 count=10 | hexdump -C

Dernière modification par Nasman (Le 06/01/2017, à 19:15)


PC fixe sous Bionic 64 bits et portable avec Focal 64 bits

Hors ligne

#8 Le 06/01/2017, à 19:28

Vincent Valentine

Re : [problème] table de partition vide d'une clef USB

Ce qui a été fait : sous Linux (Ubuntu Gnome 15.10)
Coupé collé des fichiers de la clef : presque 8Go de données. 15% ont été copié ailleurs (mais non lisible, tous les fichiers sont endommagés), puis le déplacement à planté : la copie s'est arrété et la clef n'était plus vu dans Fichier.
Depuis, copie des données avec DDrescue et divers accès avec fdisk, gpart, testdisk.

sudo dd if=/dev/sdi bs=512 count=10 | hexdump -C

00000000  70 00 00 00 00 00 00 0a  00 00 00 00 00 00 00 00  |p...............|
00000010  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
000001e0  00 00 00 00 72 72 41 61  8d 97 00 00 fb f9 06 00  |....rrAa........|
000001f0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 55 aa  |..............U.|
00000200  70 00 00 00 00 00 00 0a  00 00 00 00 00 00 00 00  |p...............|
00000210  00 00 30 30 30 30 20 6e  0d 0a 30 30 30 30 30 35  |..0000 n..000005|
00000220  36 36 36 36 20 30 30 30  30 30 20 6e 0d 0a 30 30  |6666 00000 n..00|
00000230  30 30 30 35 37 30 38 31  20 30 30 30 30 30 20 6e  |00057081 00000 n|
00000240  0d 0a 30 30 30 30 30 35  37 31 37 38 20 30 30 30  |..0000057178 000|
00000250  30 30 20 6e 0d 0a 30 30  30 30 30 35 37 36 33 37  |00 n..0000057637|
00000260  20 30 30 30 30 30 20 6e  0d 0a 30 30 30 30 30 35  | 00000 n..000005|
00000270  37 39 30 37 20 30 30 30  30 30 20 6e 0d 0a 30 30  |7907 00000 n..00|
00000280  30 30 30 35 38 32 32 34  20 30 30 30 30 30 20 6e  |00058224 00000 n|
00000290  0d 0a 30 30 30 30 30 35  39 35 39 33 20 30 30 30  |..0000059593 000|
000002a0  30 30 20 6e 0d 0a 30 30  30 30 30 36 39 35 35 39  |00 n..0000069559|
000002b0  20 30 30 30 30 30 20 6e  0d 0a 30 30 30 30 30 36  | 00000 n..000006|
000002c0  39 38 31 30 20 30 30 30  30 30 20 6e 0d 0a 30 30  |9810 00000 n..00|
000002d0  30 30 30 36 39 38 34 34  20 30 30 30 30 30 20 6e  |00069844 00000 n|
000002e0  0d 0a 30 30 30 30 30 37  30 30 31 37 20 30 30 30  |..0000070017 000|
000002f0  30 30 20 6e 0d 0a 30 30  30 30 30 37 30 32 31 36  |00 n..0000070216|
00000300  20 30 30 30 30 30 20 6e  0d 0a 30 30 30 30 30 37  | 00000 n..000007|
00000310  30 32 37 35 20 30 30 30  30 30 20 6e 0d 0a 30 30  |0275 00000 n..00|
00000320  30 30 30 37 37 39 33 34  20 30 30 30 30 30 20 6e  |00077934 00000 n|
00000330  0d 0a 74 72 61 69 6c 65  72 0d 0a 3c 3c 2f 53 69  |..trailer..<</Si|
00000340  7a 65 20 32 36 2f 49 44  5b 3c 41 41 34 43 31 38  |ze 26/ID[<AA4C18|
00000350  37 31 33 44 36 34 43 34  34 46 42 37 32 34 32 41  |713D64C44FB7242A|
00000360  38 41 38 30 42 38 42 34  39 36 3e 3c 44 34 37 30  |8A80B8B496><D470|
00000370  37 30 35 38 35 43 33 38  30 36 34 35 38 35 39 43  |70585C380645859C|
00000380  37 38 38 35 36 45 31 36  44 31 34 45 3e 5d 3e 3e  |78856E16D14E>]>>|
00000390  0d 0a 73 74 61 72 74 78  72 65 66 0d 0a 31 31 36  |..startxref..116|
000003a0  0d 0a 25 25 45 4f 46 0d  0a 00 00 00 00 00 00 00  |..%%EOF.........|
000003b0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000400  20 20 20 20 20 20 20 3c  73 74 45 76 74 3a 77 68  |       <stEvt:wh|
00000410  65 6e 3e 32 30 31 30 2d  30 37 2d 31 32 54 31 30  |en>2010-07-12T10|
00000420  3a 35 34 3a 30 39 2b 30  32 3a 30 30 3c 2f 73 74  |:54:09+02:00</st|
00000430  45 76 74 3a 77 68 65 6e  3e 0a 20 20 20 20 20 20  |Evt:when>.      |
00000440  20 20 20 20 20 20 20 20  20 20 20 20 3c 73 74 45  |            <stE|
00000450  76 74 3a 73 6f 66 74 77  61 72 65 41 67 65 6e 74  |vt:softwareAgent|
00000460  3e 41 64 6f 62 65 20 49  6e 44 65 73 69 67 6e 20  |>Adobe InDesign |
00000470  36 2e 30 3c 2f 73 74 45  76 74 3a 73 6f 66 74 77  |6.0</stEvt:softw|
00000480  61 72 65 41 67 65 6e 74  3e 0a 20 20 20 20 20 20  |areAgent>.      |
00000490  20 20 20 20 20 20 20 20  20 20 20 20 3c 73 74 45  |            <stE|
000004a0  76 74 3a 63 68 61 6e 67  65 64 3e 2f 3c 2f 73 74  |vt:changed>/</st|
000004b0  45 76 74 3a 63 68 61 6e  67 65 64 3e 0a 20 20 20  |Evt:changed>.   |
000004c0  20 20 20 20 20 20 20 20  20 20 20 20 3c 2f 72 64  |            </rd|
000004d0  66 3a 6c 69 3e 0a 20 20  20 20 20 20 20 20 20 20  |f:li>.          |
000004e0  20 20 20 20 20 3c 72 64  66 3a 6c 69 20 72 64 66  |     <rdf:li rdf|
000004f0  3a 70 61 72 73 65 54 79  70 65 3d 22 52 65 73 6f  |:parseType="Reso|
00000500  75 72 63 65 22 3e 0a 20  20 20 20 20 20 20 20 20  |urce">.         |
00000510  20 20 20 20 20 20 20 20  20 3c 73 74 45 76 74 3a  |         <stEvt:|
00000520  61 63 74 69 6f 6e 3e 73  61 76 65 64 3c 2f 73 74  |action>saved</st|
00000530  45 76 74 3a 61 63 74 69  6f 6e 3e 0a 20 20 20 20  |Evt:action>.    |
00000540  20 20 20 20 20 20 20 20  20 20 20 20 20 20 3c 73  |              <s|
00000550  74 45 76 74 3a 69 6e 73  74 61 6e 63 65 49 44 3e  |tEvt:instanceID>|
00000560  78 6d 70 2e 69 69 64 3a  37 41 32 46 41 43 33 44  |xmp.iid:7A2FAC3D|
00000570  43 34 41 36 44 46 31 31  38 41 38 34 42 38 34 39  |C4A6DF118A84B849|
00000580  38 44 39 32 43 39 31 45  3c 2f 73 74 45 76 74 3a  |8D92C91E</stEvt:|
00000590  69 6e 73 74 61 6e 63 65  49 44 3e 0a 20 20 20 20  |instanceID>.    |
000005a0  20 20 20 20 20 20 20 20  20 20 20 20 20 20 3c 73  |              <s|
000005b0  74 45 76 74 3a 77 68 65  6e 3e 32 30 31 30 2d 30  |tEvt:when>2010-0|
000005c0  38 2d 31 33 54 31 32 3a  32 30 3a 30 34 2b 30 32  |8-13T12:20:04+02|
000005d0  3a 30 30 3c 2f 73 74 45  76 74 3a 77 68 65 6e 3e  |:00</stEvt:when>|
000005e0  0a 20 20 20 20 20 20 20  20 20 20 20 20 20 20 20  |.               |
000005f0  20 20 20 3c 73 74 45 76  74 3a 73 6f 66 74 77 61  |   <stEvt:softwa|
00000600  72 65 41 67 65 6e 74 3e  41 64 6f 62 65 20 49 6e  |reAgent>Adobe In|
00000610  44 65 73 69 67 6e 20 36  2e 30 3c 2f 73 74 45 76  |Design 6.0</stEv|
00000620  74 3a 73 6f 66 74 77 61  72 65 41 67 65 6e 74 3e  |t:softwareAgent>|
00000630  0a 20 20 20 20 20 20 20  20 20 20 20 20 20 20 20  |.               |
00000640  20 20 20 3c 73 74 45 76  74 3a 63 68 61 6e 67 65  |   <stEvt:change|
00000650  64 3e 2f 3c 2f 73 74 45  76 74 3a 63 68 61 6e 67  |d>/</stEvt:chang|
00000660  65 64 3e 0a 20 20 20 20  20 20 20 20 20 20 20 20  |ed>.            |
00000670  20 20 20 3c 2f 72 64 66  3a 6c 69 3e 0a 20 20 20  |   </rdf:li>.   |
00000680  20 20 20 20 20 20 20 20  20 3c 2f 72 64 66 3a 53  |         </rdf:S|
00000690  65 71 3e 0a 20 20 20 20  20 20 20 20 20 3c 2f 78  |eq>.         </x|
000006a0  6d 70 4d 4d 3a 48 69 73  74 6f 72 79 3e 0a 20 20  |mpMM:History>.  |
000006b0  20 20 20 20 20 20 20 3c  78 6d 70 4d 4d 3a 4d 61  |       <xmpMM:Ma|
000006c0  6e 69 66 65 73 74 3e 0a  20 20 20 20 20 20 20 20  |nifest>.        |
000006d0  20 20 20 20 3c 72 64 66  3a 42 61 67 3e 0a 20 20  |    <rdf:Bag>.  |
000006e0  20 20 20 20 20 20 20 20  20 20 20 20 20 3c 72 64  |             <rd|
000006f0  66 3a 6c 69 20 72 64 66  3a 70 61 72 73 65 54 79  |f:li rdf:parseTy|
00000700  70 65 3d 22 52 65 73 6f  75 72 63 65 22 3e 0a 20  |pe="Resource">. |
10+0 enregistrements lus
10+0 enregistrements écrits
00000710  20 20 20 20 20 20 20 20  20 20 20 20 20 20 20 20  |                |
5120 octets (5,1 kB) copiés00000720  20 3c 73 74 4d 66 73 3a  6c 69 6e 6b 46 6f 72 6d  | <stMfs:linkForm|
00000730  3e 52 65 66 65 72 65 6e  63 65 53 74 72 65 61 6d  |>ReferenceStream|
, 0,00199517 s, 2,6 MB/s
00000740  3c 2f 73 74 4d 66 73 3a  6c 69 6e 6b 46 6f 72 6d  |</stMfs:linkForm|
00000750  3e 0a 20 20 20 20 20 20  20 20 20 20 20 20 20 20  |>.              |
00000760  20 20 20 20 3c 78 6d 70  4d 4d 3a 70 6c 61 63 65  |    <xmpMM:place|
00000770  64 58 52 65 73 6f 6c 75  74 69 6f 6e 3e 37 32 2e  |dXResolution>72.|
00000780  30 30 3c 2f 78 6d 70 4d  4d 3a 70 6c 61 63 65 64  |00</xmpMM:placed|
00000790  58 52 65 73 6f 6c 75 74  69 6f 6e 3e 0a 20 20 20  |XResolution>.   |
000007a0  20 20 20 20 20 20 20 20  20 20 20 20 20 20 20 3c  |               <|
000007b0  78 6d 70 4d 4d 3a 70 6c  61 63 65 64 59 52 65 73  |xmpMM:placedYRes|
000007c0  6f 6c 75 74 69 6f 6e 3e  37 32 2e 30 30 3c 2f 78  |olution>72.00</x|
000007d0  6d 70 4d 4d 3a 70 6c 61  63 65 64 59 52 65 73 6f  |mpMM:placedYReso|
000007e0  6c 75 74 69 6f 6e 3e 0a  20 20 20 20 20 20 20 20  |lution>.        |
000007f0  20 20 20 20 20 20 20 20  20 20 3c 78 6d 70 4d 4d  |          <xmpMM|
00000800  3a 70 6c 61 63 65 64 52  65 73 6f 6c 75 74 69 6f  |:placedResolutio|
00000810  6e 55 6e 69 74 3e 49 6e  63 68 65 73 3c 2f 78 6d  |nUnit>Inches</xm|
00000820  70 4d 4d 3a 70 6c 61 63  65 64 52 65 73 6f 6c 75  |pMM:placedResolu|
00000830  74 69 6f 6e 55 6e 69 74  3e 0a 20 20 20 20 20 20  |tionUnit>.      |
00000840  20 20 20 20 20 20 20 20  20 20 20 20 3c 73 74 4d  |            <stM|
00000850  66 73 3a 72 65 66 65 72  65 6e 63 65 20 72 64 66  |fs:reference rdf|
00000860  3a 70 61 72 73 65 54 79  70 65 3d 22 52 65 73 6f  |:parseType="Reso|
00000870  75 72 63 65 22 3e 0a 20  20 20 20 20 20 20 20 20  |urce">.         |
00000880  20 20 20 20 20 20 20 20  20 20 20 20 3c 73 74 52  |            <stR|
00000890  65 66 3a 69 6e 73 74 61  6e 63 65 49 44 3e 75 75  |ef:instanceID>uu|
000008a0  69 64 3a 62 63 65 39 31  66 66 36 2d 65 61 39 61  |id:bce91ff6-ea9a|
000008b0  2d 34 36 32 61 2d 38 66  66 37 2d 63 63 65 39 30  |-462a-8ff7-cce90|
000008c0  31 66 30 38 63 34 33 3c  2f 73 74 52 65 66 3a 69  |1f08c43</stRef:i|
000008d0  6e 73 74 61 6e 63 65 49  44 3e 0a 20 20 20 20 20  |nstanceID>.     |
000008e0  20 20 20 20 20 20 20 20  20 20 20 20 20 20 20 20  |                |
000008f0  3c 73 74 52 65 66 3a 64  6f 63 75 6d 65 6e 74 49  |<stRef:documentI|
00000900  44 3e 75 75 69 64 3a 62  63 64 33 36 33 61 62 2d  |D>uuid:bcd363ab-|
00000910  63 39 33 31 2d 34 65 66  32 2d 38 64 33 61 2d 34  |c931-4ef2-8d3a-4|
00000920  39 35 36 34 64 32 37 30  31 63 65 3c 2f 73 74 52  |9564d2701ce</stR|
00000930  65 66 3a 64 6f 63 75 6d  65 6e 74 49 44 3e 0a 20  |ef:documentID>. |
00000940  20 20 20 20 20 20 20 20  20 20 20 20 20 20 20 20  |                |
00000950  20 3c 2f 73 74 4d 66 73  3a 72 65 66 65 72 65 6e  | </stMfs:referen|
00000960  63 65 3e 0a 20 20 20 20  20 20 20 20 20 20 20 20  |ce>.            |
00000970  20 20 20 3c 2f 72 64 66  3a 6c 69 3e 0a 20 20 20  |   </rdf:li>.   |
00000980  20 20 20 20 20 20 20 20  20 20 20 20 3c 72 64 66  |            <rdf|
00000990  3a 6c 69 20 72 64 66 3a  70 61 72 73 65 54 79 70  |:li rdf:parseTyp|
000009a0  65 3d 22 52 65 73 6f 75  72 63 65 22 3e 0a 20 20  |e="Resource">.  |
000009b0  20 20 20 20 20 20 20 20  20 20 20 20 20 20 20 20  |                |
000009c0  3c 73 74 4d 66 73 3a 6c  69 6e 6b 46 6f 72 6d 3e  |<stMfs:linkForm>|
000009d0  52 65 66 65 72 65 6e 63  65 53 74 72 65 61 6d 3c  |ReferenceStream<|
000009e0  2f 73 74 4d 66 73 3a 6c  69 6e 6b 46 6f 72 6d 3e  |/stMfs:linkForm>|
000009f0  0a 20 20 20 20 20 20 20  20 20 20 20 20 20 20 20  |.               |
00000a00  20 20 20 3c 78 6d 70 4d  4d 3a 70 6c 61 63 65 64  |   <xmpMM:placed|
00000a10  58 52 65 73 6f 6c 75 74  69 6f 6e 3e 37 32 2e 30  |XResolution>72.0|
00000a20  30 3c 2f 78 6d 70 4d 4d  3a 70 6c 61 63 65 64 58  |0</xmpMM:placedX|
00000a30  52 65 73 6f 6c 75 74 69  6f 6e 3e 0a 20 20 20 20  |Resolution>.    |
00000a40  20 20 20 20 20 20 20 20  20 20 20 20 20 20 3c 78  |              <x|
00000a50  6d 70 4d 4d 3a 70 6c 61  63 65 64 59 52 65 73 6f  |mpMM:placedYReso|
00000a60  6c 75 74 69 6f 6e 3e 37  32 2e 30 30 3c 2f 78 6d  |lution>72.00</xm|
00000a70  70 4d 4d 3a 70 6c 61 63  65 64 59 52 65 73 6f 6c  |pMM:placedYResol|
00000a80  75 74 69 6f 6e 3e 0a 20  20 20 20 20 20 20 20 20  |ution>.         |
00000a90  20 20 20 20 20 20 20 20  20 3c 78 6d 70 4d 4d 3a  |         <xmpMM:|
00000aa0  70 6c 61 63 65 64 52 65  73 6f 6c 75 74 69 6f 6e  |placedResolution|
00000ab0  55 6e 69 74 3e 49 6e 63  68 65 73 3c 2f 78 6d 70  |Unit>Inches</xmp|
00000ac0  4d 4d 3a 70 6c 61 63 65  64 52 65 73 6f 6c 75 74  |MM:placedResolut|
00000ad0  69 6f 6e 55 6e 69 74 3e  0a 20 20 20 20 20 20 20  |ionUnit>.       |
00000ae0  20 20 20 20 20 20 20 20  20 20 20 3c 73 74 4d 66  |           <stMf|
00000af0  73 3a 72 65 66 65 72 65  6e 63 65 20 72 64 66 3a  |s:reference rdf:|
00000b00  70 61 72 73 65 54 79 70  65 3d 22 52 65 73 6f 75  |parseType="Resou|
00000b10  72 63 65 22 3e 0a 20 20  20 20 20 20 20 20 20 20  |rce">.          |
00000b20  20 20 20 20 20 20 20 20  20 20 20 3c 73 74 52 65  |           <stRe|
00000b30  66 3a 69 6e 73 74 61 6e  63 65 49 44 3e 75 75 69  |f:instanceID>uui|
00000b40  64 3a 62 63 65 39 31 66  66 36 2d 65 61 39 61 2d  |d:bce91ff6-ea9a-|
00000b50  34 36 32 61 2d 38 66 66  37 2d 63 63 65 39 30 31  |462a-8ff7-cce901|
00000b60  66 30 38 63 34 33 3c 2f  73 74 52 65 66 3a 69 6e  |f08c43</stRef:in|
00000b70  73 74 61 6e 63 65 49 44  3e 0a 20 20 20 20 20 20  |stanceID>.      |
00000b80  20 20 20 20 20 20 20 20  20 20 20 20 20 20 20 3c  |               <|
00000b90  73 74 52 65 66 3a 64 6f  63 75 6d 65 6e 74 49 44  |stRef:documentID|
00000ba0  3e 75 75 69 64 3a 62 63  64 33 36 33 61 62 2d 63  |>uuid:bcd363ab-c|
00000bb0  39 33 31 2d 34 65 66 32  2d 38 64 33 61 2d 34 39  |931-4ef2-8d3a-49|
00000bc0  35 36 34 64 32 37 30 31  63 65 3c 2f 73 74 52 65  |564d2701ce</stRe|
00000bd0  66 3a 64 6f 63 75 6d 65  6e 74 49 44 3e 0a 20 20  |f:documentID>.  |
00000be0  20 20 20 20 20 20 20 20  20 20 20 20 20 20 20 20  |                |
00000bf0  3c 2f 73 74 4d 66 73 3a  72 65 66 65 72 65 6e 63  |</stMfs:referenc|
00000c00  65 3e 0a 20 20 20 20 20  20 20 20 20 20 20 20 20  |e>.             |
00000c10  20 20 3c 2f 72 64 66 3a  6c 69 3e 0a 20 20 20 20  |  </rdf:li>.    |
00000c20  20 20 20 20 20 20 20 20  3c 2f 72 64 66 3a 42 61  |        </rdf:Ba|
00000c30  67 3e 0a 20 20 20 20 20  20 20 20 20 3c 2f 78 6d  |g>.         </xm|
00000c40  70 4d 4d 3a 4d 61 6e 69  66 65 73 74 3e 0a 20 20  |pMM:Manifest>.  |
00000c50  20 20 20 20 3c 2f 72 64  66 3a 44 65 73 63 72 69  |    </rdf:Descri|
00000c60  70 74 69 6f 6e 3e 0a 20  20 20 20 20 20 3c 72 64  |ption>.      <rd|
00000c70  66 3a 44 65 73 63 72 69  70 74 69 6f 6e 20 72 64  |f:Description rd|
00000c80  66 3a 61 62 6f 75 74 3d  22 22 0a 20 20 20 20 20  |f:about="".     |
00000c90  20 20 20 20 20 20 20 78  6d 6c 6e 73 3a 78 6d 70  |       xmlns:xmp|
00000ca0  3d 22 68 74 74 70 3a 2f  2f 6e 73 2e 61 64 6f 62  |="http://ns.adob|
00000cb0  65 2e 63 6f 6d 2f 78 61  70 2f 31 2e 30 2f 22 3e  |e.com/xap/1.0/">|
00000cc0  0a 20 20 20 20 20 20 20  20 20 3c 78 6d 70 3a 43  |.         <xmp:C|
00000cd0  72 65 61 74 65 44 61 74  65 3e 32 30 31 30 2d 31  |reateDate>2010-1|
00000ce0  31 2d 31 36 54 31 34 3a  33 32 3a 30 32 2b 30 31  |1-16T14:32:02+01|
00000cf0  3a 30 30 3c 2f 78 6d 70  3a 43 72 65 61 74 65 44  |:00</xmp:CreateD|
00000d00  61 74 65 3e 0a 20 20 20  20 20 20 20 20 20 3c 78  |ate>.         <x|
00000d10  6d 70 3a 4d 6f 64 69 66  79 44 61 74 65 3e 32 30  |mp:ModifyDate>20|
00000d20  31 30 2d 31 31 2d 31 36  54 31 34 3a 33 32 3a 30  |10-11-16T14:32:0|
00000d30  34 2b 30 31 3a 30 30 3c  2f 78 6d 70 3a 4d 6f 64  |4+01:00</xmp:Mod|
00000d40  69 66 79 44 61 74 65 3e  0a 20 20 20 20 20 20 20  |ifyDate>.       |
00000d50  20 20 3c 78 6d 70 3a 4d  65 74 61 64 61 74 61 44  |  <xmp:MetadataD|
00000d60  61 74 65 3e 32 30 31 30  2d 31 31 2d 31 36 54 31  |ate>2010-11-16T1|
00000d70  34 3a 33 32 3a 30 34 2b  30 31 3a 30 30 3c 2f 78  |4:32:04+01:00</x|
00000d80  6d 70 3a 4d 65 74 61 64  61 74 61 44 61 74 65 3e  |mp:MetadataDate>|
00000d90  0a 20 20 20 20 20 20 20  20 20 3c 78 6d 70 3a 43  |.         <xmp:C|
00000da0  72 65 61 74 6f 72 54 6f  6f 6c 3e 41 64 6f 62 65  |reatorTool>Adobe|
00000db0  20 49 6e 44 65 73 69 67  6e 20 43 53 34 20 28 36  | InDesign CS4 (6|
00000dc0  2e 30 2e 36 29 3c 2f 78  6d 70 3a 43 72 65 61 74  |.0.6)</xmp:Creat|
00000dd0  6f 72 54 6f 6f 6c 3e 0a  20 20 20 20 20 20 3c 2f  |orTool>.      </|
00000de0  72 64 66 3a 44 65 73 63  72 69 70 74 69 6f 6e 3e  |rdf:Description>|
00000df0  0a 20 20 20 20 20 20 3c  72 64 66 3a 44 65 73 63  |.      <rdf:Desc|
00000e00  72 69 70 74 69 6f 6e 20  72 64 66 3a 61 62 6f 75  |ription rdf:abou|
00000e10  74 3d 22 22 0a 20 20 20  20 20 20 20 20 20 20 20  |t="".           |
00000e20  20 78 6d 6c 6e 73 3a 69  64 50 72 69 76 3d 22 68  | xmlns:idPriv="h|
00000e30  74 74 70 3a 2f 2f 6e 73  2e 61 64 6f 62 65 2e 63  |ttp://ns.adobe.c|
00000e40  6f 6d 2f 78 6d 70 2f 49  6e 44 65 73 69 67 6e 2f  |om/xmp/InDesign/|
00000e50  70 72 69 76 61 74 65 22  3e 0a 20 20 20 20 20 20  |private">.      |
00000e60  20 20 20 3c 69 64 50 72  69 76 3a 44 6f 63 43 68  |   <idPriv:DocCh|
00000e70  61 6e 67 65 43 6f 75 6e  74 3e 32 37 3c 2f 69 64  |angeCount>27</id|
00000e80  50 72 69 76 3a 44 6f 63  43 68 61 6e 67 65 43 6f  |Priv:DocChangeCo|
00000e90  75 6e 74 3e 0a 20 20 20  20 20 20 3c 2f 72 64 66  |unt>.      </rdf|
00000ea0  3a 44 65 73 63 72 69 70  74 69 6f 6e 3e 0a 20 20  |:Description>.  |
00000eb0  20 20 20 20 3c 72 64 66  3a 44 65 73 63 72 69 70  |    <rdf:Descrip|
00000ec0  74 69 6f 6e 20 72 64 66  3a 61 62 6f 75 74 3d 22  |tion rdf:about="|
00000ed0  22 0a 20 20 20 20 20 20  20 20 20 20 20 20 78 6d  |".            xm|
00000ee0  6c 6e 73 3a 64 63 3d 22  68 74 74 70 3a 2f 2f 70  |lns:dc="http://p|
00000ef0  75 72 6c 2e 6f 72 67 2f  64 63 2f 65 6c 65 6d 65  |url.org/dc/eleme|
00000f00  6e 74 73 2f 31 2e 31 2f  22 3e 0a 20 20 20 20 20  |nts/1.1/">.     |
00000f10  20 20 20 20 3c 64 63 3a  66 6f 72 6d 61 74 3e 61  |    <dc:format>a|
00000f20  70 70 6c 69 63 61 74 69  6f 6e 2f 70 64 66 3c 2f  |pplication/pdf</|
00000f30  64 63 3a 66 6f 72 6d 61  74 3e 0a 20 20 20 20 20  |dc:format>.     |
00000f40  20 3c 2f 72 64 66 3a 44  65 73 63 72 69 70 74 69  | </rdf:Descripti|
00000f50  6f 6e 3e 0a 20 20 20 20  20 20 3c 72 64 66 3a 44  |on>.      <rdf:D|
00000f60  65 73 63 72 69 70 74 69  6f 6e 20 72 64 66 3a 61  |escription rdf:a|
00000f70  62 6f 75 74 3d 22 22 0a  20 20 20 20 20 20 20 20  |bout="".        |
00000f80  20 20 20 20 78 6d 6c 6e  73 3a 70 64 66 3d 22 68  |    xmlns:pdf="h|
00000f90  74 74 70 3a 2f 2f 6e 73  2e 61 64 6f 62 65 2e 63  |ttp://ns.adobe.c|
00000fa0  6f 6d 2f 70 64 66 2f 31  2e 33 2f 22 3e 0a 20 20  |om/pdf/1.3/">.  |
00000fb0  20 20 20 20 20 20 20 3c  70 64 66 3a 50 72 6f 64  |       <pdf:Prod|
00000fc0  75 63 65 72 3e 41 64 6f  62 65 20 50 44 46 20 4c  |ucer>Adobe PDF L|
00000fd0  69 62 72 61 72 79 20 39  2e 30 3c 2f 70 64 66 3a  |ibrary 9.0</pdf:|
00000fe0  50 72 6f 64 75 63 65 72  3e 0a 20 20 20 20 20 20  |Producer>.      |
00000ff0  20 20 20 3c 70 64 66 3a  54 72 61 70 70 65 64 3e  |   <pdf:Trapped>|
00001000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00001030  00 00 00 00 00 00 00 00  0f 14 01 00 10 14 01 00  |................|
00001040  11 14 01 00 ff ff ff 0f  00 00 00 00 00 00 00 00  |................|
00001050  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00001160  59 14 01 00 5a 14 01 00  f4 14 01 00 ff ff ff 0f  |Y...Z...........|
00001170  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00001400

PRO : Mon taf : https://www.webcaf.fr - Mes designs en vente : http://shop.mideel.fr
PASSION : Ocarina FR : http://www.partition-ocarina.fr/ - Mes peintures : https://www.mideel.fr - Mes photos : https://pix.diaspodon.fr/VV666

Hors ligne

#9 Le 06/01/2017, à 19:44

Nasman

Re : [problème] table de partition vide d'une clef USB

J'ai l'impression que c'est mort sad
Trop d'outils semblent avoir été utilisés.

En cas de perte de données, surtout ne plus écrire sur le support dont on veut retrouver les données car toute opération éloigne un peu plus de l'état avant le pb.

Tu ne nous a pas dit quel(s) étaient les systèmes de fichiers de la clé (système de fichiers de la partition où se trouvaient les fichiers source et système de fichiers de la clé de destination).

Et pour rappel :
Ne jamais faire de couper/coller pour copier des fichiers mais un copier/coller car on ne sait jamais si une coupure de courant ou un autre événement ne va pas interrompre le processus.

Dernière modification par Nasman (Le 06/01/2017, à 19:48)


PC fixe sous Bionic 64 bits et portable avec Focal 64 bits

Hors ligne

#10 Le 06/01/2017, à 19:45

MicP

Re : [problème] table de partition vide d'une clef USB

Bonsoir

Les commandes suivantes sont à entrer depuis le compte utilisateur

Pour obtenir des informations au sujet de la clef USB associée au fichier de périphérique /dev/sdi :

udisksctl info -b /dev/sdi

Si une partition a été directement copiée sur la clef (sans table des partitions),
essaye :

udisksctl mount -b /dev/sdi

Pour démonter le système de fichiers :

udisksctl unmount -b /dev/sdi

=======
De toutes façons, sur cette clef USB, il n'y a effectivement pas de MBR et donc pas de tables des partitions

Il faudra donc créer un MBR avec sa table des partitions en utilisant fdisk
et ensuite, créer la ou les partitions pour pouvoir formater cette ou ces partitions avec le type système de fichiers de ton choix.

Dernière modification par MicP (Le 06/01/2017, à 19:48)

Hors ligne

#11 Le 06/01/2017, à 19:51

Nasman

Re : [problème] table de partition vide d'une clef USB

>MicP
A priori Vincent Valentine veut retrouver les données de la clé, ce qui est plus problématique.
La création d'un mbr ou toute autre opération qu'une lecture de la clé compromettra les chances de retrouver les données.


PC fixe sous Bionic 64 bits et portable avec Focal 64 bits

Hors ligne

#12 Le 06/01/2017, à 20:29

Vincent Valentine

Re : [problème] table de partition vide d'une clef USB

J'aurai effectivement voulu retrouver les données ...
Les clefs étaient en FAT, mais16 ou 32, je n'en sais rien.

Je pense aussi que c'est mort.
Je me suis souvenu qu'avant le plantage, il y a eu plein d'erreur d'entrés/sorties .... :-\


PRO : Mon taf : https://www.webcaf.fr - Mes designs en vente : http://shop.mideel.fr
PASSION : Ocarina FR : http://www.partition-ocarina.fr/ - Mes peintures : https://www.mideel.fr - Mes photos : https://pix.diaspodon.fr/VV666

Hors ligne

#13 Le 07/01/2017, à 22:04

MicP

Re : [problème] table de partition vide d'une clef USB

Nasman a écrit :

…A priori Vincent Valentine veut retrouver les données de la clé…

Aucune des 3 lignes de commandes que j'ai proposées ne modifiera quoi que ce soit sur sa clef USB, mais cela permettra peut-être de récupérer les fichiers qui ont été écrits dans ce système de fichiers.
La dernière remarque que j'ai fait dans mon précédent message sera de toutes façons valable s'il veut pouvoir réutiliser cette clef USB.
Mais s'il exécute les deux premières commandes, il aura peut-être la chance de pouvoir récupérer les fichiers qui ont été copiés sur la clef.

=======
@Vincent Valentine donne au moins le retour de la première commande :

udisksctl info -b /dev/sdi

elle nous informera sur ce qu'il est possible de faire sur cette clef car je pense que tu as formaté cette clef sans avoir au préalable créé une table des partitions, puis une ou des partitions à formater.

Même dans ce cas, il est possible que le système de fichiers créé sur la clef soit utilisable.

Dernière modification par MicP (Le 07/01/2017, à 22:07)

Hors ligne

#14 Le 08/01/2017, à 01:04

Vincent Valentine

Re : [problème] table de partition vide d'une clef USB

Ce n'est pas ma clef, formatage du commerce et aucune manip dessus pendant son utilisation.
Merci pour vos différentes participations.

$ udisksctl info -b /dev/sdh
/org/freedesktop/UDisks2/block_devices/sdh:
  org.freedesktop.UDisks2.Block:
    Configuration:              []
    CryptoBackingDevice:        '/'
    Device:                     /dev/sdh
    DeviceNumber:               2160
    Drive:                      '/org/freedesktop/UDisks2/drives/USBest_Technology_USB_Mass_Storage_Device_090630882b1242'
    HintAuto:                   true
    HintIconName:               
    HintIgnore:                 false
    HintName:                   
    HintPartitionable:          true
    HintSymbolicIconName:       
    HintSystem:                 false
    Id:                         
    IdLabel:                    
    IdType:                     
    IdUUID:                     
    IdUsage:                    
    IdVersion:                  
    MDRaid:                     '/'
    MDRaidMember:               '/'
    PreferredDevice:            /dev/sdh
    ReadOnly:                   false
    Size:                       8086618112
    Symlinks:                   /dev/disk/by-id/usb-USBest_Technology_USB_Mass_Storage_Device_090630882b1242-0:0
                                /dev/disk/by-path/pci-0000:00:1d.7-usb-0:1:1.0-scsi-0:0:0:0

PRO : Mon taf : https://www.webcaf.fr - Mes designs en vente : http://shop.mideel.fr
PASSION : Ocarina FR : http://www.partition-ocarina.fr/ - Mes peintures : https://www.mideel.fr - Mes photos : https://pix.diaspodon.fr/VV666

Hors ligne

#15 Le 08/01/2017, à 07:18

MicP

Re : [problème] table de partition vide d'une clef USB

Bonjour

Merci pour le retour de commande.

J'espérais qu'un système de fichiers soit reconnu, mais hélas rien de neuf…

Ceci dit, comme la clef est lisible, tu devrais plutôt travailler sur un fichier copie du contenu de cette clef,
ou au moins créer un fichier copie de sauvegarde (avec dd) du contenu brut de cette clef avant de faire une modification sur la clef.

Dernière modification par MicP (Le 09/01/2017, à 11:10)

Hors ligne

#16 Le 08/01/2017, à 13:57

Vincent Valentine

Re : [problème] table de partition vide d'une clef USB

Aucun outils ne voit de système de fichier ...
Je crois que c'est mort ...

Les fichiers qui avaient été copié sur une autre clef sont tous illisible. Et depuis peu, j'ai appris qu'une sauvegarde partiel de la clef avait été faite sans plantage (copie de 1.5Go de doc de travail), et aucun fichier n'est lisible.
Elle devait avoir un sacré plomb dans l'aile depuis un moment. Ça fait juste chier de s'en apercevoir tardivement ... :-(

Merci à tous.


PRO : Mon taf : https://www.webcaf.fr - Mes designs en vente : http://shop.mideel.fr
PASSION : Ocarina FR : http://www.partition-ocarina.fr/ - Mes peintures : https://www.mideel.fr - Mes photos : https://pix.diaspodon.fr/VV666

Hors ligne