Very interesting. I am going to test it. I am very curious to see if the created date/time on the destination folder is the same as the source input.
I believe that it was on the test data, at least on the Ubuntu machine. I can't recall what happened on the Windows box, and don't have access to the test data at the moment to check. I would expect it to be the same, but can't say for sure.
Good Luck
Stu
I did test the python code on my MBP, OS X 10.7.5. I used the python script, capture.py, with the source path of a known directory. Before running the script, I verified the creation date two ways. First, using Terminal, I used the ls -lU command ( U gives the creation date). I verified the creation date using fileXray to introspect the folder. Both agreed on the creation date.
I then ran capture.py, below. I added the last line. I'm a visual guy )
#!/usr/bin/python
import os
import shutil
srcfile = raw_input("set source path")
dstfile = raw_input("set dest path")
shutil.copytree(srcfile, dstfile)
print 'The value of dstfile is', dstfile
After running the script I repeated the steps using Terminal to verify the creation date of the folder. The results were surprising. The creation date changed, but, not what you would expect (the time/date the new folder was created). Nope, the dstfile was given the attributeModDate of the srcfile as the creationDate. See the clip below. I didn't test this on Ubuntu or Windows, however, I would not consider using shutil.copytree to create forensic deliverables specifically on Mac OS X 10.7.x I do plan to test Linux at a later time.
Illustration from DiffFork ; Note the difference in date/time stamps from simply running the python script.
Before
path = Macintosh HD/Users/sgware/Forensics/research
# Catalog Folder Thread Record
# Record 1 in node 23275 beginning at 512-byte sector 0x1c56c0
parentID = 608790
nodeName = research
# Catalog Folder Record
# Record 21 in node 25564 beginning at 512-byte sector 0x1ce5d0
type = folder
folder ID = 7240718
flags = 0000000010000000
. Folder has date-added stored in Finder Info.
valence = 8
createDate = Fri May 25 144637 2012
contentModDate = Fri Oct 19 165219 2012
attributeModDate = Fri Oct 19 165219 2012
accessDate = Fri Oct 19 205742 2012
backupDate = 0
After
path = Macintosh HD/Users/sgware/Forensics/capture
# Catalog Folder Thread Record
# Record 89 in node 38573 beginning at 512-byte sector 0x2012e0
parentID = 608790
nodeName = capture
# Catalog Folder Record
# Record 9 in node 25564 beginning at 512-byte sector 0x1ce5d0
type = folder
folder ID = 9576100
flags = 0000000010000000
. Folder has date-added stored in Finder Info.
valence = 8
createDate = Fri Oct 19 165219 2012
contentModDate = Fri Oct 19 165219 2012
attributeModDate = Fri Oct 19 210116 2012
accessDate = Fri Oct 19 210115 2012
backupDate = 0
Scott
A directory copy job is pretty simple.
cp -nprv (Source) (Destination)
n - Do not overwrite an existing file
p - Preserves attributes, including resource forks (on macs)
R - When the source file is a directory and the path ends in with a slash (/) then the entire contents of the directory are copied recursively
v - Causes files to be listed when copied
You can check the man pages for more about the commands but these are what I always use for a straight copy job. Works for Ubuntu and Macs too.
Others I know use tar.
A quick test of cp -nprv on my MBP was interesting as well. Only the accessDate was preserved. The others three were modified. I know what the man pages say, but, I observed different behavior. This has been my experience with OS X. You have to verify everything.
The suggestion of imaging the disk and then exporting the files/folders using the FTK Imager is definitely going to provide the metadata available at the time the image was snapped.
These other methods of copying files may result in good data, but, the metadata is at risk.
Scott
One last note on this thread. Buster, your code (python script) was not the source of the metadata manipulation. HFS+ is doing it for some reason. I saw the same transposition of the attributeModDate to creationDate when "cp -nprv" was executed on a folder. Not sure why the filesystem is making that change in the catalog file. Would take more extensive testing to determine the rationale.
The important point is that copying, regardless of implementation, is likely to change the metadata. You have to be able to explain it if that is the method used.
Scott