info['file_id'] not set properly when there is a directory

[papadop]

Description of the problem

When a FIF file contains a directory, the file_id item of the info dictionary remains to None. This is because the _read_dir_entry_struct ignores (wrongly in my opinion) the first tag in the directory, which happens to be the file_id. Alternatively, the file_id has already been read in open.py (_fiff_open), but the id is not used.

Correction:
Change _read_dir_entry_struct to:

def _read_dir_entry_struct(fid, tag, shape, rlims):
    """Read dir entry struct tag."""
    pos = tag.pos
    entries = list()
    for offset in range(tag.size // 16):
    ....

where ... mean "code unchanged".

I can create a patch if the analysis above is validated...

Steps to reproduce

import mne
sample_data_folder = mne.datasets.sample.data_path()
raw = mne.io.read_raw(sample_data_folder / "MEG" / "sample" / "sample_audvis_filt-0-40_raw.fif")
print(raw.info['file_id'])

Link to data

No response

Expected results

{'version': 65539, 'machid': array([-1137681485, 1834156032], dtype='>i4'), 'secs': 1384803104, 'usecs': 923597}

Actual results

None

Additional information

Platform Linux-6.14.6-300.fc42.x86_64-x86_64-with-glibc2.41
Python 3.13.3 (main, Apr 22 2025, 00:00:00) [GCC 15.0.1 20250418 (Red Hat 15.0.1-0)]
Executable /usr/bin/python
CPU 12th Gen Intel(R) Core(TM) i9-12900H (20 cores)
Memory 62.5 GiB

Core
├☑ mne 1.9.0 (latest release)
├☑ numpy 2.2.5 (OpenBLAS 0.3.29 with 20 threads)
├☑ scipy 1.14.1
└☑ matplotlib 3.10.0 (backend=qtagg)

Numerical (optional)
├☑ sklearn 1.6.1
├☑ nibabel 5.3.2
├☑ nilearn 0.11.1
├☑ pandas 2.2.3
├☑ h5io 0.2.4
├☑ h5py 3.12.1
└☐ unavailable numba, dipy, openmeeg, cupy

Visualization (optional)
├☑ pyvista 0.44.1 (OpenGL 4.6 (Core Profile) Mesa 25.0.4 via Mesa Intel(R) Iris(R) Xe Graphics (ADL GT2))
├☑ pyvistaqt 0.11.1
├☑ vtk 9.4.0
├☑ qtpy 2.4.2 (PyQt5=5.15.16)
├☑ pyqtgraph 0.13.7
└☐ unavailable ipympl, mne-qt-browser, ipywidgets, trame_client, trame_server, trame_vtk, trame_vuetify

Ecosystem (optional)
├☑ mne-bids 0.16.0
├☑ edfio 0.4.8
└☐ unavailable mne-nirs, mne-features, mne-connectivity, mne-icalabel, mne-bids-pipeline, neo, eeglabio, mffpy, pybv

[larsoner]

It would be good to mirror what show_fiff and mne_show_fiff do here. So looking at the original sample dataset for example:

larsoner:~/mne_data/MNE-sample-data/MEG/sample$ show_fiff sample_audvis_raw.fif -v
100 = file ID        	1.1 0x1083ff3f3a0000 Tue 03 Dec 2002 02:01:12 PM EST
101 = dir pointer    	-1
106 = free list      	-1
104 = {              	100 = measurement   
103 = block ID       	1.1 0x306e058d6e0000 Tue 03 Dec 2002 02:01:10 PM EST
104 = {              	101 = meas. info    
212 = scientist      	MEG
...
100 = file ID        	1.1 0x1083ff3f3a0000 Wed 10 Oct 2001 04:06:45 PM EDT
...

and

larsoner:~/mne_data/MNE-sample-data/MEG/sample$ mne_show_fiff --in sample_audvis_raw.fif --verbose
 100 = file ID           	1.1 0x1083ff3f3a0000 Tue Dec  3 14:01:12 2002
 101 = dir pointer       	-1
 106 = free list         	-1
 104 = {	100 = measurement
 103 = block ID          	1.1 0x306e058d6e0000 Tue Dec  3 14:01:10 2002
 104 = {	101 = meas. info
 212 = scientist         	MEG
...
 100 = file ID           	1.1 0x1083ff3f3a0000 Wed Oct 10 16:06:45 2001
...

So it does seem like we should populate info["file_id"] in MNE-Python. But I do see that it's (probably) correct, or at least non-None:

larsoner:~/mne_data/MNE-sample-data/MEG/sample$ python -c "import mne; print(mne.io.show_fiff('sample_audvis_raw.fif', tag=100, max_str=80))"
999  = FIFFB_ROOT
    100  = FIFF_FILE_ID (20b ids)  = {'version': 65537, 'machid': array([   1082367, 1060765696], dtype='>i4'), 'secs ... dict len=4
    100  = FIFFB_MEAS
        103  = FIFF_BLOCK_ID (20b ids)  = {'version': 65537, 'machid': array([    3173893, -1922170880], dtype='>i4'), 'se ... dict len=4
        101  = FIFFB_MEAS_INFO
            100  = FIFF_FILE_ID (20b ids)  = {'version': 65537, 'machid': array([   1082367, 1060765696], dtype='>i4'), 'secs ... dict len=4

and with

>>> import mne
>>> raw = mne.io.read_raw_fif("sample_audvis_raw.fif")
>>> raw.info["file_id"]
{'version': 65537, 'machid': array([   1082367, 1060765696], dtype='>i4'), 'secs': 1038942072, 'usecs': 190548}
>>> 

So it works for that file! I suspect that maybe the truncated version that was written by MNE-C (I think?) a loooooong time ago did not set this value, and so having None might be the correct behavior actually?

[papadop]

The real difference is reading the directory in slow_mode (mandatory for "sample_audvis_raw.fif" because it does not have a directory at the end of the file) and fast mode (i.e reading the directory (list of tag headers) placed at the end of the file which is the case for "sample_audvis_filt-0-40_raw.fif"). IMHO the result should not depend on the way of reading that directory (assuming the slow and fast directories contain the same information which is the case for "sample_audvis_filt-0-40_raw.fif").

The fact that dir_pointer is -1 for "sample_audvis_raw.fif" indicates that there is no such directory.
If you try with "sample_audvis_filt-0-40_raw.fif", you will see that dir_pointer has a non-negative value indicating the presence of that directory, which enables the fast mode.

And that's actually the reasoning why I think the current behaviour is wrong. In slow mode the first file_id header is processed while in fast mode it is skipped !

[larsoner]

Ahh that makes sense @papadop ! Would you be up for making a PR to fix it?

[papadop]

Will do that... in a few days.