# Extraction of Creation-Time for Recovered Files on Windows FAT32 File System
## 5 Conclusions and Discussions  
In this article, we verify the file allocation behavior of Windows FAT32 file system through elaborate examinations of recent Windows operating systems. When storing the file contents, the file allocator searches for available content clusters linearly from the beginning of the data area according to the next fit algorithm. If some files located before the lastly allocated cluster are deleted, the file allocator searches available space from the content cluster with the lowest index among contents clusters allocated to deleted files. Otherwise, the file allocator searches available space from the lastly allocated content cluster according to the next fit algorithm. The file allocation pattern of Windows FAT32 file system is called deletion-backward next fit algorithm. When recording the file meta information, the Windows FAT32 file system searches for an available directory entry space according to the next available algorithm until the last directory entry space is assigned. After the last directory entry space is assigned, it searches from the first directory entry space. When all directory entry spaces are unavailable, another cluster is allotted to further meta information recording. The directory entry allocation pattern of Windows FAT32 file system is called wrap-around next available algorithm. \begin{table}
\begin{tabular}{c c c} \hline \hline
**No. of Created (Deleted) Files** & **Proposed Scheme** & **Previous Method** \\ \hline
50 (12) & 100\% & 60\% \\
100 (25) & 100\% & 33.3\% \\
150 (37) & 100\% & 15.4\% \\ \hline \hline \end{tabular}
\end{table} 
Table 3: Accuracy of analyzed creation-time bound. On the basis of the verified behaviors of Windows FAT32 file system, we propose a novel method that finds the creation order of files recovered without the creation of time information. Creation order of recovered files is established utilizing both the correlation between data area locations of files and their creation order, and the correlation between directory entry locations of files and their creation order. The file creation order is directly related to the creation-time bound of files recovered without the creation-time information. Our method is not applicable to the file allocation case with fragmentations rarely occurred. File fragmentation occurs only when the storage space is fully occupied. Non-existence of file fragmentation is confirmed by checking that there is no data behind the end of allocated content clusters. In experiments on a commercial device, we confirm that the actual creation order of each recovered file belongs to one of the creation order candidates found by the proposed method. Our method derives fewer creation order candidates for recovered files, where the number of deleted files is smaller. Our method is suitable for specialized multimedia storages with a few file deletions, e.g., digital cameras, portable video recorders, and CCTV. Although we address only three properties to reduce the number of creation order candidates, there are possibly more properties to further reduce the number of candidates. We leave the problem of minimizing the number of creation order candidates for further study. We will also investigate the file allocation behaviors of other file systems such as flash transition layer (FTL), extended FAT (exFAT), EXT Linux file system, and new technology file system (NTFS) in further study, while this study is bounded to the FAT32 file system. Conceptualization, W.Y.L. and H.L. ; implementation, K.H.K. and W.Y.L. ; testing and validation, K.H.K. and W.Y.L. ; writing--original draft preparation, W.Y.L. ; writing--review and editing, H.L. This research was supported by Basic Science Research Program through the National Research Foundation of Korea(NRF) funded by the Ministry of Education (NRF-2018R1D1A1B07045806). The authors declare no conflict of interest. It is clear that the creation-time of a partially overwritten file is earlier than that of a file overwriting the partially overwritten file.