|
From: Szakacsits S. <sz...@si...> - 2004-03-05 16:24:54
|
On Sat, 28 Feb 2004, Anton Altaparmakov wrote:
> > 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.
>
> That is not a showstopper for a stable release IMO.
True but let me explain why I think it's important.
Currently presenting an "error" is very cumbersome for external tools.
Thus they often skip it completely and just say e.g. something like
"Error: resize failed". What are the most popular reasons for the error?
- inconsistent NTFS -> user must run 'chkdsk /f'
- bad sectors -> still unsupported but user might get a
clue and disk replacement
People are confused by the "Error: resize failed" messages (what actually
happend?) and when they communicate the unclear message, others may make
the incorrect conclusion that the fs was trashed.
Exit codes carry a strict meaning and they can be presented in whatever
wording in whatever language by any external tool.
> > 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?
>
> I suggest stable release sooner rather than later. Remember: release
> often is the secret to success. (-:
I know very well, this is why I asked :)
> I would suggest to either implement the $BITMAP saving
I'm afraid I don't have the needed time for that right now.
> OR to bolt a big fat warning when ntfsresize aborts saying something
> like: WARNING! WARNING! WARNING! You MUST let Windows chkdsk test and
> repair this partition as it has been left in an inconsistent state!
> Do not attempt to write anything to this partition until it has been
> repaired by chkdsk! Failure to do so will result in total loss of all
> data on the partition in the worst case! You have been warned.
Seems to be unneeded. If user boots Windows then it's unavoidable. If they
want to run ntfsresize or ntfsclone then any action will be refused if the
fs is inconsistent even by using the --force option. And at present I
can't see any other way to damage or lose data using Windows or released
Linux-NTFS tools.
> Whatever you decide just let me know when you are ready and I will make
> the release.
I'd also like a stable release ASAP but I'm not sure I have the needed
free time at present to finish everything what I originally planned.
That's why I'm looking for safe shortcuts.
Szaka
|
