4 Before it's non-embarrassingly releasable:
6 - sort out the command line syntax
7 * I think there should be a unified --mode / -M for every
8 running mode, possibly without the one-letter option for the
9 diagnostic sorts of things
10 * there should be some configurable options:
11 + range limits on the age display
12 + server address in httpd mode
13 + HTTP authentication: specify username and/or password, the
14 latter by at least some means which doesn't involve it
17 - work out what to do about atimes on directories in the absence of
18 the Linux syscall magic
19 * one option is to read them during the scan and reinstate them
20 after each recursion pop. Race-condition prone.
21 * marking them in a distinctive colour in the reports is another
23 * a third option is simply to ignore space taken up by
24 directories in the first place; inaccurate but terribly simple.
25 * incidentally, sometimes open(...,O_NOATIME) will fail, and
26 then we have to fall back to ordinary open. Be prepared to do
27 this, which probably means getting rid of the icky macro
28 hackery in du.c and turning it into a more sensible run-time
31 - make a final decision on the name!
33 - man page, licence, online help.
37 - run-time configuration in the HTTP server
38 * I think this probably works by having a configuration form, or
39 a link pointing to one, somewhere on the report page. If you
40 want to reconfigure anything, you fill in and submit the form;
41 the web server receives HTTP GET with parameters and a
42 referer, adjusts its internal configuration, and returns an
43 HTTP redirect back to the referring page - which it then
44 re-renders in accordance with the change.
45 * All the same options should have their starting states
46 configurable on the command line too.
48 - polish the plain-text output:
49 + do the same formatting as in HTML, by showing files as a
50 single unit and also sorting by size? (Probably the other way
51 up, due to scrolling.)
52 + configurable recursive output depth
54 - curses-ish equivalent of the web output
55 + try using xterm 256-colour mode. Can (n)curses handle that? If
56 not, try doing it manually.
59 + figure out what to do about scans starting in the root
61 * Currently we end up with a double leading slash on the
62 pathnames, which is ugly, and we also get a zero-length
63 href in between those slashes which means the web interface
64 doesn't let you click back up to the top level at all.
65 * One big problem here is that a lot of the code assumes that
66 you can find the extent of a pathname by searching for
67 "foo" and "foo^A", trusting that anything inside the
68 directory will begin "foo/". So I'd need to consistently
69 fix this everywhere so that a trailing slash is disregarded
70 while doing it, but not actually removed.
71 * The text output gets it all wrong.
72 * The HTML output is fiddly even at the design stage: where
73 would I _ideally_ put the link to click on to get back to
76 - more flexible running modes
77 + decouple the disk scan from the index building code, so that
78 the former can optionally output in the same format as --dump
79 and the latter can optionally work from input on stdin (having
80 also fixed the --dump format in the process so it's perfectly
81 general). Then we could scan on one machine and transfer the
82 results over the net to another machine where they'd be
83 indexed; in particular, this way the indexing machine could be
84 64-bit even if the machine owning the filesystems was only 32.
85 + in the other direction, ability to build a database _and_
86 immediately run one of the ongoing interactive report modes
87 (httpd, curses) in a single invocation would seem handy.
92 * configure use of stat64
93 * configure use of /proc/net/tcp
94 * configure use of /dev/random
95 * configure use of Linux syscall magic replacing readdir
96 + later glibcs have fdopendir, hooray! So we can use that
97 too, if it's available and O_NOATIME is too.
98 * what do we do elsewhere about _GNU_SOURCE?
99 + http://msdn.microsoft.com/en-us/library/ms724290.aspx suggest
100 modern Windowses support atime-equivalents, so a Windows port
101 is possible in principle. Would need to modify the current
102 structure a lot, to abstract away (at least) memory-mapping of
103 files, details of disk scan procedure, networking for httpd,
104 the path separator character (yuck). Unclear what the right UI
105 would be on Windows, too; command-line exactly as now might be
106 considered just a _little_ unfriendly. Or perhaps not.
~mdw / sgt / agedu / blob