Opened 11 years ago
Closed 11 years ago
#527 closed defect (fixed)
mkext2.py does not handle block boundaries in directory contents correctly
| Reported by: | Martin Sucha | Owned by: | |
|---|---|---|---|
| Priority: | major | Milestone: | 0.6.0 |
| Component: | helenos/fs/ext4fs | Version: | mainline |
| Keywords: | Cc: | ||
| Blocker for: | Depends on: | ||
| See also: |
Description
When trying to run python, I found a bug in ext4fs and/or mkext2.py. With the python lib copied to the ramdisk, ext4fs fails to find lib/python2.7/site.py in the directory (it does not show up in listing printed by ls and the python binary couldn't find it either). Trying to (re)create this empty file using edit causes an assertion to be hit:
Assertion failed (entry_len ⇐ block_size) in file "libext4_directory.c", line 354
Note that site.py is an empty file. I was not able to reproduce this simply by adding an empty file to the root or a subdirectory of the ramdisk though.
I used amd64 build of HelenOS mainline,1792 with Zbigniew's python patches built using the old toolchain (GCC 4.7.2) (I suspect neither to be connected to this issue, though)
Attachments (1)
Change History (3)
by , 11 years ago
| Attachment: | image.iso.lzma added |
|---|
comment:1 by , 11 years ago
| Summary: | Ext4 bug with an empty file in a large image → mkext2.py does not handle block boundaries in directory contents correctly |
|---|
This is a bug in mkext2.py. It created a directory entry spanning accross the block boundary at offset 0x4000 of the contents of directory inode 242 in the ramdisk of the attached image.
amd64 iso image that could be used to reproduce the problem