#1 Le 02/01/2017, à 18: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, à 19: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, à 18: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, à 19: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, à 17: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, à 11: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, à 14: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, à 14: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, à 18: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, à 18:15)
PC fixe sous Bionic 64 bits et portable avec Focal 64 bits
Hors ligne
#8 Le 06/01/2017, à 18: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, à 18:44
- Nasman
Re : [problème] table de partition vide d'une clef USB
J'ai l'impression que c'est mort
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, à 18:48)
PC fixe sous Bionic 64 bits et portable avec Focal 64 bits
Hors ligne
#10 Le 06/01/2017, à 18: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, à 18:48)
Hors ligne
#11 Le 06/01/2017, à 18: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, à 19: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, à 21:04
- MicP
Re : [problème] table de partition vide d'une clef USB
…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, à 21:07)
Hors ligne
#14 Le 08/01/2017, à 00: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, à 06: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, à 10:10)
Hors ligne
#16 Le 08/01/2017, à 12: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