Hi,

I am using ntfs-3g-2009.4.4AR.1.tgz version and trying to copy the NTFS attribute (specifically the encrypted attribute) from one file to another.

I have a Drafts file which produces the following output:


I have another file Drafts in a different directory which shows the following:

To copy over the attribute I do the following:

What is it that I am doing wrong? Is it possible to copy over the encrypted flag?

There is a reason I am doing this. I accidentally deleted some files on my NTFS partition and an undelete program did manage to recover them but is unable to restore it with encrypted flag set. So, I have the file in encrypted form but showing it as unecrypted and that is causing all the problems. If I can somehow set the encrypted flag and trick NTFS to recognize it as encrypted, then it will probably decrypt it and solve my problem. I am not sure if that will work, but that is the best shot I have at this stage!

thanx,
--rohit.

Hi,


Forced setting the encrypted flag is not possible with good reasons : an encrypted file is composed of a data stream (the encrypted file contents) and another stream which contains the encryption key encrypted for all users allowed to access the stream. Setting the encrypted flag without defining the decryption stream is meaningless.

Did you recover the encryption information ? To determine this, you can :
a) determine the inode number by "ls -li the-file"
b) unmount the volume
c) dump the inode structure by "ntfsinfo -vi the-inode partition"
d) check whether the inode contains an attribute "$LOGGED_UTILITY_STREAM"
If you do not have this, you will not be able to interpret the file.

Now, if you have it, check the thread viewtopic.php?f=2&t=1084 for availability of an extension made by mabene aiming at saving and restoring an encrypted file. Adaptations will be needed for your situation though.

Regards

Jean-Pierre

The file has been recovered in full. I followed the earlier post and that is how I got here. I have the certificate to decrypt the file. And I believe that apart from that all other required data is written to the file, which I am assuming has been recovered properly.

When my undelete program is done it creates the file Draft whose Inode does not have the $LOGGED_UTILITY_STREAM entry. If I then encrypt this file (double encryption?) then the entry appears and is the identical for all other files that are under EFS - possibly coz' my certificate has not changed. So if the data is recovered completely then I will need to set the 'encrypted' flag and also add this entry to the Inode - right? Doing one would not automatically do the other part I suppose?

For all my encrypted files, the entry appears as follows:


thanx,
--rohit.

Hi,


Not clear to me from what you say.

Very bad. Each file has its own random encryption key. The missing stream contains the original encryption key, encrypted with public keys of all people allowed to get the encryption key and decrypt the file. The encryption key is random because each file has its own set of allowed readers.

So you have double encrypted the file with a new random encryption key, and with your private key you can get it from the new LOGGED_UTILITY_STREAM and make your file single encrypted. This is probably not what you wanted.

You have to get the LOGGED_UTILITY_STREAM which was associated to your original file.

Regards

Jean-Pierre

Hi,



If that is the case then I should pretty much forget about recovering anything. However, when I do go back and look at the inodes of other encrypted files, I realize that they all have pretty much the same inode entries:


Where is the encrypted encryption key stored in this stream? I guess this dump does not actually print that. I believe that this program never recovered this inode entry so I have pretty much no hope :-(.


The double encryption was just a try. I read somewhere that double encryption is not possible so I thought maybe the system intelligently recognized something, but I guess it does not. And if the random encryption key is missing then there is no hope.

Your other post had said:

This gave me the hope that all the data is in the file itself and if the file is recovered, everything is recovered and since I have the certificate so I am all set. I guess that is not the case then.

BTW I tried the patch from your other post but I guess that also does not restore the EFS flag.

thanx,
--rohit.

Hi,


You have a similar header, but the actual data (568 bytes in your example) must be different. You should be able to dump it with option -v in ntfsinfo.

It just recognizes the presence of LOGGED_UTILITY_STREAM...

That was what I thought after a wrong interpretation of a diagram in MSDN, but I was proved wrong.

It should not.

Your best chance is to find a smarter undelete... not an easy job from my point of view.

Regards

Jean-Pierre

Hi,



I did find it, but by then the disk had done some activity and recovery was not possible for more than 70% of the files, as it must have overwritten the sectors. This program had saved an image - and I believe it did not store the LOGGED_UTILITY_STREAM parts, so about 1 month of my emails is gone now! This is a first for me, as I am very good at backing up but I just pressed one wrong click :-(

Anyway thanks a ton for your help, I did learn a lot while doing this. And ntfs-3g is terrific!! Great job!!

thanx,
--rohit.

Hi,

You could try

to find and locate your emails the place(s) on the disk. It's very possible that they are still in contiguous bigger blocks on your disk. A disk editor could help too. (Sorry, I have no recommendation).

Regards, Szaka