Hi again,
Johannes Bauer wrote:
> Hi Jean-Pierre,
>
> On 24.09.2013 16:15, Jean-Pierre André wrote:
>
>
>>> Do and of you have a clue what could be happening here and how to fix it?
>>>
>> This all shows that you cannot access files whose inode
>> number is greater or equal 58368. Instead of the expected
>> magic number there is a random (or encrypted) value. I see
>> that TrueCrypt is inode 58065, which tends to mean you have
>> encrypted files which were created since May 25th keeping
>> former files unencrypted.
>>
> I agree with you that instead of the magic value it finds some garbage,
> but I cannot imagine how it could be encrypted: I use full-disk
> encryption and try to mount the *decrypted* device-mapper device
> (/dev/mapper/truecrypt1), i.e. this is a 1:1 mapping of the original
> block-device with all content already decrypted. So ntfs3g actually
> doesn't even know that it's an encypted device
>
[...]
> Dumping attribute $DATA (0x80) from mft record 0 (0x0)
> Attribute length: 80 (0x50)
> Resident: No
> Name length: 0 (0x0)
> Name offset: 64 (0x40)
> Attribute flags: 0x0000
> Attribute instance: 1 (0x1)
> Lowest VCN 0 (0x0)
> Highest VCN: 51583 (0xc97f)
> Mapping pairs offset: 64 (0x40)
> Compression unit: 0 (0x0)
> Data size: 211288064 (0xc980000)
> Allocated size: 211288064 (0xc980000)
> Initialized size: 211288064 (0xc980000)
> Runlist: VCN LCN Length
> 0x0 0xc0000 0x3900
> 0x3900 0x479d20a 0x9080
>
This is interesting. There are four inodes per cluster,
so inode 58368 is in relative cluster 58368/4 = 14592
= 0x3900.
The MFT has two fragments, and the decryption (or
whatever) problem lies exactly in the second fragment.
The LCN is reasonable (it is less than the cluster count)
and the length is correct (as shown by the data size).
The problem now is to find out why cluster 0x479d20a
(describing inode 58368) is not correctly decrypted.
You may first confirm this by :
dd if=/dev/mapper/trycrypt1 bs=4096 skip=75092490 \
count=1 | head -c 4
which should return "FILE", but will probably return
some unprintable chars.
>> I would also like to know the physical sector size.
>>
> That's 512 bytes.
>
> All partitions are (at least) 4096-byte aligned, however (don't know if
> that matters or not).
>
It does not matter for ntfs-3g for a 512-byte sector disk
(no idea for TrueCrypt).
>
>> It would also be useful to know the history of this
>> partition :
>>
>> - how was it formatted ? (Bastille Day 2009 tends to
>> mean Windows 7)
>>
> Yes, Windows 7 professional, the disk was formatted during the
> installation phase.
>
>
>> - how was it encrypted ? (can it be partially encrypted) ?
>>
> It is encrypted using full-disk-encryption, i.e. the complete system
> (including all partitions on that device) are encrypted.
>
>
>> - are you using the same TrueCrypt version and the
>> same key on Window and Linux ?
>>
> Yes, 7.1a.
>
If the full disk was encrypted, and you can read it
partially, I assume the encryption key is correct.
However when customizing the encryption, did you
have to enter the disk size ?
>> - what is "the installation of the OS" ? (reinstallation
>> of Windows ? of Linux ?)
>>
> I meant the installation of the Windows OS on that disk. Everything in
> the "early" age of the disk appears to be fine, while (as you also
> noted) everything in the later age of the disk is not readable by ntfs3g.
>
Actually, what I wanted to know is the sequencing
of events (formatting, encrypting, installing Windows,
installing Linux). I would like to know why the
TrueCrypt directory is just near the encryption issue,
I do not find this consistent with a full disk encryption
earlier than Windows installation.
> Most curiously to me is that all content access works perfectly from
> within Windows and the Windows chkdsk program doesn't find any errors on
> the disk.
I have no explanation so far. To understand why
Windows and Linux do not get the same data, maybe
you can download a Windows version of ntfsinfo from
http://jp-andre.pagesperso-orange.fr/advanced-ntfs-3g.html#download
and compare the outputs of
ntfsinfo -fvi 0 /dev/mapper/truecrypt1
and
ntfsinfo -fvi 58368 /dev/mapper/truecrypt1
(this one will fail...)
Do both same command on Windows, with a drive letter
designating the encrypted partition.
ntfsinfo -fvi 0 X:
ntfsinfo -fvi 58368 X:
If this succeeds, the issue does not lie in ntfs-3g...
Regards
Jean-Pierre
------------------------------------------------------------------------------
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk
_______________________________________________
ntfs-3g-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/ntfs-3g-devel
