Adam Brenner wrote: > On 02/12/2017 11:22 PM, Jean-Pierre André wrote: > >> Hi, >> >> Jean-Pierre André wrote: >>> Adam Brenner wrote: >>>> Hello, >>>> >>>> I am trying to understand what a value of -2 means for aLCN. Does >>>> anyone >>>> know? >>>> >>>> For example: I see the following when I run ntfscluster: >>>> >>>> ./ntfscluster -f -I 0 /dev/sdc1 >>>> Dump: /$MFT >>>> 0x10 - resident >>>> 0x20 - resident >>>> 0x30 - resident >>>> 0x80 - non-resident >> >> As you were pinpointed the value -2, I did not notice >> this "non-resident" state yesterday. >> >> The first thing to do is to backup the raw partition, >> as partition checkers might get into trouble and delete >> useful information. >> >> Were you doing something special the last time you mounted >> the partition successfully ? >> > Jean-Pierre: thank you very much for all the information. > > It does not appear anything is wrong with the NTFS partition at all. The > filesystem is filled with 10+ million, 5KiB files (its all data from > /dev/zero). ntfs-3g and Windows are able to correctly read the contents > of the MFT and mount the partition. > > I am trying to resolve a bug in another open source tool, p7zip, as it > does not correctly understand this use case. For reference: > https://sourceforge.net/p/p7zip/bugs/193/ > > The p7zip code does _not_ include ntfs-3g, it has its own > implementation. It was helpful to get an understanding of why ntfs-3g > correctly handles the -2 LCN so we can fix it in p7zip. > >> I suggest you post the contents of the boot sector and >> the beginning of the mft : >> >> dd if=/dev/PARTITION bs=512 count=1 | gz > boot.gz >> dd if=/dev/PARTITION bs=4096 skip=786432 count=16 | gz > mft.gz > > Do you suspect that $MFT (and even $MFTMirror) are in a bad state?
I was suspecting that the location defined for the beginning (786432) might not be the record itself, as defined in the boot sector... Please forget about it if you can read it. Jean-Pierre > I know that 0x80 is supposed to be the data section of any inode/record > number within NTFS. For record number 0, $MFT, the data section should > just be the offsets on disk where the rest of the metadata/records for > the filesystem exist. My understanding is that it should be small enough > so it all fits within the record it self, resident. > > However, due to the number of records on disk, it could not fit > everything into the resident structure; hence the two data sections. I > am assuming that is what is happening. > > -Adam > >> >> Regards >> >> Jean-Pierre >> >>>> VCN LCN Length >>>> 0 786432 4 >>>> 4 -2 3882300 >>>> 0x80 - non-resident >>>> VCN LCN Length >>>> 0 -2 4 >>>> 4 786436 90684 >>>> 90688 877270 51210 >>>> 141898 1359523 51229 >>>> 193127 1841856 51200 >>>> 244327 2324736 51200 >>>> ... continues ... >>>> >>>> >>>> The NTFS filesystem was created on Windows (Server 2008 R2) and mounted >>>> on linux using ntfs-3g. May someone please explain to this situation to >>>> me? I could not find any documentation that explains this further. >>>> >>>> Quickly looking at the source code, some comments mention that -2 is >>>> mapped to LCN_RL_NOT_MAPPED and the runlist is not yet defined? >>> >>> The value -2 means just that : it means there is no >>> location defined there for the described range. >>> >>> In your case the mapping list had to be split across >>> two records (because the full list is too big for a >>> single record). >>> >>> In the first record, the location of the first four >>> clusters are defined (cluster 786432 and next three), >>> but the location of the next 3882300 clusters are not >>> defined (at least not defined there), which is >>> indicated by the value -2. >>> >>> In the second record, the location of the first four >>> clusters are not defined (as shown by the value -2), >>> but the location of the next clusters are defined. >>> >>> When you consider both records, all locations are >>> defined exactly once. This is the normal situation. >>> >>> Note 1 : this is the MFT, the entry to the file system >>> which tells where each file, including itself, is >>> located. So for the second record to be accessed, >>> its location must be defined in the first record. >>> As the first record only defines four clusters, one >>> of these four clusters must contain the second >>> record. >>> >>> Note 2 : the LCN_RL_NOT_MAPPED is also used to mark >>> a hole in a sparse file or in a compressed file >>> >>> Regards >>> >>> Jean-Pierre >>> >>>> >>>> Any explanation on this situation and how to properly handle this case >>>> would be very helpful. >>>> >>>> Thanks, >>>> -Adam >>> >> >> > > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, SlashDot.org! http://sdm.link/slashdot > ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot _______________________________________________ ntfs-3g-devel mailing list ntfs-3g-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ntfs-3g-devel
