Ext2 fail to read `t_alarm`, problem with inode blocks

[Galfurian]

The file has these statistics:

   Size :  86020 N. Blocks :  176
 Access : (33261/rwxr-xr-x ) Uid: (1000, None) Gid: (1000, None)
 Access : 2024-03-08 17:21:50 (1709918510)
 Modify : 2024-03-08 17:21:46 (1709918506)
 Change : 2024-03-08 17:21:46 (1709918506)
 Delete : 1970-01-01  0: 0: 0 (0)
  Links :  1 Flags : 0
 Blocks : [ 1345 1346 1347 1348 1349 1350 1351 1352 1353 1354 1355 1356 ]
IBlocks : 1357 [ 1358 1359 1360 1361 1362 1363 1364 1365 1366 ]
DBlocks : 0
TBlocks : 0

The file size is 86020 bytes, and it uses a total of 22 blocks. Where, 21 blocks are used to store data, while another block (1357) is used for indirect block addressing.

Now, 21 blocks with a block size of 4096 can accommodate only 86016 bytes. Where are those last 4 bytes stored?

Currently, it tries to read a 23rd block, which does not exist in the indirect block table. Thus, it fails to load the executable.

[fischerling]

On my system on the current develop branch (6ab208623348fc25dec4ee8290bcd8bdb4d8d0a5) I can not reproduce an error reading t_alarm.

Is this with a fresh build or after running and using MentOS ?

[Galfurian]

I think it is a corner case happening during reading and writing procedures inside the ext2. I "allegedly" solved the problem this past weekend. I'll test it out for a little more, and make a pull request by the end of today.

[Galfurian]

This problem is not occurring anymore. If it happens again, I will open another (update) issue.