Re: dos filesystem check

[Richard Hirst]

On Tue, Mar 26, 2002 at 04:28:08PM +1100, Andrew Clausen wrote:
> On Mon, Mar 25, 2002 at 11:52:07AM +0000, Richard Hirst wrote:
> > Now that I'm not getting the "you found a bug", I get a further
> > warning on this FAT fs which was created with mkdosfs:
> > 
> > address@hidden:/build/parted/parted-1.4.24.ori# parted -s /dev/sdc check 1
> > Warning: Partition size (64197 sectors) and filesystem size (64196 sectors) 
> > do not match.
> > Warning: File system doesn't have expected sizes for Windows to like it.  
> > Cluster size is 2k (0k expected); number of clusters is 16009 (63666 
> > expected); size of FATs is 63 sectors (249 expected).
> > address@hidden:/build/parted/parted-1.4.24.ori# echo $?
> > 0
> > 
> > Note "(0k expected)",
> 
> Probably 512 bytes rounded to 0k... grrr.  Prolly not worth worrying
> about.
> 
> > and again a return code of 0.
> 
> Likewise, not something serious.
> 
> > In this case the return certainly shouldn't be 0, as the exception
> > wasn't handled.  This is because parted/parted.c:do_check() ignores the
> > return code from ped_file_system_check() and always returns success.
> 
> Well, the exception WAS handled.  Just not by the user.  The raiser
> of the exception saw it wasn't handled, and decided to resolve it
> itself.

Well, it resolved it by returning 0, indicating a problem.  This is
different from 'fs smaller than partition' where the code chooses to
ignore the (non)problem and continue it's checks.

> > As for the return of zero when an EXCEPTION_BUG is reported, it was
> > thrown by fat_check() in this case, so if do_check() had checked the
> > return code, I would have got the non-zero exit code I expected.
> 
> Right.  Subtle difference... here the user wants to know if the
> fs is 100% ok or not.  OTOH, if they just wanted to resize the
> damn thing, they don't really care about these minor issues.

OK, but if fat_check() considers a problem serious enough to return zero
indicating an error, then I would think do_check() should take notice.
Looking at 1.6 source, fat_check() returning 0 appears serious enough to
stop copy and resize operations.

> I dunno, error handling is SOOO hard to get right.  It seems like

No argument there!  

> So, keep arguing / raising these issues (thanks!), just I don't
> think there's a "right" answer... best to pick what works best.

Will do,

Cheers,
  Richard