Re: Bug in ext2fs or e2fsck 1.02?

Stephen C. Tweedie (
Thu, 30 Jan 1997 22:25:13 GMT


On Tue, 21 Jan 1997 12:14:00 -0500, "Theodore Y. Ts'o" <tytso@MIT.EDU>

> Date: Sun, 19 Jan 97 00:12:07 MST
> From: (Colin Plumb)

> While dealing with some disk corruption, I managed to create some
> directories which appeared, to ls, to be fine, but would fail
> the empty_dir test in fs/ext2/namei.c:553. To be precise, line 572,
> where it does "strcmp(".", de->name). It seems that de->name[1] was
> not '\0'. Of course, de->name_len was 1, so ls produced fine
> results, but the test failed.

> e2fsck 1.02 (I know, I know) does not detect or correct this problem,
> but ext2fs doesn't like it. I don't know which of the two is considered
> to have the bug, but one of them does.

> The bug is definitely in the kernel, since names in directories are not
> null-terminated. (If a directory name is a multiple of 4
> bytes long, there's not even any room for the null termination
> character.)

> At the same time, because the 2.0 kernel is doing this, I will be fixing
> e2fsprogs to make sure the directory names are null terminated.

Actually, it's debatable where the bug is. Once a directory is
created, the kernel will *never* touch the . or .. entries. If they
become changed in any way, it's not unreasonable for the kernel to
object. On the other hand, neither is it unreasonable for the kernel
only to look at the significant characters, ignoring padding.

The problem is just in the disagreement between e2fsck and the kernel
over which is the right thing to do. We can fix it in either e2fsck
or the kernel, and neither is really any more correct than the other.
For what it's worth, I tend to think that the kernel can afford to be
a conservative here, so any change in the . or .. dirents is
reasonable cause for getting upset.