Thread: [sleuthkit-developers] [ sleuthkit-Bugs-3088447 ] NTFS error about adding attribute sequence
Brought to you by:
carrier
Menu
▾
▴
sleuthkit-developers
|
From: SourceForge.net <no...@so...> - 2010-10-16 00:31:35
|
Bugs item #3088447, was opened at 2010-10-15 19:31 Message generated for change (Tracker Item Submitted) made by carrier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3088447&group_id=55685 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: File System Tools Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Brian Carrier (carrier) Assigned to: Brian Carrier (carrier) Summary: NTFS error about adding attribute sequence Initial Comment: Adam Dershowitz reported: General file system error (fs_attr_add_run: error adding additional run (9): No filler entry for 0. Final 176) ( - proc_attrseq: put run- proc_attrlist) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3088447&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2010-10-19 04:01:45
|
Bugs item #3088447, was opened at 2010-10-15 19:31 Message generated for change (Comment added) made by carrier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3088447&group_id=55685 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: File System Tools Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Brian Carrier (carrier) Assigned to: Brian Carrier (carrier) Summary: NTFS error about adding attribute sequence Initial Comment: Adam Dershowitz reported: General file system error (fs_attr_add_run: error adding additional run (9): No filler entry for 0. Final 176) ( - proc_attrseq: put run- proc_attrlist) ---------------------------------------------------------------------- >Comment By: Brian Carrier (carrier) Date: 2010-10-18 23:01 Message: Issue seems to be because the $Secure file is VERY fragmented and has lots of attrlists. There are two NTFS_ATYPE_IDXALLOC attributes and they both have an ID of 0 in the attrlist entries. So, we get a collision when the second one is added to the runs of the first one (because they have the same type and id). Sent a request to get MFT entry 9 to see if there is ID info that we are dropping.... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3088447&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2010-10-20 03:49:52
|
Bugs item #3088447, was opened at 2010-10-15 19:31 Message generated for change (Comment added) made by carrier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3088447&group_id=55685 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: File System Tools Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Brian Carrier (carrier) Assigned to: Brian Carrier (carrier) Summary: NTFS error about adding attribute sequence Initial Comment: Adam Dershowitz reported: General file system error (fs_attr_add_run: error adding additional run (9): No filler entry for 0. Final 176) ( - proc_attrseq: put run- proc_attrlist) ---------------------------------------------------------------------- >Comment By: Brian Carrier (carrier) Date: 2010-10-19 22:49 Message: The base MFT entry didn't have any details about the IDX_ALLOC entries. Requested the ATTRLIST block for more details to see if the id is in there. The verbose log shows that all entries in ATTRLIST have an ID of 0. ---------------------------------------------------------------------- Comment By: Brian Carrier (carrier) Date: 2010-10-18 23:01 Message: Issue seems to be because the $Secure file is VERY fragmented and has lots of attrlists. There are two NTFS_ATYPE_IDXALLOC attributes and they both have an ID of 0 in the attrlist entries. So, we get a collision when the second one is added to the runs of the first one (because they have the same type and id). Sent a request to get MFT entry 9 to see if there is ID info that we are dropping.... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3088447&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2010-10-21 02:55:46
|
Bugs item #3088447, was opened at 2010-10-15 19:31 Message generated for change (Comment added) made by carrier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3088447&group_id=55685 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: File System Tools Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Brian Carrier (carrier) Assigned to: Brian Carrier (carrier) Summary: NTFS error about adding attribute sequence Initial Comment: Adam Dershowitz reported: General file system error (fs_attr_add_run: error adding additional run (9): No filler entry for 0. Final 176) ( - proc_attrseq: put run- proc_attrlist) ---------------------------------------------------------------------- >Comment By: Brian Carrier (carrier) Date: 2010-10-20 21:55 Message: Note that Stefan Kelm reported this same error back in Sept. ---------------------------------------------------------------------- Comment By: Brian Carrier (carrier) Date: 2010-10-19 22:49 Message: The base MFT entry didn't have any details about the IDX_ALLOC entries. Requested the ATTRLIST block for more details to see if the id is in there. The verbose log shows that all entries in ATTRLIST have an ID of 0. ---------------------------------------------------------------------- Comment By: Brian Carrier (carrier) Date: 2010-10-18 23:01 Message: Issue seems to be because the $Secure file is VERY fragmented and has lots of attrlists. There are two NTFS_ATYPE_IDXALLOC attributes and they both have an ID of 0 in the attrlist entries. So, we get a collision when the second one is added to the runs of the first one (because they have the same type and id). Sent a request to get MFT entry 9 to see if there is ID info that we are dropping.... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3088447&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2010-10-21 03:06:50
|
Bugs item #3088447, was opened at 2010-10-15 19:31 Message generated for change (Comment added) made by carrier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3088447&group_id=55685 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: File System Tools Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Brian Carrier (carrier) Assigned to: Brian Carrier (carrier) Summary: NTFS error about adding attribute sequence Initial Comment: Adam Dershowitz reported: General file system error (fs_attr_add_run: error adding additional run (9): No filler entry for 0. Final 176) ( - proc_attrseq: put run- proc_attrlist) ---------------------------------------------------------------------- >Comment By: Brian Carrier (carrier) Date: 2010-10-20 22:06 Message: Looked at the attribute list cluster and the IDX_ALLOC entries have an ID of 0. The BITMAP entries have an ID value set, but the DATA attributes don't either. But, DATA is defined in the base MFT entry. IDX_ALLOC aren't. ---------------------------------------------------------------------- Comment By: Brian Carrier (carrier) Date: 2010-10-20 21:55 Message: Note that Stefan Kelm reported this same error back in Sept. ---------------------------------------------------------------------- Comment By: Brian Carrier (carrier) Date: 2010-10-19 22:49 Message: The base MFT entry didn't have any details about the IDX_ALLOC entries. Requested the ATTRLIST block for more details to see if the id is in there. The verbose log shows that all entries in ATTRLIST have an ID of 0. ---------------------------------------------------------------------- Comment By: Brian Carrier (carrier) Date: 2010-10-18 23:01 Message: Issue seems to be because the $Secure file is VERY fragmented and has lots of attrlists. There are two NTFS_ATYPE_IDXALLOC attributes and they both have an ID of 0 in the attrlist entries. So, we get a collision when the second one is added to the runs of the first one (because they have the same type and id). Sent a request to get MFT entry 9 to see if there is ID info that we are dropping.... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3088447&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2010-10-26 03:19:31
|
Bugs item #3088447, was opened at 2010-10-15 19:31 Message generated for change (Comment added) made by carrier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3088447&group_id=55685 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: File System Tools Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Brian Carrier (carrier) Assigned to: Brian Carrier (carrier) Summary: NTFS error about adding attribute sequence Initial Comment: Adam Dershowitz reported: General file system error (fs_attr_add_run: error adding additional run (9): No filler entry for 0. Final 176) ( - proc_attrseq: put run- proc_attrlist) ---------------------------------------------------------------------- >Comment By: Brian Carrier (carrier) Date: 2010-10-25 22:19 Message: The problem seems to come from a TSK design problem. TSK assumes that the attribute ID will be unique for the file, but in fact it is unique only within the MFT entry. For files that have multiple MFT entries because they are fragmented, it is possible to have two attributes with the same type and ID value. In this scenario, this error is generated. One solution is to specify the name in addition to the type. This would dramatically change the addressing scheme in TSK. Another solution is to assign a unique ID to each attribute that is not located in the base MFT entry. ---------------------------------------------------------------------- Comment By: Brian Carrier (carrier) Date: 2010-10-20 22:06 Message: Looked at the attribute list cluster and the IDX_ALLOC entries have an ID of 0. The BITMAP entries have an ID value set, but the DATA attributes don't either. But, DATA is defined in the base MFT entry. IDX_ALLOC aren't. ---------------------------------------------------------------------- Comment By: Brian Carrier (carrier) Date: 2010-10-20 21:55 Message: Note that Stefan Kelm reported this same error back in Sept. ---------------------------------------------------------------------- Comment By: Brian Carrier (carrier) Date: 2010-10-19 22:49 Message: The base MFT entry didn't have any details about the IDX_ALLOC entries. Requested the ATTRLIST block for more details to see if the id is in there. The verbose log shows that all entries in ATTRLIST have an ID of 0. ---------------------------------------------------------------------- Comment By: Brian Carrier (carrier) Date: 2010-10-18 23:01 Message: Issue seems to be because the $Secure file is VERY fragmented and has lots of attrlists. There are two NTFS_ATYPE_IDXALLOC attributes and they both have an ID of 0 in the attrlist entries. So, we get a collision when the second one is added to the runs of the first one (because they have the same type and id). Sent a request to get MFT entry 9 to see if there is ID info that we are dropping.... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3088447&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2010-10-26 03:41:56
|
Bugs item #3088447, was opened at 2010-10-15 19:31 Message generated for change (Comment added) made by carrier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3088447&group_id=55685 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: File System Tools Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Brian Carrier (carrier) Assigned to: Brian Carrier (carrier) Summary: NTFS error about adding attribute sequence Initial Comment: Adam Dershowitz reported: General file system error (fs_attr_add_run: error adding additional run (9): No filler entry for 0. Final 176) ( - proc_attrseq: put run- proc_attrlist) ---------------------------------------------------------------------- >Comment By: Brian Carrier (carrier) Date: 2010-10-25 22:41 Message: ntfs_proc_attrlist() should process the list and make a map from (ExtMftEntry,Type,ID) to NewID. That structure needs to be passed to ntfs_proc_attrseq(). ---------------------------------------------------------------------- Comment By: Brian Carrier (carrier) Date: 2010-10-25 22:19 Message: The problem seems to come from a TSK design problem. TSK assumes that the attribute ID will be unique for the file, but in fact it is unique only within the MFT entry. For files that have multiple MFT entries because they are fragmented, it is possible to have two attributes with the same type and ID value. In this scenario, this error is generated. One solution is to specify the name in addition to the type. This would dramatically change the addressing scheme in TSK. Another solution is to assign a unique ID to each attribute that is not located in the base MFT entry. ---------------------------------------------------------------------- Comment By: Brian Carrier (carrier) Date: 2010-10-20 22:06 Message: Looked at the attribute list cluster and the IDX_ALLOC entries have an ID of 0. The BITMAP entries have an ID value set, but the DATA attributes don't either. But, DATA is defined in the base MFT entry. IDX_ALLOC aren't. ---------------------------------------------------------------------- Comment By: Brian Carrier (carrier) Date: 2010-10-20 21:55 Message: Note that Stefan Kelm reported this same error back in Sept. ---------------------------------------------------------------------- Comment By: Brian Carrier (carrier) Date: 2010-10-19 22:49 Message: The base MFT entry didn't have any details about the IDX_ALLOC entries. Requested the ATTRLIST block for more details to see if the id is in there. The verbose log shows that all entries in ATTRLIST have an ID of 0. ---------------------------------------------------------------------- Comment By: Brian Carrier (carrier) Date: 2010-10-18 23:01 Message: Issue seems to be because the $Secure file is VERY fragmented and has lots of attrlists. There are two NTFS_ATYPE_IDXALLOC attributes and they both have an ID of 0 in the attrlist entries. So, we get a collision when the second one is added to the runs of the first one (because they have the same type and id). Sent a request to get MFT entry 9 to see if there is ID info that we are dropping.... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3088447&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2010-10-27 03:09:10
|
Bugs item #3088447, was opened at 2010-10-15 19:31 Message generated for change (Comment added) made by carrier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3088447&group_id=55685 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: File System Tools Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Brian Carrier (carrier) Assigned to: Brian Carrier (carrier) Summary: NTFS error about adding attribute sequence Initial Comment: Adam Dershowitz reported: General file system error (fs_attr_add_run: error adding additional run (9): No filler entry for 0. Final 176) ( - proc_attrseq: put run- proc_attrlist) ---------------------------------------------------------------------- >Comment By: Brian Carrier (carrier) Date: 2010-10-26 22:09 Message: I think this is fixed now. Solved by assigning unique IDs to attributes. Previously, TSK assumed that each attribute had a unique ID, but that isn't the case when a file has multiple MFT entries. Sending trunk/NEWS.txt Sending trunk/tsk3/fs/ntfs.c Transmitting file data ... Committed revision 292. ---------------------------------------------------------------------- Comment By: Brian Carrier (carrier) Date: 2010-10-25 22:41 Message: ntfs_proc_attrlist() should process the list and make a map from (ExtMftEntry,Type,ID) to NewID. That structure needs to be passed to ntfs_proc_attrseq(). ---------------------------------------------------------------------- Comment By: Brian Carrier (carrier) Date: 2010-10-25 22:19 Message: The problem seems to come from a TSK design problem. TSK assumes that the attribute ID will be unique for the file, but in fact it is unique only within the MFT entry. For files that have multiple MFT entries because they are fragmented, it is possible to have two attributes with the same type and ID value. In this scenario, this error is generated. One solution is to specify the name in addition to the type. This would dramatically change the addressing scheme in TSK. Another solution is to assign a unique ID to each attribute that is not located in the base MFT entry. ---------------------------------------------------------------------- Comment By: Brian Carrier (carrier) Date: 2010-10-20 22:06 Message: Looked at the attribute list cluster and the IDX_ALLOC entries have an ID of 0. The BITMAP entries have an ID value set, but the DATA attributes don't either. But, DATA is defined in the base MFT entry. IDX_ALLOC aren't. ---------------------------------------------------------------------- Comment By: Brian Carrier (carrier) Date: 2010-10-20 21:55 Message: Note that Stefan Kelm reported this same error back in Sept. ---------------------------------------------------------------------- Comment By: Brian Carrier (carrier) Date: 2010-10-19 22:49 Message: The base MFT entry didn't have any details about the IDX_ALLOC entries. Requested the ATTRLIST block for more details to see if the id is in there. The verbose log shows that all entries in ATTRLIST have an ID of 0. ---------------------------------------------------------------------- Comment By: Brian Carrier (carrier) Date: 2010-10-18 23:01 Message: Issue seems to be because the $Secure file is VERY fragmented and has lots of attrlists. There are two NTFS_ATYPE_IDXALLOC attributes and they both have an ID of 0 in the attrlist entries. So, we get a collision when the second one is added to the runs of the first one (because they have the same type and id). Sent a request to get MFT entry 9 to see if there is ID info that we are dropping.... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3088447&group_id=55685 |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X