Add birthtime, blocksize and blks to stat output for NTFS

[Miauwkeru]

st_block uses the realsize if defined, oterwise it uses the size
the real size on disk is only defined if the file is not a resident file.

st_birthtime and st_birthtime_ns now use the creation_time from a MFT Record

Other timestamps where incorrectly used, and have been changed:
st_mtime: changed from using last_change_time to last_modification_time

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 76.50%. Comparing base (2389376) to head (fe92d40).
Report is 2 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #848      +/-   ##
==========================================
+ Coverage   76.48%   76.50%   +0.02%     
==========================================
  Files         314      314              
  Lines       26933    26945      +12     
==========================================
+ Hits        20600    20615      +15     
+ Misses       6333     6330       -3     

Flag	Coverage Δ
unittests	76.50% <100.00%> (+0.02%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[Schamper]

[Miauwkeru]

dissect.target/dissect/target/helpers/fsutil.py

Line 131 in c5bf1ed

"_st_ctime": "integer time of last change",

So what do we want to use, the windows style or unix style? Cause I'd prefer them to be consistent across dissect. Regardless what the python docs say. As we change it anyways

[Schamper]

The entire filesystem layer is designed to be consistent with Python since the beginning of Dissect.

[Miauwkeru]

The entire filesystem layer is designed to be consistent with Python since the beginning of Dissect.

In that case, have we changed that for any other filesystem then? Where the c_time gets used for the birth timestamp on the machine? Or should we adapt the btrfs stuff too when using windows?

Cause in this current case it seems to only hold for ntfs doesn't it?

[Schamper]

https://github.com/python/cpython/blob/3.12/Modules/posixmodule.c#L2142-L2145
https://docs.python.org/3/library/os.html#os.DirEntry.stat (deprecation note)

The only thing missing currently is setting st_birthtime and st_birthtime_ns to their proper values on Windows filesystems (read, NTFS).

Btrfs and other filesystems don't have this, as they actually properly expose all 4 timestamps.

[Miauwkeru]

https://github.com/python/cpython/blob/3.12/Modules/posixmodule.c#L2142-L2145 https://docs.python.org/3/library/os.html#os.DirEntry.stat (deprecation note)

The only thing missing currently is setting st_birthtime and st_birthtime_ns to their proper values on Windows filesystems (read, NTFS).

Btrfs and other filesystems don't have this, as they actually properly expose all 4 timestamps.

st_birthtime gets set here right?: https://github.com/python/cpython/blob/aee219f4558dda619bd86e4b0e028ce47a5e4b77/Python/fileutils.c#L1122

where ctime gets changed afterwards at the posixmodule sets it to the value in st_birthtime, which is only used for backwards compatibility.

So sure, I'll set the ctime to birthtime for now. And make a note about it for backwards compatibility

[Schamper]

st_birthtime gets set here right?: https://github.com/python/cpython/blob/aee219f4558dda619bd86e4b0e028ce47a5e4b77/Python/fileutils.c#L1122

In our code.

[Miauwkeru]

st_birthtime gets set here right?: https://github.com/python/cpython/blob/aee219f4558dda619bd86e4b0e028ce47a5e4b77/Python/fileutils.c#L1122

In our code.

which I've done?

[pyrco]

Yes, it seems to be correct now.

Both st_birthtime and st_ctime are now set to the CreationTime attribute, as is done by Python up to and including Py3.12.

The change for st_mtime to the LastModificationTime attribute (which is called LastWriteTime in the Windows fileapi.h, and is the name Python uses) is also in line with how python handles this timestamp.

[Horofic]

Ack on the timestamps. Is @Poeloe still on for a code-review?

[pyrco]

I'm not sure this double ceiling is correct, it could lead to a really inflated number of blocks, e.g.:

st_size: 256
st_blksize: 128
->
math.ceil(128/512) * math.ceil(256/128) = math.ceil(1/4) * math.ceil(2) = 1 * 2 = 2

Inflates the apparent size by a factor of 4

st_size: 1024
st_blksize: 768
->
math.ceil(768/512) * math.ceil(1024/768) = math.ceil(3/2) * math.ceil(4/3) = 2 * 2 = 4

Inflates the apparent size by a factor of 2

If I read and interpret the various sources of what st_blocks should be it seems to me it represents the size on disk in blocks (which are 512 bytes in our implementation).
The POSIX/opengroup for example says: "Number of blocks allocated for this object."

The on disk is important in the sense that if files that are e.g. sparse their size on disk is smaller than their actual size, the same holds for example for files that are compressed on the filesystem layer.

So I think we can just do a math.ceil(st_info.st_size / 512) here. It also means that for symbolic links st_blocks should be 0, unless the symbolic link data is not (only) contained in the inode structure.