On Thu, 26 Feb 2004, Anton Altaparmakov wrote:
> Yes, we could really, really do with a fully featured ntfsfsk utility in
> ntfsprogs. It wouldn't even need to fix anything, just report errors...
> Unfortunately noone's ever written one. )-:
I use this over a year
% alias ntfsck="ntfsresize -fi"
Exit value is 0 if NTFS is OK and 1 otherwise, reporting what was the
problem.
It found _many_ problems during development, in libntfs, RAM problems, IDE
cable problem, etc.
I'm planning to make the consistency check part of ntfsresize to be a
function because I'd like resizing this way in the future.
consistency check
resize
consistency check
But I have a dilemma at present to proceed.
There is a high demand for a stable resizer with the relocation support.
Current ntfsresize 1.9-BETA is stable, still no error was reported over
the last 3 months. The things needed to be added are
- support the very rare cases left
- make code usable for others as functions
Both of the aboves need heavier changes and although they aren't really in
functionality but they are error-prone. I'm afraid it could just
invalidate the last 3 months successful testing phase.
What's missing to be released as stable? Well, mostly
1) discriminated exit codes thus tools using it would know
what to do or report to users without parsing the ntfsresize
output.
2) if an on-going resize fails for some reason then the modified
$BITMAP won't be saved. This isn't very healthy but
a) users and integrators are always adviced to make an
explicite resize test run. If that succeds then the
real resize must succeed also. So they can end up in this
situation only if they don't follow the advice.
b) if they ignored the documents/advices and ended up in
this situation then the scheduled chkdsk should be able
to correct $BITMAP. In my experience, it was always able
to do it correctly.
My question is what way to proceed? Focus/make a stable release before
heavier changes? If yes then should I implement the $BITMAP saving for
that release?
Szaka
|