[sleuthkit-developers] [ sleuthkit-Bugs-2982426 ] Slow FAT32 dir listing

[SourceForge.net <no...@so...>]

Bugs item #2982426, was opened at 2010-04-05 20:14
Message generated for change (Settings changed) made by carrier
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2982426&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: Nobody/Anonymous (nobody)
Summary: Slow FAT32 dir listing

Initial Comment:
If you run fls on a big FAT file system, it is slow because it needs to hunt the file system for the parent directory (in order to populate the metadata address of the ".." entry). In doing so, it ends up trying to load up the orphan directory and this takes a long time.    The only good solution seems to be to somehow cache the data because if we just skip the OrpanFiles directory, then if we are listing hte contents of an Orphan Directory, we'll never find the parent directory...


----------------------------------------------------------------------

>Comment By: Brian Carrier (carrier)
Date: 2010-04-06 20:28

Message:
The code was scanning the entire image even after it found the needed
parent.  I think the original goal was to fill up the internal cached DB
once and then never worry about it, but that is not good for fls. Now, the
search stops after the parent is found.


Sending        branches/sleuthkit-3.1/NEWS.txt
Sending        branches/sleuthkit-3.1/tsk3/fs/fatfs_dent.c
Sending        trunk/NEWS.txt
Sending        trunk/tsk3/fs/fatfs_dent.c
Transmitting file data ....
Committed revision 188.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2982426&group_id=55685