All times are UTC - 5 hours [ DST ]




Post new topic Reply to topic  [ 60 posts ]  Go to page Previous  1, 2, 3  Next
Author Message
 Post subject: Re: Weird logical issue (“RAW” NTFS partition)
PostPosted: June 19th, 2018, 18:26 
Offline
User avatar

Joined: December 19th, 2006, 8:49
Posts: 9981
Location: Portugal
abolibibelot wrote:
(...) So, with all due respect, although it is certainly a wise course of action for the apparently common hardware / firmware failures this range of drives seems to be plagued with, I don't think that it is relevant in this particular case.


Ok !

Good luck with that data extraction !

_________________
1Q9xrDTzTddUXeJAFRn37aqh1Yr6buDCdw - (Bitcoin Donations)
paypal.me/Spildit - (PayPal Donations)
The HDD Oracle - Platform for OPEN research on Data Recovery.


Top
 Profile  
 
 Post subject: Re: Weird logical issue (“RAW” NTFS partition)
PostPosted: June 20th, 2018, 2:04 
Offline

Joined: November 22nd, 2017, 21:47
Posts: 166
Location: France
@fzabkar
Quote:
CHS mode assigns 10 bits for the cylinder number, resulting in a limit of 1024 cylinders (0 - 1023). In CHS mode, sector numbers count from 1, not 0 (seems crazy, but that's the way it is).
This site should tell you everything you want to know about partition tables:
MBR/EBR Partition Tables:
http://thestarman.pcministry.com/asm/mbr/PartTables.htm

I had already read articles on the subject, but it's hard to register without concrete examples ; this one is clear and thorough, definitely helpful. I'm begining to have a better grasp of it, quite confusing indeed...

Quote:
I have just tested an NTFS volume and confirmed that the first cluster of the $MFT is byte-for-byte identical to the first cluster of $MFTMirr.

Yes, that's its purpose, from what I understand $MFTMirr (for “mirror”) is just a backup of the first cluster of the actual $MFT (and only the first – I've read repeatedly that there was a “secondary” MFT or a “backup” MFT on a NTFS partition, meaning a complete copy, which is not true), and it's supposed to allow those crucial first four MFT records to be fixed in case they get corrupted. But in this case, three of them have somehow been corrupted in both the MFT and its (very partial) mirror simultaneously.
Again, is there a simple way to recreate them ? Or to “retro-engineer” them by analysing valid corresponding records from other partitions, and replacing some values to reflect the actual sizes and timestamps of each file on this partition ? Or is this a case where you would just extract the files, re-format, and re-transfer the files without thinking twice about the intricacies of the filesystem ?
Now all the files have been extracted with no issue, so there's no risk of losing anything, I'd like to fix the partition in-place if possible, if only for the sheer challenge of it (even though I might end up spending more time figuring it out than I would to get rid of the issue with the basic method above !).
The most problematic one is probably $Volume, as it is resident, meaning that not only the record but the actual contents of the file have been lost, and it apparently contains a unique identificator representing each partition (and also the partition name but that's not important as it can't be left empty and changed later on). I don't know if that ID can be randomly defined, if it has to conform to a specific pattern, and so on. It is probably because of the absence of that particular file that the partition can't be accessed.


Top
 Profile  
 
 Post subject: Re: Weird logical issue (“RAW” NTFS partition)
PostPosted: June 20th, 2018, 2:34 
Offline

Joined: November 22nd, 2017, 21:47
Posts: 166
Location: France
Here are two valid $Volume MFT records from other NTFS partitions, and the corrupted one :
Attachment:
MFT $Volume SSD Sandisk partition “TEMP”.png
MFT $Volume SSD Sandisk partition “TEMP”.png [ 136.88 KiB | Viewed 1287 times ]

Attachment:
MFT $Volume WD20EARX-WCAZAJ971138.png
MFT $Volume WD20EARX-WCAZAJ971138.png [ 140.69 KiB | Viewed 1287 times ]

Attachment:
MFT $Volume ST2000DM001-1ER164.png
MFT $Volume ST2000DM001-1ER164.png [ 120.19 KiB | Viewed 1287 times ]


Again, can I rebuild the third one by assembling static bits from the two others and replacing the changing values with the correct informations about each file ?
Should the Volume ID be exactly the same, or can it be randomly defined, so long as it doesn't conflict with another ? Does the system store those IDs somewhere, even for the drives which are not currently connected ?


Top
 Profile  
 
 Post subject: Re: Weird logical issue (“RAW” NTFS partition)
PostPosted: June 20th, 2018, 18:25 
Offline
User avatar

Joined: September 8th, 2009, 18:21
Posts: 11010
Location: Australia
@abolibibelot, ISTM that you should take this opportunity to learn about NTFS metafiles. I could watch you and learn something as well. :-)

This seems to be a good resource:
http://dubeyko.com/development/FileSystems/NTFS/ntfsdoc.pdf

If you can find it, here is another good resource:

NTFS Forensics: A Programmers View of Raw Filesystem Data Extraction (Jason Medeiros, Grayscale Research 2008).

BTW, DMDE can display all the metadata attributes, eg ...

Code:
LBA:70021380           vol.sec:6291462 Clus:786432 sec:6 (MFT 3)
[-] File #3 ======== (3) ====        ==================
     magic ("FILE"):            FILE
     fixups offset:               30h
     fixups count:                 3
     LSNlo:                 022F0095h
     LSNHi:                 00000000h
     seq. number:                  3
     hlink number:                 1
     attrs offset:                38h
     flags:                        1h
     used size:                  1F0h      496
     record size:                400h     1024
     basefileref:                  0
     0x24:                         0h
     basefileref seq.:             0
     next attribute #:             7
     0x2A:                         0h
     file #:                       3
     fixup:                     0045h
[-] #0              $STANDARD_INFORMATION
       Attr. type:                      10h
       Attr. length:                    48h         72
       Non-resident:                     0
       Attrname len:                     0
       Attrname ofs:                    18h
       Flags:                            0h  -- --
       Attr. number:                     0
       Data Size:                       30h         48
       Data Offset:                     18h
              created:          2015-05-26 08:59:04.501
              modified:         2015-05-26 08:59:04.501
              changed:          2015-05-26 08:59:04.501
              accessed:         2015-05-26 08:59:04.501
              attrs:            -HS------------- ----------------
              Max versions:     0
              Version:          0
              Class Id:         0
[-] #1              $FILE_NAME
       Attr. type:                      30h
       Attr. length:                    68h        104
       Non-resident:                     0
       Attrname len:                     0
       Attrname ofs:                    18h
       Flags:                            0h  -- --
       Attr. number:                     1
       Data Size:                       50h         80
       Data Offset:                     18h
              directory:        5           (5    )
              created:          2015-05-26 08:59:04.501
              modified:         2015-05-26 08:59:04.501
              changed:          2015-05-26 08:59:04.501
              accessed:         2015-05-26 08:59:04.501
              allocated:        0
              size:             0
              attrs:            -HS------------- ----------------
              reparse:          0
              name len:         7
              posix:            3
              name:             $Volume
[-] #6              Other Attribute
       Attr. type:                      40h
       Attr. length:                    28h         40
       Non-resident:                     0
       Attrname len:                     0
       Attrname ofs:                     0h
       Flags:                            0h  -- --
       Attr. number:                     6
       Data Size:                       10h         16
       Data Offset:                     18h
       Hex:
       000: DE 28 17 04 10 10 A5 4B B9 35 E0 07 C6 36 F3 9E  Þ(....Â¥K¹5à.Æ6óž
[-] #2              $SECURITY_DESCRIPTOR
       Attr. type:                      50h
       Attr. length:                    80h        128
       Non-resident:                     0
       Attrname len:                     0
       Attrname ofs:                    18h
       Flags:                            0h  -- --
       Attr. number:                     2
       Data Size:                       68h        104
       Data Offset:                     18h
       Hex:
       000: 01 00 04 80 48 00 00 00 58 00 00 00 00 00 00 00  ...€H...X.......
       010: 14 00 00 00 02 00 34 00 02 00 00 00 00 00 14 00  ......4.........
       020: 9F 01 12 00 01 01 00 00 00 00 00 05 12 00 00 00  Ÿ...............
       030: 00 00 18 00 9F 01 12 00 01 02 00 00 00 00 00 05  ....Ÿ...........
       040: 20 00 00 00 20 02 00 00 01 02 00 00 00 00 00 05   ... ...........
       050: 20 00 00 00 20 02 00 00 01 02 00 00 00 00 00 05   ... ...........
       060: 20 00 00 00 20 02 00 00                           ... ...
[-] #4              $VOLUME_NAME
       Attr. type:                      60h
       Attr. length:                    18h         24
       Non-resident:                     0
       Attrname len:                     0
       Attrname ofs:                    18h
       Flags:                            0h  -- --
       Attr. number:                     4
       Data Size:                        0h          0
       Data Offset:                     18h
              Volume Name:      ?
[-] #5              $VOLUME_INFORMATION
       Attr. type:                      70h
       Attr. length:                    28h         40
       Non-resident:                     0
       Attrname len:                     0
       Attrname ofs:                    18h
       Flags:                            0h  -- --
       Attr. number:                     5
       Data Size:                        Ch         12
       Data Offset:                     18h
       Hex:
       000: 00 00 00 00 00 00 00 00 03 01 00 00 00 00 00 00  ............
[-] #3              $DATA
       Attr. type:                      80h
       Attr. length:                    18h         24
       Non-resident:                     0
       Attrname len:                     0
       Attrname ofs:                    18h
       Flags:                            0h  -- --
       Attr. number:                     3
       Data Size:                        0h          0
       Data Offset:                     18h
           FFFFFFFFh End Mark

_________________
A backup a day keeps DR away.


Top
 Profile  
 
 Post subject: Re: Weird logical issue (“RAW” NTFS partition)
PostPosted: June 20th, 2018, 19:41 
Offline

Joined: December 8th, 2010, 11:37
Posts: 596
Location: Ottawa, Canada
fzabkar wrote:
If you can find it, here is another good resource:
NTFS Forensics: A Programmers View of Raw Filesystem Data Extraction (Jason Medeiros, Grayscale Research 2008).


Here's one source for it: http://citeseerx.ist.psu.edu/viewdoc/su ... 1.169.1973

_________________
Sabo Computer Repairs & Data Recovery


Top
 Profile  
 
 Post subject: Re: Weird logical issue (“RAW” NTFS partition)
PostPosted: June 21st, 2018, 4:06 
Offline

Joined: November 22nd, 2017, 21:47
Posts: 166
Location: France
Quote:
ISTM that you should take this opportunity to learn about NTFS metafiles. I could watch you and learn something as well. :-)

That's what I'm trying to do indeed...

Quote:

Wow, that one is thorough... Very good starting point.

Quote:
BTW, DMDE can display all the metadata attributes

It might be helpful to decipher the structure of a MFT record. What I want to do is the opposite, put the right hex values to the right fields, based on the informations I have. All I can recognize for sure so far are the timestamps (which are translated by WinHex when hovered over) ; also, for the $Volume file, the partition's name obviously, and what seems to be the partition's ID. I can't yet locate the field for the file size or the allocated clusters. With the precise template provided in the document you linked I may be able to find the others important fields. File size should be part of the $FILE_NAME attribute, right after the timestamps, but I find nothing there. I tried to convert the size of the MFT to hexadecimal, and search those values in MFT record #0, to no avail...
No, apparently the size information is in the pink area called “Data” in WinHex, but that doesn't correspond to what is called the “$DATA attribute” in the PDF, that's confusing... But it's there anyway : for a partition which has a MFT with a size of 625999872 bytes, in MFT record #0 there are two fields with 00 00 50 25, it's written in “little endian”, and 25500000 (hex) = 625999872 (dec).

Other things I know :
– $MFTMirr : has always a size of 4096 bytes, is apparently always located at sector 16
– $LogFile : has a size of 67108864 bytes (according to WinHex, and it's the same size on other partitions), is located at cluster 5910056 (according to WinHex with the old volume snapshot – it would have been tricky to find it otherwise)
– $Volume : is resident in the MFT
– The timestamps are the same for all system files so they can be copied from MFT record 0 ; there are two sets, one in StdInfo (colored in orange by WinHex), one in FileName (colored in blue by WinHex) ; looking at the MFT records of regular files, it appears that the actual file's timestamps are the first ones, in StdInfo, I don't know what the other set is about, apparently for most files the four timestamps are identical in that second set (perhaps they're updated each time the name itself is changed ?).
– Between two valid $MFTMirr MFT records, only the timestamps and two other bytes are different (those two bytes are identical, I don't know what they are yet, apparently it's called “fixup” in DMDE).
– Between two valid $LogFile MFT records, two other values are different, which apparently correspond to the first cluster's LBA (DE 7C 0B = B7CDE = 752862 or sector 6022896 / C5 45 0B = B45C5 = 738757 or sector 5910056 => same value as on the partition I'm trying to fix).
– Between two valid $Volume MFT records, the volume's name and ID are different, plus the “fixup” byte, and a few other bytes at the begining ; in DMDE I can see that the first field which varies is “LSNlo”, which must be “Logical Sector Number low”, for a 2TB partition it's 53 58 00 1D, or 1D005853, 486561875 in decimal, and for a 100GB partition it's 67 C1 7D 2F, or 2F7DC167, 796770663 in decimal... I can't see what to make of it... In the PDF there's no mention of “LSNlo”, but “LSN” in fact stands for “Logical Sequence Number” or “LogFile Sequence Number”. Even the document's author doesn't seem to know what this is exactly : “The purpose of the various LSNs is unclear. It appears that the data around offset 3C deal with the clear/dirty state of the volume, too.” The other varying field below seems to be the “used size”, apparently the portion of the MFT record which is actually in use.
– Regarding the volume's ID, I remember being in a situation where I cloned a drive to another with ddrescue, plugged both at the same time on Windows, and there was a conflict, I found out that it was due to the fact that both volumes had the exact same ID, and found a command to change it, don't remember the details, I must have kept some information about the procedure but can't find it in the huge mess of my main HDD... but the bottom line is : if it can be changed, it's probably not necessary to put the original one. I guess that it has to match some kind of pattern though... Perhaps I can just copy the ID from another partition and change one byte to avoid a conflict ?

That's all I could get so far... :? Tomorrow I'm gonna make a backup of the first few GB, then try to apply this with some “educated guesses” to fill the blanks, and see how it goes...


Top
 Profile  
 
 Post subject: Re: Weird logical issue (“RAW” NTFS partition)
PostPosted: June 21st, 2018, 9:42 
Offline

Joined: January 29th, 2012, 1:43
Posts: 473
Location: United States
Quote:
– Between two valid $MFTMirr MFT records, only the timestamps and two other bytes are different (those two bytes are identical, I don't know what they are yet, apparently it's called “fixup” in DMDE).

The fixup is a check to make sure the record is valid and not corrupt. The pattern is dictated in the beginning of the record, then bytes 511-512 and 1023-1024 (the last 2 bytes in each 512 byte block) should also have the matching pattern. The pattern needs to match in all three places, but otherwise is randomly generated so you can make it what you want.

_________________
http://www.sdcomputingservice.com
Home of HDDSuperClone and HDDSuperTool


Top
 Profile  
 
 Post subject: Re: Weird logical issue (“RAW” NTFS partition)
PostPosted: June 21st, 2018, 20:42 
Offline
User avatar

Joined: September 8th, 2009, 18:21
Posts: 11010
Location: Australia
This might be one important thing to check in the $Volume MFT record.

Locating the NTFS "dirty bit":
http://www.hddoracle.com/viewtopic.php?f=117&t=2126&p=14046#p14046

_________________
A backup a day keeps DR away.


Top
 Profile  
 
 Post subject: Re: Weird logical issue (“RAW” NTFS partition)
PostPosted: June 22nd, 2018, 4:14 
Offline

Joined: November 22nd, 2017, 21:47
Posts: 166
Location: France
By searching a known volume ID (from the 2TB partition shown above) in the entire system partition (C:), I found out that these IDs (or labels) were stored at least in the “xxxxxx.automaticDestinations-ms” files, in this directory :
C:\Users\[user_name]\AppData\Roaming\Microsoft\Windows\Recent\AutomaticDestinations\
I have no idea what these files are, it looks as though they keep track of the locations where files were copied or downloaded... The partition's ID/label is preceded by the name of the machine in the current Windows install, just above there's the path of a file which ended up on the corresponding volume, and the name of that volume (that one is named after the HDD's model reference and serial number, “WD20EARX WCAZAJ971138”). So, remembering that I've used that drive regularly about a year ago, and its letter was “K:”, I searched inside an “AutomaticDestinations” file with a modified date in September 2017, large enough to contain “something”, an occurrence of the string “K:”, and indeed found many, with what must be the original volume ID, and the original volume's name (which I had forgotten but now I remember) was “Stockage”.

Regarding the LSN :
“The field in the upper right at offset 0x08 labeled $Logfile Sequence Number or LSN is how the MFT refers to the most recent change recorded in the $logfile. Each $logfile record has an associated LSN, however the LSN is updated in the file record to correspond to the most recent change. There is no record that I'm aware of that shows what LSNs a file record previously had. The MFT Record Number is a unique identifier for this file record, and if we have a way to link a change to it then it becomes easy to associate historical changes we recover to indicate which MFT file record they are referencing.
The $USNJrnl keeps the MFT Record Number to indicate which file it is operating on and the Parent Record number to reflect what directory that MFT file record resided in. If a $logfile entry records a change then that change can be easily linked back to the MFT file record number's LSN if it's the last change made to that file record.”
Found this here :
http://www.hecfblog.com/2013/01/ntfs-tr ... nside.html

“This is a 48 bit number that is incremented every 16 bits when each record is added”
http://amanda.secured.org/ntfs-mft-reco ... ng-parser/

“The $MFT record carries the $LogFile sequence number (LSN) in its header, which links the $MFT record to the corresponding chain of operational records in the $LogFile.”
(Found here.)

Now I would have to delve into the $LogFile to get that value, but according to the “NTFS documentation” PDF :
“Little is known about the LogFile's structure.”
“The logrecord supposedly contains a sequence of variable sized records. The structuring of those is not clear.”
:shock:

The article linked above (hecfblog.com) gives more details, there should be a reference to the MFT cluster number in each $LogFile header – but I don't know where exactly those headers are supposed to be found, the $LogFile appears as a huge garbled mess, I can't find any occurrence of “$Volume” inside (ASCII / Unicode), I don't know where to look for at this point. It's probably not that important, but I'd prefer not to overlook anything, so if anyone has a clue...
Image


@maximus
Quote:
The fixup is a check to make sure the record is valid and not corrupt. The pattern is dictated in the beginning of the record, then bytes 511-512 and 1023-1024 (the last 2 bytes in each 512 byte block) should also have the matching pattern. The pattern needs to match in all three places, but otherwise is randomly generated so you can make it what you want.

Alright, thank you for that. Any idea about the “LSN” value ?

@fzabkar
Quote:
This might be one important thing to check in the $Volume MFT record.
Locating the NTFS "dirty bit":

What should I check exactly ? Should it be set to “dirty” or not ?
In my case the entire MFT record has been wiped, and the aim is to reconstruct it as accurately as possible... If there's an inconsistency, but the filesystem is parsable again, I'll probably get a warning and a CHKDSK analysis should fix the abnormal values. In any case it would probably be wise to run CHKDSK even if it works flawlessly at the first attempt.
I haven't written to the partition yet, but I have built an almost complete 3072 bytes file in WinHex, corresponding to the 3 missing MFT records.


Top
 Profile  
 
 Post subject: Re: Weird logical issue (“RAW” NTFS partition)
PostPosted: June 22nd, 2018, 10:59 
Offline

Joined: January 29th, 2012, 1:43
Posts: 473
Location: United States
As far as the LSN value, I would say set it to zero if you can't figure out what it should be. Maybe that is something that chkdisk can fix. I don't have any idea about the LOG file, nor do I (and probably everybody else on here) have much interest in it, as it is not important for data recovery :)

EDIT: I should say that is not important to data recovery, unless you are using CHKDISK to, uh, "recover" the data :)

_________________
http://www.sdcomputingservice.com
Home of HDDSuperClone and HDDSuperTool


Top
 Profile  
 
 Post subject: Re: Weird logical issue (“RAW” NTFS partition)
PostPosted: June 22nd, 2018, 16:42 
Offline
User avatar

Joined: September 8th, 2009, 18:21
Posts: 11010
Location: Australia
abolibibelot wrote:
@fzabkar
Quote:
This might be one important thing to check in the $Volume MFT record.
Locating the NTFS "dirty bit":

What should I check exactly ? Should it be set to “dirty” or not ?
In my case the entire MFT record has been wiped, and the aim is to reconstruct it as accurately as possible... If there's an inconsistency, but the filesystem is parsable again, I'll probably get a warning and a CHKDSK analysis should fix the abnormal values. In any case it would probably be wise to run CHKDSK even if it works flawlessly at the first attempt.
I haven't written to the partition yet, but I have built an almost complete 3072 bytes file in WinHex, corresponding to the 3 missing MFT records.

I was thinking that you wouldn't want Windows to automatically launch CHKDSK. That's what happens when the dirty bit is set. It occurred to me that patching the patient FS with an MFT record from a donor might inadvertently set this bit, especially as it does not seem to be a well known parameter.

_________________
A backup a day keeps DR away.


Top
 Profile  
 
 Post subject: Re: Weird logical issue (“RAW” NTFS partition)
PostPosted: June 22nd, 2018, 18:35 
Offline

Joined: November 22nd, 2017, 21:47
Posts: 166
Location: France
Quote:
As far as the LSN value, I would say set it to zero if you can't figure out what it should be. Maybe that is something that chkdisk can fix. I don't have any idea about the LOG file, nor do I (and probably everybody else on here) have much interest in it, as it is not important for data recovery :)

Alright then, if noone here has any clue, that's about the best I can do ! :)
But what I discovered is : looking at the MFT record of a file created recently on a valid partition, I copied the LSN value (hex, little endian), searched that value inside the $LogFile of that partition, and there it is. Since the $LogFile is only 64MB in size, it does not retain all information :
“When the log file fills up, the records at the beginning are purged (by modifying the oldest_lsn to a higher value presumably) and writing begins at the beginning of the file. Effectively, the log file is viewed as a circular entity.” (from “NTFS documentation” PDF linked by fzabkar 20180620 23:25)
“Both the $logfile and the $usnjrnl are circular with a max size, so there is a finite amount of data each will keep before it begins to overwrite themselves.” (article linked above)
So whatever the log value for $Volume was, it's irrelevant now since the corresponding record has most likely been “purged” a long time ago.

Quote:
I should say that is not important to data recovery, unless you are using CHKDISK to, uh, "recover" the data :)

I've already made a full recovery for safety (and it's a recovery of a recovery actually as I said earlier). But still, knowing that sort of stuff (how NTFS metafiles are structured and organized) could be a significant time saver in a situation like this. Suppose you (you being : a professional data recovery technician) receive a drive in this exact state, with one partition which is no longer accessible and no help from CHKDSK or TestDisk, discover as I did that this is due to only 3 missing MFT records, why go through the hassle of extracting the whole contents, re-formatting, re-transfering everything, if it can be effectively fixed by copying those sectors from a valid partition and changing a few key values ? Or maybe professional softwares can deal with this kind of issues automatically ?

Apparently the $LogFile is of great value for forensic purposes, but I understand that this is not the primary focus on this forum.

***

So I did it, I applied my “patch” : CHKDSK worked right away, but (launched at first without the /F switch so in read-only) reported errors in index $O of file 25 (file 25 being $ObjId), and an error in the record for file 3 (file 3 being $Volume). Then, I tried to parse $ObjId/$O, hoping to find the correct value, to no avail. I did find 3 or 4 variations of the first value I had found in “faef7def55a1d4b.automaticDestinations-ms”, which I tried one by one, but CHKDSK gave the same output. Then I realized that there were a gazillion of variations of that very value in “faef7def55a1d4b.automaticDestinations-ms”, differing by the first two characters, so that couldn't be the actual ID. Then, I don't know why, I had the idea of looking inside System Volume Information : on a valid partition, I opened “tracking.log”, and right at the begining there's the name of the machine on that system, followed by the 16 characters ID found in $Volume. So I copied the value from “tracking.log” on the corrupted partition, pasted it into $Volume (in both $MFT and $MFTMirr), launched CHKDSK again... no error this time ! The partition was still not accessible, probably because it had to be properly re-mounted. I launched CHKDSK with the /F switch (which requires to unmount the volume), it found no error as before, and then the partition became accessible again. Ouf ! :)

Attachment:
ST2000DM001-1ER164 CHKDSK 20180622 1.png
ST2000DM001-1ER164 CHKDSK 20180622 1.png [ 19.28 KiB | Viewed 1074 times ]

(The first command was executed before the patching : CHKDSK couldn't identify the state and version of the volume and aborted.)
Attachment:
ST2000DM001-1ER164 CHKDSK 20180622 2.png
ST2000DM001-1ER164 CHKDSK 20180622 2.png [ 20.36 KiB | Viewed 1074 times ]

(I renamed the volume “Stoc” instead of “Stockage” as it was called before, so as to have the same number of characters as in the $Volume MFT record from another partition named “TEMP”, to stay on the safe side and avoid an error due to some unexpected offset, and to be sure that the “used size” value would match, since I don't fully understand the structure of the record.)

***

Now, does anybody else – aside from “Spildit” – think that this drive could still have a “silent” hardware issue, despite the fact that the S.M.A.R.T. status shows currently no worrying value ? I know now that this range of drive has a bad reputation, but can I still trust this particular unit, for now ?
Attachment:
ST2000DM001 Z4Z0T7LY HD Sentinel SMART Ultra ATA CRC Error Count.png
ST2000DM001 Z4Z0T7LY HD Sentinel SMART Ultra ATA CRC Error Count.png [ 157.71 KiB | Viewed 1074 times ]

My main HDD is a ST2000DX001... it's not that I like to live dangerously, but when I bought those two I had no idea that Seagate drives had acquired such a bad reputation lately ! It's got a pristine S.M.A.R.T. status currently. I've had another ST2000DM001, purchased used, which I used three years before it started to misbehave – that's when I cloned it onto the ST2000DX001. Reliability aside, what I like about those drives is that they're excellent performers (max reading rate above 200MB/s) while being relatively silent for 7200rpm models.


Top
 Profile  
 
 Post subject: Re: Weird logical issue (“RAW” NTFS partition)
PostPosted: June 22nd, 2018, 18:52 
Offline
User avatar

Joined: December 19th, 2006, 8:49
Posts: 9981
Location: Portugal
abolibibelot wrote:
Now, does anybody else – aside from “Spildit” – think that this drive could still have a “silent” hardware issue, despite the fact that the S.M.A.R.T. status shows currently no worrying value ? I know now that this range of drive has a bad reputation, but can I still trust this particular unit, for now ?


viewtopic.php?f=1&t=36995

:D

_________________
1Q9xrDTzTddUXeJAFRn37aqh1Yr6buDCdw - (Bitcoin Donations)
paypal.me/Spildit - (PayPal Donations)
The HDD Oracle - Platform for OPEN research on Data Recovery.


Top
 Profile  
 
 Post subject: Re: Weird logical issue (“RAW” NTFS partition)
PostPosted: June 22nd, 2018, 19:18 
Offline

Joined: October 16th, 2013, 13:21
Posts: 717
Location: Brazil
I agree with the others in that you should fully erase/reformat this drive a couple times to see if any bad sector arises, then trash the drive.


Top
 Profile  
 
 Post subject: Re: Weird logical issue (“RAW” NTFS partition)
PostPosted: June 22nd, 2018, 19:34 
Offline
User avatar

Joined: December 19th, 2006, 8:49
Posts: 9981
Location: Portugal
maximus wrote:
EDIT: I should say that is not important to data recovery, unless you are using CHKDISK to, uh, "recover" the data :)


:row:

Don't do it. Period.

_________________
1Q9xrDTzTddUXeJAFRn37aqh1Yr6buDCdw - (Bitcoin Donations)
paypal.me/Spildit - (PayPal Donations)
The HDD Oracle - Platform for OPEN research on Data Recovery.


Top
 Profile  
 
 Post subject: Re: Weird logical issue (“RAW” NTFS partition)
PostPosted: June 22nd, 2018, 19:39 
Offline
User avatar

Joined: September 8th, 2009, 18:21
Posts: 11010
Location: Australia
@abolibibelot, congratulations ... I think. :-)

_________________
A backup a day keeps DR away.


Top
 Profile  
 
 Post subject: Re: Weird logical issue (“RAW” NTFS partition)
PostPosted: June 22nd, 2018, 20:06 
Offline

Joined: November 22nd, 2017, 21:47
Posts: 166
Location: France
Quote:
viewtopic.php?f=1&t=36995

Well, you could show rocky horror pictures from any brand / model of drive, couldn't you ? In this particular case nothing is said about the conditions in which the drives were used, perhaps they sustained vibrations or shocks way beyond their specifications... or perhaps not, but pictures are not enough to tell the whole story. It's a bit like showing a chest radiography from a russian guy who was born in Tchernobyl in 1986, smokes like a mofo since the age of 12 and works in an asbestos disposal facility, and saying, see, russians have bad lungs ! :)
I'm willing to trust the near unanimous opinion expressed on this forum that these drives have an inferior design, are made with lesser quality materials, and are generally less reliable statistically than their counterparts from other brands (although it's not very clear which ones – only HGST seems to have a stellar reputation here, but I've seen one fail badly, and as far as I know way fewer units are sold worldwide compared to the two giants Seagate and WD), but some statements about Seagate are clearly blown out of proportion. Caricature can be funny for a while but it doesn't help in approaching the truth. If all Seagate drives were so bad and utterly unreliable, the company would face a huge worldwide backlash and would soon disappear, if all this is true, if they haven't produced a drive in 10 years that lasted 6 months, how can it be explained that the company is still a major player in this field ?

@rogfanther
Quote:
I agree with the others in that you should fully erase/reformat this drive a couple times to see if any bad sector arises, then trash the drive.

You mean, trash it even if no bad sector arises ? :shock: Or only if that were to happen ? Do you recommand this because this is a Seagate “DM” drive, because there was this (apparently strictly logical) issue, or both ?

@fzabkar
Quote:
@abolibibelot, congratulations ... I think. :-)

Thanks! :)
(I'm quite proud indeed since the assistance was rather scarce... I can't say that I fully understand the structure of those metafiles yet, it's frighteningly complex, but that's quite encouraging. And I have the feeling that even among data recovery experts, many would have considered this a lost cause, or at least “not worth the trouble”.)


Top
 Profile  
 
 Post subject: Re: Weird logical issue (“RAW” NTFS partition)
PostPosted: June 22nd, 2018, 20:20 
Offline

Joined: October 16th, 2013, 13:21
Posts: 717
Location: Brazil
I recommend to test, a couple times, with the long test option from the seagate test tool, or some complete erase/writes/test with mhdd or victoria.

If after all of that the disk passes with an "ok" from the tool, then I would say you can use it, with your *own* data in it, and that it would be better to not store valuable data in it.


Top
 Profile  
 
 Post subject: Re: Weird logical issue (“RAW” NTFS partition)
PostPosted: June 22nd, 2018, 20:36 
Offline
User avatar

Joined: December 19th, 2006, 8:49
Posts: 9981
Location: Portugal
abolibibelot wrote:
(...)And I have the feeling that even among data recovery experts, many would have considered this a lost cause, or at least “not worth the trouble”.)


No they wouldn't.

They would simple hook up the drive to something like PC-3000 DE or even use simple methods like open the drive with R-Studio and directly extract the data.

Yes, nobody would bother to fix the partition by hand because it's a time waste and no-one in it's right mind would even "consider" to re-use that drive even more "gamble" with that chkdsk !

You were very lucky so far and that's it.

_________________
1Q9xrDTzTddUXeJAFRn37aqh1Yr6buDCdw - (Bitcoin Donations)
paypal.me/Spildit - (PayPal Donations)
The HDD Oracle - Platform for OPEN research on Data Recovery.


Top
 Profile  
 
 Post subject: Re: Weird logical issue (“RAW” NTFS partition)
PostPosted: June 22nd, 2018, 20:46 
Offline

Joined: October 16th, 2013, 13:21
Posts: 717
Location: Brazil
[quote="abolibibelot" And I have the feeling that even among data recovery experts, many would have considered this a lost cause, or at least “not worth the trouble”.)[/quote]


Thats because they are experts, and they work in data recovery. The job is recovering the data. The most trusted way would be to just extract with R-Studio, for example. Why mess with direct editing of the partitions when not necessary , and possibly making another customer wait ?


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 60 posts ]  Go to page Previous  1, 2, 3  Next

All times are UTC - 5 hours [ DST ]


Who is online

Users browsing this forum: No registered users and 20 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:  
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group