Back to basics - File slack

In this post, I wanted to revisit the concept of partial file recovery do to overwrite of unallocated clusters and the concept of RAM slack value in investigations.  Unfortunately, I see less and less explanations of basic concepts like this for those entering this field. 

In this case, file1.txt saved on a drive with cluster size 3, or 1536 bytes per cluster.  Therefore, the file will require 4 clusters to store where the last cluster will only store 52 bytes.  The last cluster consists of 3 sectors where the first sector needs to be completed to 512 bytes to complete the sector.  It needs 460 bytes of data that it will grab from RAM and the last two sectors will remain untouched.  The RAM slack and the disk slack will remain the same until file1.xt is modified or deleted.  RAM slack and disk slack become protected that might contain pertinent data without the knowledge of the user.  When file1.txt is deleted, all the 4 clusters become unallocated, so available to overwrite.  Here, file2.txt is saved that will require 3 clusters.  So, the fourth cluster of file1.txt will remain unallocated until another file overwrites it or file2.txt content expanded to the next cluster.  File2.txt will overwrite the first two clusters and 28 bytes of the first sector of the third cluster.  484 bytes will be grabbed from RAM to fill the cluster with a complete 512 bytes of data and the last 2 sectors in the third cluster will retain the previous file's content.  The fourth cluster will also have 52 bytes of file1.txt retained, but we can only recover 1024 + 52 bytes of file1.txt that used to be 4660 bytes long.  Here e have two partial sectors with data from RAM that might contain keywords or passwords of applications.  Notice the difference between the logical and physical size.