[gull] caractères spéciaux dans nom de fichier sur partition ntfs

[Félix Hauri]

On Fri, Apr 08, 2011 at 10:35:33PM +0200, Yves Martin wrote:
> On Fri, 2011-04-08 at 21:36 +0200, Sebastien Chassot wrote:

> > Sur un disque en ntfs...
> > ...
> > "-rw-r--r--  1 user user 171159 2011-03-26 10:04  $%&\'-/,.&65   "
> > ...
> > erreur (stdin: Input/output error). 
Comme Erik, je suis pessimiste quand à la suite...

> Hum, est-ce bien raisonnable d'essayer de manipuler du NTFS depuis
> Linux ?
Oui, des commandes ``bas niveau'' comme dd te permettent de copier
*tout* le disque et travailler sur des copies.

A noter que quand tu commance à avoir des I/O-Error, sur un disque dur,
très souvent, tu en aurras de plus en plus... (à chaque lecture, un peu
plus...;)

> 
> > même en échappant les caractères spéciaux je n'y arrive pas. stderr
> > nomme le fichier "\$\%\&\'\-\/\,.\&65" alors qu'il me semble que ce
> > devrait être "\$\%\&\\'\-\/\,.\&65".
Pas la peine de chercher de ce coté, en particulier si tu n'a pas cela
sur *tout* le disque ou si tu as déjà pu le lire avec Linux préalablement.

I/O-Error signifie que des block n'ont pu être lus et donc l'interprétation
des contenus de répertoires est farfelue.

> >         - Est-ce que ça pourrait être régler avec une option au montage
> >         (mount -o iocharset=???) ? Je vois juste pas à quoi "$%&" peut
Bof, à tester, à tout hasard, mais je n'y crois pas...

> Du kanji ?
Si tu n'as rien d'autre à faire...

> >         - Est-ce que vous croyez qu'il y aurait moyen de tout remettre
> >         en ordre avec une commande du style `dd if=/dev/sda1 | iconv >
> >         image.iso` ou avec un sed s/??/??/g ?
Non.

dd te serait utile pour travailler sur une copie, avec les 
options ``conv=noerror,sync''

> >         outils bas-nivaux ? Mais lesquels ? 
...
> >         - Est-ce qu'il y aurait moyen de récupérer les fichiers blocs
> >         par blocs sans passer par le système de fichiers ?
> 
> Tu peux toujours essayer PhotoRec et/ou TestDisk. Ils sont très
> efficaces pour des données "en clair".

Oui, pour récupérer quelque fichier, j'ai trouvé égallement ``autopsy''
qui n'est pas mal du tout.

> >         - Ces datas viennent d'archive, peut-être que les fichiers ont
> >         été encryptés, compressés, bidouillés,... ? C'est sur un disque
> >         ext, peut-être EFS a été utilisé mais windows n'arrive pas à
> >         accéder à ces fichiers non plus ?

Si c'est encrypté, 'faudrait les clef, si c'est compressé alors je suis 
*très* pessimiste... sinon, scrounge-ntfs, autopsy ou testdisk (photorec)
doivent pouvoir te permettre de ``récupérer des trucs''... (mais pas tout,
à priori)

> Par curiosité, est-ce que tu pourrais faire un "dd" des 2 premiers Mo de
> la partition pour que je puisse me faire une idée ?
>  # dd if=/dev/sda1 of=/tmp/debut-ntfs.dump bs=262144 count=8
>  # gzip /tmp/debut-ntfs.dump
(Pkoi bs=262144 ??)

Attention aux options conv=noerror,sync

> Au passage, si ton "dmesg" contient des erreurs d'I/O, ne "joue" plus
> avec ce disque et fait vite un "dd_rescue" sur un autre support
> suffisamment volumineux pour travailler ensuite sur cette copie.

CQFD!

Utilises un support disposant d'au moins 2,5x la taille de ton disque
original!

Que tu formattes (en ext2 ou ext3), effectue le dd vers un fichier:
# dd if=/dev/sda of=/mnt/disque_defect.img bs=4096 conv=noerror,sync

puis tu pourras accéder a ta partition avec losetup ou dmsetup.

# losetup -f -o $((63*512)) /mnt/disque_defect.img
(si ton disque original à une géometrie a 63 secteurs / cylindre)...

La commande file te renseignera:
# file -b /mnt/disque_defect.img
x86 boot sector; partition 1: ID=0xfd, active, starthead 1, startsector 63, ...

Dans ce cas, le ``start sector'' de la ``partition 1'' est le nro 63...

Bonne chance!

--
 Félix Hauri  -  <felix at f-hauri.ch>  -  http://www.f-hauri.ch