# Extraction of Creation-Time for Recovered Files on Windows FAT32 File System
## 3 Proposed Method to Extract Creation-Time Bound
### Working Mechanism of Proposed Method
_the creation-time of a partially overwritten file is earlier than that of a file overwriting the partially overwritten file._  
**Property 2**. _if there are_  
\[(\cdots,?_{i},\cdots,?_{i+1},\cdots,?_{i+2},\cdots)\ *\ (\cdots,X^{i},?_{j}^{i+1},Y^{i+2},\cdots) \tag{4}\]  
_in the file creation event sequence and_  
\[[\cdots X,*_{a},?_{b},Y,\cdots], \tag{5}\] \begin{table}
\begin{tabular}{c l} \hline \hline
**Notation** & **Description** \\ \hline? & a single hidden event of a deleted file \\ \(*\) & uncertain number of continuous hidden events of deleted files \\ \(X^{i}\) & file \(X\) stored in the directory entry position of \(?_{i}\) \\ \((\ )\) & sequential file creation event flow from the beginning of direction entries to their end \\ \([\ ]\) & sequential file allocation flow from the beginning of content clusters to their end \\ \hline \hline \end{tabular}
\end{table} 
Table 1: Description of notations. in the file allocation sequence, then \(?_{j}^{i+1}\) is a candidate of creation event only for the file recovered from \(*_{a}\) or \(?_{b}\), but not for the other recovered files._  
In the example of Figure 6, \(?_{1}\) in Equation (2) is a candidate of creation event only for the file recovered from \(?_{b}\) in Equation (3) according to Property 2. \((A,?_{1},C)\) is a simple form of Equation (4) where \(A\), \(?_{1}\) and \(C\) are continuous file creation events. Also?2 in Equation (2) is a candidate only for the file recovered from \(?_{d}\) in Equation (3). After applying Property 1 and Property 2, the final candidates for the file recovered from \(?_{b}\) are \(?_{1}\) and \(?_{3}\) (or \(*_{4}\)). This means that the creation-time of the file recovered from \(?_{b}\) is located between the creation-time of file A and that of file C, or between the creation-time of file E and that of file H. The final candidates of the file recovered from \(?_{d}\) are \(?_{2}\) and \(?_{3}\) (or \(*_{4}\)). Figure 8 shows another example which is continued from the example of Figure 6. File K, file L, and file M are allocated sequentially. Next file J, file C and file L are deleted sequentially. At last file N, file O, \(\cdots\), file R and file S are allocated sequentially. Figure 8a shows the directory entries that are established according to the Wrap-around Next Available algorithm. The directory entries of deleted files C, J and L are eliminated by recording the directory entries of files Q and R respectively. Then the file creation event sequence in Figure 8a can be represented with  
\[(A,?_{1},?_{2},?_{3},E,?_{4})\ *_{5}\ (H^{1},?_{6}^{2},?_{7}^{3},?_{8},M,N,O,P)\ *_{9}\ (Q^{6},R^{7},S^{8}). \tag{6}\]  
There are three sequential file creation event flows through two directory entry clusters: \((A,?_{1},?_{2},?_{3},E,?_{4})\), \((H^{1},?_{6}^{2},?^{3},?_{7}^{4},K,?_{8},M,N,O,P)\) and \((Q^{6},R^{7},S^{8})\). Figure 8b shows content clusters that are established according to the deletion-backward next fit algorithm. Similar to Figure 6b, boxes filled with dark gray denote clusters containing a deleted file, and names of deleted files in dark gray boxes are depicted for the sake of readability although they disappeared actually. Figure 9 shows the analysis procedure of the file allocation pattern of Figure 8b. The top figure in Figure 9 shows the first traversal of sequential file allocation according to the deletion-backward next fit algorithm. The first sequential file allocation traversal is \([A,*_{a},?_{b},*_{c},?_{d},E]\). The notation \(?_{b}\) represents the deleted file in clusters 6 and 7, and the notation \(?_{d}\) represents the deleted file in cluster 15. The notation \(*_{a}\) represents uncertain number of file allocations hidden under file H, and The notation \(*_{c}\) represents an uncertain number of file allocations hidden under file N, file O and file I. We cannot exactly know how many file allocations are hidden under overwriting file allocation.