I’m developing a backup application which performs copying of all occupied clusters (using FSCTL_GET_VOLUME_BITMAP & FSCTL_GET_RETRIEVAL_POINTERS). The volume (NTFS) I’m testing this on is not used, i.e. nobody has opened files and nobody modifies it during the test backup. However after restoration I can’t enter some directoreis and “chkdsk” says that I30 attribute is corrupted but succeeds to repair it.
The information I found regarding this I30 attribute says that this is an index reference between files an folders.
Can someone shed some light on this? Does this I30 attribute contain any volume-specific information and gets corrupted when volume GUID changes? Can this be something with journaling on NTFS volumes? Can I rebuild these indices somehow wihtout calling to “chkdsk”?
I tried to call FSCTL_GET_RETRIEVAL_POINTERS on a folder with appending “:$i30:$INDEX_ALLOCATION” to its name. The call succeeds but the result is the same as I would call it without this postfix.
$I30 is the body of the NTFS’s directory.
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
----- Original Message -----
From: Roman Kudinov
Newsgroups: ntfsd
To: Windows File Systems Devs Interest List
Sent: Tuesday, December 07, 2004 10:08 AM
Subject: [ntfsd] $I30 attribute
I’m developing a backup application which performs copying of all occupied clusters (using FSCTL_GET_VOLUME_BITMAP & FSCTL_GET_RETRIEVAL_POINTERS). The volume (NTFS) I’m testing this on is not used, i.e. nobody has opened files and nobody modifies it during the test backup. However after restoration I can’t enter some directoreis and “chkdsk” says that I30 attribute is corrupted but succeeds to repair it.
The information I found regarding this I30 attribute says that this is an index reference between files an folders.
Can someone shed some light on this? Does this I30 attribute contain any volume-specific information and gets corrupted when volume GUID changes? Can this be something with journaling on NTFS volumes? Can I rebuild these indices somehow wihtout calling to “chkdsk”?
I tried to call FSCTL_GET_RETRIEVAL_POINTERS on a folder with appending “:$i30:$INDEX_ALLOCATION” to its name. The call succeeds but the result is the same as I would call it without this postfix.
Questions? First check the IFS FAQ at https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com
Sorry, that was my bug again. I wasn’t restoring folder related clusters
“Roman Kudinov” wrote in message news:xxxxx@ntfsd…
I’m developing a backup application which performs copying of all occupied clusters (using FSCTL_GET_VOLUME_BITMAP & FSCTL_GET_RETRIEVAL_POINTERS). The volume (NTFS) I’m testing this on is not used, i.e. nobody has opened files and nobody modifies it during the test backup. However after restoration I can’t enter some directoreis and “chkdsk” says that I30 attribute is corrupted but succeeds to repair it.
The information I found regarding this I30 attribute says that this is an index reference between files an folders.
Can someone shed some light on this? Does this I30 attribute contain any volume-specific information and gets corrupted when volume GUID changes? Can this be something with journaling on NTFS volumes? Can I rebuild these indices somehow wihtout calling to “chkdsk”?
I tried to call FSCTL_GET_RETRIEVAL_POINTERS on a folder with appending “:$i30:$INDEX_ALLOCATION” to its name. The call succeeds but the result is the same as I would call it without this postfix.