TODO

   1 User request:
   2
   3 BTW: 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
   7      by hand :-
   8
   9 ------------------------------------------
  10
  11 Add a "answer Yes always to this class of question" response.
  12
  13 ----------------------------------
  14
  15 ext2fs_flush() should return a different error message for primary
  16 versus backup superblock flushing, so that mke2fs can print an
  17 appropriate error message.
  18
  19 ---------------------------------
  20 Date: Mon, 08 Mar 1999 21:46:14 +0100
  21 From: Sergio Polini <s.polini@mclink.it>
  22
  23
  24 I'm reading the sorce code of e2fsck 1.14.
  25 In pass2.c, lines 352-357, I read:
  26
  27 if ((dirent->name_len & 0xFF) > EXT2_NAME_LEN) {
  28         if (fix_problem(ctx, PR_2_FILENAME_LONG, &cd->pctx)) {
  29                 dirent->name_len = EXT2_NAME_LEN;
  30                 dir_modified++;
  31         }
  32 }
  33
  34 I think that I'll never see any messages about too long filenames,
  35 because "whatever & 0xFF" can never be "> 0xFF".
  36 Am I wrong?
  37 --------------------------------------
  38
  39 Add chmod command to debugfs.
  40
  41 ------------------------------------------
  42
  43 Maybe a bug in debugfs v.1.14:
  44 if a file has more than one hardlink, only the first filename is shown when
  45 using command
  46         ncheck <inode>
  47
  48 ------------------------------------
  49
  50 Add a filesystem creation date to the superblock
  51
  52 -----------------------------------
  53 Date: Tue, 18 Jan 2000 17:54:53 -0800 (PST)
  54 From: Alan Blanchard <alan@abraxas.to>
  55 To: tytso@MIT.EDU
  56 Subject: DEBUGFS - thanks and a feature idea
  57 Content-Type: TEXT/PLAIN; charset=US-ASCII
  58
  59 Theodore:
  60
  61 First, let me thank you for writing debugfs. Recently, my Linux box
  62 (RH 6.0, 400 MHz PIII, on a DSL line) was hacked into.  The intruder did
  63 an "rm -Rf" on a 34 GB drive with about 5GB of data on it.  I was able to
  64 restore essentially the entire thing with debugfs and a bit of C code and Perl.
  65 Actually, I could have done the entire thing with debugfs and Perl, but I
  66 thought it would be too slow.
  67
  68 During this exercise, I noticed that one small feature was lacking that would
  69 have made my job a bit easier.  The length of a deleted directory is
  70 reported as 0, hence debugfs won't dump the contents of the directory to a
  71 file using the "dump" command.  The only thing that saved me was that the
  72 list of disk blocks is not zeroed out.  I was able to dump the contents of the
  73 directories by using debugfs to get the relevant block numbers, then
  74 using dd to get the actual data.
  75
  76 If debugfs had a feature where it ignored the size of a directory reported by
  77 the inode and instead just dumped all the blocks, it would have facilited
  78 things a bit. This seems like a very easy feature to add.
  79
  80 Again, thanks for writing debugfs (and all the other Linux stuff you've written!).
  81
  82 Cheers,
  83 Alan Blanchard
  84 alan@abraxas.to
  85
  86
  87 -------------------------------------------------------------------
  88
  89 Date: Fri, 21 Jan 2000 14:07:12 -0800
  90 From: "H. Peter Anvin" <hpa@www.transmeta.com>
  91 Subject: mkfs -cc and fsck -c
  92
  93 b) An option to mkfs to zero the partition.  Yes, it can be done with
  94 dd, but it would be a nicer way of doing it.
  95
  96 ------------------------------------------------------------------
  97
  98 Add support for in ext2fs_block_iterate() for a returning the
  99 compressed flag blocks to block_iterate.  Change default to not return
 100 EXT2_COMPRESSED_BLKADDR.  Change e2fsck to pass this flag in.
 101
 102 (The old compression patches did this by default all the time, which
 103 is bad, since it meant e2fsck never saw the EXT2_COMPRESSED_BLKADDR
 104 flagword.
 105
 106 ------------------------------------------------------------
 107
 108 E2fsck should offer to clear all the blocks in an indirect block, not
 109 the entire inode, so there's better recovery for when an indirect
 110 block gets trashed.
 111
 112
 113 -------------------------------------------------------------
 114
 115 From: Yann Dirson - LOGATIQUE <Yann.Dirson@France.Sun.COM>
 116 Date: Thu, 2 Mar 2000 13:52:13 +0100 (MET)
 117
 118 During my experiments on the broken system, I noticed the following in
 119 the badblocks program (which I'm aware is not designed for IDE drives)
 120 - I'd probably have already fixed them if my home system was up :(
 121
 122 * the syntax summary documents 2nd arg as blocks_count, which should
 123 probably read something like end_count.
 124
 125 * testing past end of device is not detected, and lists those blocks
 126 as bad, whereas they simply do not exist.
 127
 128
 129 I think I'll probably add a "max count" option to findsuper(8), so
 130 that I do not have to wait for the whole disk to be scanned when the
 131 system had to be launched with "init=/bin/sh", in which case Ctrl-[CZ]
 132 and friends appear to be absolutely ignored.
 133
 134
 135 Somewhat unrelated, I just noticed the
 136 http://web.mit.edu/tytso/www/linux/ext2.html could be updated:
 137
 138 - could mention SGI xfs (http://oss.sgi.com/projects/xfs/ - they just
 139   release 0.03 snapshot)
 140
 141 ----------------------------------------------------------------
 142
 143 Return-Path: <tytso@MIT.EDU>
 144 Date: Thu, 10 Feb 2000 13:20:14 -0500
 145 From: "Theodore Y. Ts'o" <tytso@MIT.EDU>
 146 To: R.E.Wolff@BitWizard.nl
 147 In-Reply-To: Rogier Wolff's message of Thu, 10 Feb 2000 08:46:30 +0100 (MET),
 148         <200002100746.IAA24573@cave.bitwizard.nl>
 149 Subject: Re: e2fsck request for enhancement.
 150 Phone: (781) 391-3464
 151
 152    Date: Thu, 10 Feb 2000 08:46:30 +0100 (MET)
 153    From: R.E.Wolff@BitWizard.nl (Rogier Wolff)
 154
 155    Lately, while trying to recover a broken disk, my system froze (twice,
 156    until I tried something else) while copying the disk.
 157
 158    So I had a file of about 50Mb that was growing frantically at the
 159    moment of the crash.
 160
 161    e2fsck, then finds an indirect block that is completely bogus. It
 162    starts by asking me if it's ok to clear a few of the referenced
 163    blocks. I say yes. Then it comes to the conclusion:
 164
 165       too many invalid blocks. Clear inode?
 166
 167    and then I get the option to delete the whole file. Not to truncate
 168    the file to a "working" size.
 169
 170
 171    I'd MUCH rather have e2fsck say something like:
 172
 173       inode 1234 references an invalid block 134345454. Hmm.
 174       inode 1234 references 567 out of 50176 invalid blocks,
 175                           all near the end. Truncate file to 49152 blocks?
 176
 177    Here you can see that of the 1024 blocks near the end of the file,
 178    only 567 were detected as invalid. However now 48Mb of the file will
 179    be recovered, instead of thrown away.
 180
 181 That's a good point.  Actually, the right thing is for e2fsck to offer
 182 to clear all of the bad blocks in a particular indirect block.  I don't
 183 know how hard it would be to do that, but I'll put it on my e2fsprogs
 184 TODO list.
 185
 186                                                         - Ted
 187
 188 -----------------------------------------------------------------
 189
 190 Debugfs's link command should set the file type information
 191
 192 ---------------------------------------------------------------
 193 From e2fsprogs Debian TODO file as of 1.10-13.
 194
 195 * Maybe make -dbg packages. Look at how others do it.
 196