blob: cc694b703176426d789e34fa15f8515a866d4c5e [file] [log] [blame]
Theodore Ts'oc461e161999-01-12 23:40:01 +00001User request:
2
3BTW: Could you please add some sort of deleted and possibly corrupted file
4 and inode list to e2fsck report. There should be filenames deleted
5 from directory inodes, files with duplicate blocks e.t.c.
6 It's pretty annoying to filter this information from e2fsck output
Theodore Ts'oe2e69ba1999-06-18 01:13:31 +00007 by hand :-
8
9------------------------------------------
10
11Add a "answer Yes always to this class of question" response.
12
13----------------------------------
14
15ext2fs_flush() should return a different error message for primary
16versus backup superblock flushing, so that mke2fs can print an
17appropriate error message.
18
19-----------------------------------
20
21Put code into e2fsck to support imagic inodes....
22
23---------------------------------
24
25Deal with the case where /lost+found isn't a directory....
26
27
28--------------------------------------
29Date: Mon, 08 Mar 1999 21:46:14 +0100
30From: Sergio Polini <s.polini@mclink.it>
31
32
33I'm reading the sorce code of e2fsck 1.14.
34In pass2.c, lines 352-357, I read:
35
36if ((dirent->name_len & 0xFF) > EXT2_NAME_LEN) {
37 if (fix_problem(ctx, PR_2_FILENAME_LONG, &cd->pctx)) {
38 dirent->name_len = EXT2_NAME_LEN;
39 dir_modified++;
40 }
41}
42
43I think that I'll never see any messages about too long filenames,
44because "whatever & 0xFF" can never be "> 0xFF".
45Am I wrong?
46--------------------------------------
47
48debugfs --- ls of a corrupt directory (or a non-directory inode) with
49inconsistent lengths can cause it to core dump! Should fix to make it
50more robust.
51
52-------------------------------------
53
54
55