Today, I was asked to rescue some lost photos on an NTFS partition. The info I got was that "some files could not be opened anymore" on that disk.
I mounted it read-only on my Linux machine and got a very strange error while trying to access one of the problematic files:
I checked the access rights and they were "rwxrwx--- for myuser:mygroup", so it should have been fine.cp: cannot open `IMG_0123.JPG' for reading: Permission denied
There were not many search results on that errormessage on the web, but it seems that I am not alone:
http://www.linuxquestions.org/questions ... re-462318/
However, they were wrong (at least in my case). Although it was also about fotos from a Canon camera (coincidence??), my files were inaccessible because they were on in EFS encrypted NTFS folders. I found that source proving my assumption:
http://osdir.com/ml/linux.file-systems. ... 00050.html
It says:
What is a problem is that when the
NTFS driver tries to copy encrypted files, it gives the error:
"cp: reading `filename.txt`: Permission denied"
and proceeds to copy all the files, but the destination files all
have a filesize of zero.
[SOLUTION]
There is probably *no* solution unless you have access to the files of the windows' user-profile that was used for encrypting these files.
However, to ensure that I was really dealing with encrypted files, I've used "ntfsinfo':
Code: Select all
ntfsinfo -d /dev/sda1 -f -i 1234
(You can find the inode for a file by doing a "ls -i filename")
The encrypted files mentioned that in their file attributes:
whereas regular files had these file attributes:Last Accessed Time: Sat Dec 30 15:58:51 2006
File attributes: ARCHIVE TEMPORARY ENCRYPTED
Max Number of Versions: 0
*sigh*Last Accessed Time: Sun Dec 23 20:54:09 2007
File attributes: ARCHIVE TEMPORARY
Max Number of Versions: 0

(full dump of encrypted file):
Code: Select all
Dumping Inode #4298
Update Sequence Array Count: 3
$LogFile seqNum for this Inode: 0x3103db85
Number of times reused: 1
Number of hard links: 1
MFT record Flags:
Size - Used: 704 bytes
Size - Allocated: 1024 bytes
Next Attribute Instance Num 9
Dumping attribute $STANDARD_INFORMATION (0x10)
Attribute instance: 0
File Creation Time: Sat Dec 30 15:58:51 2006
File Altered Time: Sun Oct 29 16:10:18 2006
MFT Changed Time: Thu Dec 13 15:47:49 2007
Last Accessed Time: Sat Dec 30 15:58:51 2006
File attributes: ARCHIVE TEMPORARY ENCRYPTED
Max Number of Versions: 0
Version Number: 0
Class ID: 0
User ID: 0
Security ID: 298
Dumping attribute $FILE_NAME (0x30)
File Name: 'IMG_0001.JPG'
File Name Length: 12
Namespace: Win32 & DOS
Attribute instance: 2
Allocated File Size: 0
Real File Size: 0
Parent directory: 4297
File attributes: ARCHIVE TEMPORARY
File Creation Time: Sat Dec 30 15:58:51 2006
File Altered Time: Sat Dec 30 15:58:51 2006
MFT Changed Time: Sat Dec 30 15:58:51 2006
Last Accessed Time: Sat Dec 30 15:58:51 2006
Dumping attribute $DATA (0x80) related info
Stream name: unnamed
Attribute instance: 3
Flags: 0x4000
Is resident? No
Data size: 406256
Allocated size: 409600
Initialized size: 406256
Not Compressed
Dumping attribute $DATA (0x80) related info
Stream name: 'Q30lsldxJoudresxAaaqpcawXc'
Attribute instance: 6
Flags: 0x4000
Is resident? No
Data size: 5024
Allocated size: 8192
Initialized size: 5024
Not Compressed
Dumping attribute $DATA (0x80) related info
Stream name: '{4c8cc155-6c1e-11d1-8e41-00c04fb9386d}'
Attribute instance: 8
Flags: 0x4000
Is resident? No
Data size: 0
Allocated size: 0
Initialized size: 0
Not Compressed
Dumping attribute $LOGGED_UTILITY_STREAM (0x100)
TODO
End of inode reached
Linux is powerful, but so far I'm probably out of luck.