FAQ SearchLogin
Tuxera Home
View unanswered posts | View active topics It is currently Sat May 15, 2021 02:53



Post new topic Reply to topic  [ 5 posts ] 
lost To of files... 
Author Message

Joined: Wed Sep 19, 2012 14:10
Posts: 3
Post lost To of files...
Hello,

Here is my problem:

first of all let me describe the config:

I have a EFI PC with new GPT partitions on its 3To hard disk. Dual boot W7 w64 and Ubuntu 12.4 w64 Partition are distribued like this:

-> one or 2 small boot partition for efi magic...
-> an NTFS system partitions, labelled "OS", for windows 7 64 bits (seen as c:), rougly 1To
-> an NTFS data partition, labelled "DATA", mounted as "D:" by windows 7, rougly 1.8To
-> an ext4 partition for linux ubuntu, rougly 250Go
-> a swap partition for ubuntu, some Go
-> a recovery NTFS partition, not mounted

The "DATA" partition was resized using linux parted in order to make room for linux partitions.

Thru linus i mount the "DATA" partition with ntfs-3g onto /media/DATA using ubuntu file browser

Enough for the config, lest describe the story :

i bought this PC 4 weeks ago, and since this day i manage to copy aaaaaaaaaaaaall my numberous data archives onto DATA partition. This include the use of recovery/forensic tools for old or damaged disks (20 disks, the oldest from 1995) and partitions (using external disks usb boxes) and same activity for hundreds of CD, the decompression of all zip, tars, iso, squashfs files ... etc... At this time the DATA partition was filled by 1,4To of files and the job is done for 75%.. except that i discovered that i forgetted a superb 500Go disk and another of 1To. (if someone want to know how i can forget somewhere 1,5To of disk... it is another story ... :lol: ).

Alls those operations are done with ubuntu (nobody wants to make recovery or forensics under windows :roll: )

So i have a little pb of disk space. But:

Due to the nature of recovery operation (specially use of forensic tools) there exist on "DATA" numerous multiple copy of sames files.

So i used a linux tool named "fdupes" witch is able to find quickly any exact copies of files.

One alternative is to uses md5sum but nobody want to make md5sum of 1e6 files of 1e12 bytes. Even with a data cruncher CPU (i have it) this is ...hum...well... quite slow :)

fdupes can also make auomatically hard links between identicals files (hard links is a classical unix file concept allowing one file to have multiples equivalent names in file hierarchy).

By a strange curiosity of Microsoft management, at the time they defined 1st version of NTFS, they decided to be "POSIX" compliant, so they integrate hard link concept in their filesystem.

I did modify fdupes because actual ubuntu fdupes version does not cope with linking errors, destroying file names when link system call does not succed.

Usually it is not a big pb because link does not fail often (it does not consume disk space, except for 1 directory entry), and in my case it reduce disk space.

The problem is that even ext4, but also NTFS , ext 2/3 or other "POSIX" filesystems (special exception for squashfs) have some limits in the number of links for one file. for ex: ext2/3 seems to limit to 1000 ones, ext4 to 65000, and NTFS i did not check it.

Obviously when managing raw mixed archives of To of size, one may encounter hundred of thousand of copy of trivials files (the most often is... the empty one). So link errors are probable, if not certain.

After correcting fdupes i launched it on my DATA disk... waiting a night... and disk space go from 1.4To to 900Go, letting me good hope because 1.5To of these disk contains mostly archives already contained in my new PC.

So i begin to extract datas from the 500Go disk. on essential archive was severely damaged , so i modified some recovery tool for it, but during the bugfix i begin to notice strange behavior: rm -rf * in a subdir of DATA disk, made as root, and containing only freshly created dirs & files report non empty dirs.

Sadly i did not investigate the problem at this time... I was thinking that bugs in creation of dirs/files in the tool has created "undeletable" and "unlistable" files... after all, it is NTFS structure... and who understand deep magic of ntfs??? :)

Once satisfied by my version of the recovery tool i let it work onto the 500Go disk, putting recovered files onto "DATA" disk during the night...

On morning, operation was not finished but i noticed lot of file creation errors... bad news. Disk was not full, number of files seems not exessive...

I stop the process, try to create one file... nop. one dir nop.... :shock: :? everything behave like if the partition become read only...

Here is the best stupidity: i was think in my personal brain: "bof... it is probably a small pb in NTFS structure causing ntfs-3g to go on safe read only mode ... maybe excess of hard link ... the simplest way is to let windows checkdisk to correct it and after getting back to ubuntu.

So i reboot the pc, and choose to boot windows 7.

Without surprise, checkdisk was made on D: showing a relatively short list of message before boot process blank screen.

So i logon with confidence... click on D: disk... an discover an beautiful empy disk!!!!

here i stopped the PC and "me voici" (here i am).

Any idea?


Wed Sep 19, 2012 15:45
Profile
NTFS-3G Lead Developer

Joined: Tue Sep 04, 2007 17:22
Posts: 1286
Post Re: lost To of files...
Hi,

Quote:
I have a EFI PC with new GPT partitions on its 3To hard disk. Dual boot W7 w64 and Ubuntu 12.4 w64

This must be a disk with 4K-sized sectors...
Quote:
make md5sum of 1e6 files of 1e12 bytes.

If you are using gigantic files, it is advisable to use a big cluster size (probably the maximum, which is 65536 for ntfs), you will less struck by fragmentation issues.
Quote:
have some limits in the number of links for one file. for ex: ext2/3 seems to limit to 1000 ones, ext4 to 65000, and NTFS i did not check it.

Windows has set a limit of 1023 hard links on ntfs, see
http://msdn.microsoft.com/en-us/library ... 60(v=vs.85).aspx
Linux may accept more links, but this is unwise if you want access by both systems.
Quote:
I did modify fdupes because actual ubuntu fdupes version does not cope with linking errors

Better avoid getting into errors by restricting to 1000 hard links. If you still get errors, try to identify the real cause.
Quote:
Without surprise, checkdisk was made on D: showing a relatively short list of message before boot process blank screen.

Do you mean that chkdsk crashed, leading to an OS crash (a BSOD ?) How much main memory do you have (recent chkdsks use a lot of memory).
Quote:
Any idea?

First only mount this partition read-only.
Then locate the chkdsk log. It should be in /System Volume Information/Chkdsk/Chkdsk* and there is probably useful information there (encoded in UTF16LE)
Also post the file system configuration (replace xxx below by partition id like sda3)
Code:
ntfsinfo -fm /dev/xxx

I do not expect to be able to recover the data, let us at least try to get an explanation....

Regards

Jean-Pierre


Wed Sep 19, 2012 18:03
Profile

Joined: Wed Sep 19, 2012 14:10
Posts: 3
Post Re: lost To of files...
Thanks a lot for your answer

Quote:
Quote:
I have a EFI PC with new GPT partitions on its 3To hard disk. Dual boot W7 w64 and Ubuntu 12.4 w64

This must be a disk with 4K-sized sectors...

Quote:
make md5sum of 1e6 files of 1e12 bytes.

If you are using gigantic files, it is advisable to use a big cluster size (probably the maximum, which is 65536 for ntfs), you will less struck by fragmentation issues.

no, i have normal sized files, but i have so much files that the total size become diffcult to manage.
Quote:
Quote:
have some limits in the number of links for one file. for ex: ext2/3 seems to limit to 1000 ones, ext4 to 65000, and NTFS i did not check it.

Windows has set a limit of 1023 hard links on ntfs, see
http://msdn.microsoft.com/en-us/library ... 60(v=vs.85).aspx
Linux may accept more links, but this is unwise if you want access by both systems.
Quote:
I did modify fdupes because actual ubuntu fdupes version does not cope with linking errors

Better avoid getting into errors by restricting to 1000 hard links. If you still get errors, try to identify the real cause.

good idea. I take it... but the sources of the modified version was on the lost data :(
Quote:

Quote:
Without surprise, checkdisk was made on D: showing a relatively short list of message before boot process blank screen.


Do you mean that chkdsk crashed, leading to an OS crash (a BSOD ?) How much main memory do you have (recent chkdsks use a lot of memory).

Sorry, i was unclear. Checkdisk goes without BSOD (i have 16Go of ram), but as ususal the windows boot process continue immediatly after so it is not possible to read checkdisk messages.
Quote:

Quote:
Any idea?


First only mount this partition read-only.
Then locate the chkdsk log. It should be in /System Volume Information/Chkdsk/Chkdsk* and there is probably useful information there (encoded in UTF16LE)
Also post the file system configuration (replace xxx below by partition id like sda3)
Code:
ntfsinfo -fm /dev/xxx

Ok i will do that as soon as possible.
Quote:
I do not expect to be able to recover the data, let us at least try to get an explanation....

I agree with you. If i can help ...
After that i will seriously envision to redo the wole recovery on a ext4 partition, instead of an NTFS. The bad news is that i will lost direct access inside it on Windows.
Quote:
Regards

Jean-Pierre

Thanks,
Michel.


Thu Sep 20, 2012 00:32
Profile

Joined: Wed Sep 19, 2012 14:10
Posts: 3
Post Re: lost To of files...
here are the datas:
------------------------------
ntfsinfo -fm /dev/disk/by-label/DATA
Volume Information
Name of device: /dev/disk/by-label/DATA
Device state: 11
Volume Name: DATA
Volume State: 27
Volume Version: 3.1
Sector Size: 512
Cluster Size: 4096
Index Block Size: 4096
Volume Size in Clusters: 359725310
MFT Information
MFT Record Size: 1024
MFT Zone Multiplier: 0
MFT Data Position: 24
MFT Zone Start: 786432
MFT Zone End: 45752095
MFT Zone Position: 786432
Current Position in First Data Zone: 45752095
Current Position in Second Data Zone: 0
LCN of Data Attribute for FILE_MFT: 786432
FILE_MFTMirr Size: 4
LCN of Data Attribute for File_MFTMirr: 2
Size of Attribute Definition Table: 2560
FILE_Bitmap Information
FILE_Bitmap MFT Record Number: 6
State of FILE_Bitmap Inode: 80
Length of Attribute List: 0
Attribute List: (null)
Number of Attached Extent Inodes: 0
FILE_Bitmap Data Attribute Information
Decompressed Runlist: not done yet
Base Inode: 6
Attribute Types: not done yet
Attribute Name Length: 0
Attribute State: 3
Attribute Allocated Size: 44965888
Attribute Data Size: 44965664
Attribute Initialized Size: 44965664
Attribute Compressed Size: 0
Compression Block Size: 0
Compression Block Size Bits: 0
Compression Block Clusters: 0
--------------------

And here is the log of checkdisk (sorry it is in french):
--------------------




Vérification du système de fichiers sur D:

Le type du système de fichiers est NTFS.

Le nom de volume est DATA.





L’intégrité de l’un de vos disques doit être vérifiée.

Vous pouvez annuler cette vérification, mais son exécution est

fortement recommandée.

Windows va maintenant vérifier le disque.

Impossible d’interroger LCN depuis VCN 0x16c000 pour l’attribut de type 0x80.

L’attribut non résident de type 0x80 est incohérent. La longueur

de donnée valide est 0x16c040000, taille de fichier 0x16c040000, et longueur allouée 0x4000.

L’attribut non résident de type 0x80 est incohérent. La longueur

de donnée valide est 0x16c040000, taille de fichier 0x4000, et longueur allouée 0x4000.



CHKDSK est en train de vérifier les fichiers (étape 1 sur 3)...

L’entrée de liste d’attributs endommagée de type de code

48 dans le fichier 0 a été supprimée.

Impossible de trouver le FRS enfant 0x10 de numéro de séquence 0x1.

L’entrée de liste d’attributs endommagée de type de code

128 dans le fichier 0 a été supprimée.

Impossible de trouver le FRS enfant 0x5b0000 de numéro de séquence 0x1.

L’entrée de liste d’attributs endommagée de type de code

128 dans le fichier 0 a été supprimée.

Impossible de trouver le FRS enfant 0x14 de numéro de séquence 0x15.

L’entrée de liste d’attributs endommagée de type de code

128 dans le fichier 0 a été supprimée.

Impossible de trouver le FRS enfant 0x15 de numéro de séquence 0x16.

L’entrée de liste d’attributs endommagée de type de code

128 dans le fichier 0 a été supprimée.

Impossible de trouver le FRS enfant 0x16 de numéro de séquence 0x1.

L’entrée de liste d’attributs endommagée de type de code

128 dans le fichier 0 a été supprimée.

Impossible de trouver le FRS enfant 0x17 de numéro de séquence 0x1.

Les attributs de type 0x80 et de balise d’instance 0x1 dans le fichier 0x0

ont une longueur allouée de 0x16c040000 au lieu de 0x4000.

L’entrée de liste d’attributs endommagée de type de code

128 dans le fichier 0 a été supprimée.

Impossible de localiser l’attribut de balise d’instance 0x1 et de référence

de segment 0x1000000000000. Le type d’attribut attendu est 0x80.

Suppression de l’enregistrement d’attribut endommagé (128, "")

du segment d’enregistrement de fichier 0.

16 enregistrements de fichier traités.


La vérification des fichiers est terminée.

0 enregistrements de grand fichier traités.


0 enregistrements de fichier incorrect traités.


0 enregistrements EA traités.


Correction des erreurs de nom de fichier dans le segment d’enregistrement de

fichier système 0.

0 enregistrements d’analyse traités.


CHKDSK est en train de vérifier les index (étape 2 sur 3)...

Une entrée d’index pour l’index $I30 dans le fichier 0x5 pointe vers le

fichier 0x25 qui est au-delà du MFT.

Suppression de l’entrée d’index $RECYCLE.BIN dans l’index $I30 du fichier 5.

Une entrée d’index pour l’index $I30 dans le fichier 0x5 pointe vers le

fichier 0x2c4584 qui est au-delà du MFT.

Suppression de l’entrée d’index .Trash-1000 dans l’index $I30 du fichier 5.

Une entrée d’index pour l’index $I30 dans le fichier 0x5 pointe vers le

fichier 0x59e qui est au-delà du MFT.

Suppression de l’entrée d’index 4a4da934 dans l’index $I30 du fichier 5.

Une entrée d’index pour l’index $I30 dans le fichier 0x5 pointe vers le

fichier 0x36 qui est au-delà du MFT.

Suppression de l’entrée d’index clef_8g dans l’index $I30 du fichier 5.

Une entrée d’index pour l’index $I30 dans le fichier 0x5 pointe vers le

fichier 0x18510c qui est au-delà du MFT.

Suppression de l’entrée d’index decompression.texte dans l’index $I30 du fichier 5.

Une entrée d’index pour l’index $I30 dans le fichier 0x5 pointe vers le

fichier 0x226821 qui est au-delà du MFT.

Suppression de l’entrée d’index divx2pass.log dans l’index $I30 du fichier 5.

Une entrée d’index pour l’index $I30 dans le fichier 0x5 pointe vers le

fichier 0x11 qui est au-delà du MFT.

Suppression de l’entrée d’index found.000 dans l’index $I30 du fichier 5.

Une entrée d’index pour l’index $I30 dans le fichier 0x5 pointe vers le

fichier 0x226009 qui est au-delà du MFT.

Suppression de l’entrée d’index Images dans l’index $I30 du fichier 5.

Une entrée d’index pour l’index $I30 dans le fichier 0x5 pointe vers le

fichier 0x225f89 qui est au-delà du MFT.

Suppression de l’entrée d’index Musique dans l’index $I30 du fichier 5.

Une entrée d’index pour l’index $I30 dans le fichier 0x5 pointe vers le

fichier 0x226008 qui est au-delà du MFT.

Suppression de l’entrée d’index Sauvegardes dans l’index $I30 du fichier 5.

Une entrée d’index pour l’index $I30 dans le fichier 0x5 pointe vers le

fichier 0x23 qui est au-delà du MFT.

Suppression de l’entrée d’index System Volume Information dans l’index $I30 du fichier 5.

Une entrée d’index pour l’index $I30 dans le fichier 0x5 pointe vers le

fichier 0x23 qui est au-delà du MFT.

Suppression de l’entrée d’index SYSTEM~1 dans l’index $I30 du fichier 5.

Une entrée d’index pour l’index $I30 dans le fichier 0x5 pointe vers le

fichier 0x29 qui est au-delà du MFT.

Suppression de l’entrée d’index ubuntu dans l’index $I30 du fichier 5.

Une entrée d’index pour l’index $I30 dans le fichier 0x5 pointe vers le

fichier 0x2255f3 qui est au-delà du MFT.

Suppression de l’entrée d’index Vacances 06-07 dans l’index $I30 du fichier 5.

Une entrée d’index pour l’index $I30 dans le fichier 0x5 pointe vers le

fichier 0x2255ec qui est au-delà du MFT.

Suppression de l’entrée d’index videos dans l’index $I30 du fichier 5.

Une entrée d’index pour l’index $I30 dans le fichier 0x5 pointe vers le

fichier 0x57 qui est au-delà du MFT.

Suppression de l’entrée d’index wubildr dans l’index $I30 du fichier 5.

L’entrée d’index $ObjId de l’index $I30 dans le fichier 0xb pointe sur un fichier

non utilisé 0x19.

Suppression de l’entrée d’index $ObjId dans l’index $I30 du fichier 11.

L’entrée d’index $Quota de l’index $I30 dans le fichier 0xb pointe sur un fichier

non utilisé 0x18.

Suppression de l’entrée d’index $Quota dans l’index $I30 du fichier 11.

22 entrées d’index traitées.


L’entrée d’index $Reparse de l’index $I30 dans le fichier 0xb pointe sur un fichier

non utilisé 0x1a.

Suppression de l’entrée d’index $Reparse dans l’index $I30 du fichier 11.

L’entrée d’index $RmMetadata de l’index $I30 dans le fichier 0xb pointe sur un fichier

non utilisé 0x1b.

Suppression de l’entrée d’index $RmMetadata dans l’index $I30 du fichier 11.

La vérification des index est terminée.

0 fichiers non indexés analysés.


0 fichiers non indéxés récupérés.


Création du fichier d’id de l’objet.

Insertion d’une entrée d’index dans l’index $I30 du fichier 11.

Création de l’index $O pour le fichier 17.

L’ID d’objet dans le fichier 0x3 n’apparaît pas dans l’index de

l’ID d’objet dans le fichier 0x11.

Insertion d’une entrée d’index dans l’index $O du fichier 17.

Création du fichier de point d’analyse.

Insertion d’une entrée d’index dans l’index $I30 du fichier 11.

Création de l’index $R pour le fichier 18.

Création du fichier quota.

Insertion d’une entrée d’index dans l’index $I30 du fichier 11.

Création de l’index $O pour le fichier 19.

Création de l’index $Q pour le fichier 19.

Insertion de l’enregistrement de quota par défaut vers l’index $Q du

fichier 19.

CHKDSK est en train de vérifier les descripteurs de sécurité (étape 3 sur 3)

24 SD/SID de fichiers traités.


Nettoyage en cours de 24 entrées d’index inutilisées à partir de l’index $SII

du fichier 0x9.

Nettoyage en cours de 24 entrées d’index inutilisées à partir de l’index $SDH

du fichier 0x9.

Nettoyage en cours de 24 descripteurs de sécurité non utilisés.

La vérification des descripteurs de sécurité est terminée.

Insertion d’un attribut de données dans le fichier 0.

4 fichiers de données traités.


Le miroir MFT est différent du MFT.

Correction des erreurs dans le miroir de la table de fichiers maîtres (MFT).

Correction des erreurs dans l’attribut DATA de la table de fichiers

maîtres (MFT).

CHKDSK a découvert de l’espace libre marqué alloué dans la

bitmap de la table de fichiers maîtres (MFT).

CHKDSK a découvert de l’espace libre marqué alloué dans la bitmap du volume.

Windows a effectué des corrections sur le système de fichiers.



1438901240 Ko d’espace disque au total.

20 Ko dans 8 index.

0 Ko dans des secteurs défectueux.

109888 Ko utilisés par le système.

65536 Ko occupés par le fichier journal.

1438791332 Ko disponibles sur le disque.



4096 octets dans chaque unité d’allocation.

359725310 unités d’allocation au total sur le disque.

359697833 unités d’allocation disponibles sur le disque.



Informations internes :

10 00 00 00 10 00 00 00 0b 00 00 00 00 00 00 00 ................

01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00


Thu Sep 20, 2012 09:32
Profile
NTFS-3G Lead Developer

Joined: Tue Sep 04, 2007 17:22
Posts: 1286
Post Re: lost To of files...
Hi Michel,

Code:
Sector Size: 512

This is unexpected on a 3 TB disk. Apparently the partition was formatted by Windows (or modified by chkdsk), and this should only lead to performance issues if it were a 4K sector disk.
Can you confirm how it was initially formatted ? If it were formatted by mkntfs, which version were you using (type "sudo mkntfs -V") ?
Quote:
Volume Size in Clusters: 359725310

This is 1.47TB (or 1372GiB), not 1.8 TB, and you filled it up with 1.4TB of data....
Code:
CHKDSK est en train de vérifier les fichiers (étape 1 sur 3)...
L’entrée de liste d’attributs endommagée de type de code
48 dans le fichier 0 a été supprimée.
Impossible de trouver le FRS enfant 0x10 de numéro de séquence 0x1.
L’entrée de liste d’attributs endommagée de type de code
128 dans le fichier 0 a été supprimée.

So chkdsk has gone mad from the start. The file 0 is the one which opens the door to all files, and chkdsk has deleted the essential clues.

Something has probably overflowed somewhere....

Quote:
i will seriously envision to redo the wole recovery on a ext4 partition

I wish you better luck.

Regards

Jean-Pierre


Thu Sep 20, 2012 11:21
Profile
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 5 posts ] 


Who is online

Users browsing this forum: No registered users and 4 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
cron
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group.
Original forum style by Vjacheslav Trushkin.