Re: dos filesystem check

[Andrew Clausen]

On Mon, Mar 25, 2002 at 11:52:07AM +0000, Richard Hirst wrote:
> On Sat, Mar 23, 2002 at 10:15:36AM +1100, Andrew Clausen wrote:
> > Definitely a bug in mkdosfs... MS s/w might corrupt/misinterpret
> > the mkdosfs file system.
> 
> So parted should not ignore it in script mode, as it does now?

No.  It's not something that will cause Parted problems.  If
Parted does an operation on the file system, it will even fix
it for free :)

> > > Also, having decided there is a bug, parted really shouldn't exit with
> > > code 0.
> > 
> > Weird... it should!  Could you please debug this?  I can't reproduce
> > (easily).  If it's too much trouble for you, I can investigate.
> 
> I asume you mean it shouldn't exit with code 0...

Right

> Looking at exit codes in general though, still on parted 1.4:
> 
> parted/parted.c:_init()
> 
> 3 of the "goto error" should be "goto error_done_ui", I think.

Thanks.  This had been fixed in 1.6, so I am improving... ;)

> parted/parted.c:main()
> 
> "if (!dev)" needs to return non-zero so if you pass a bad device
> name to parted in a script, the script can tell.

Right.  I've already fixed that in my tree, which I should
release...

> When an exception is thrown for my partition size / filesystem size
> mismatch, it has Ignore and Cancel options.
> For script mode parted/ui.c:exception_handler() will return
> PED_EXCEPTION_UNHANDLED.  fat_boot_sector_analyse() will see that the
> geom is bigger than the filesystem and decide it isn't a problem.

It isn't a problem.

> Hence the exit code of 0.  Guess that might be ok; seems a bit odd to
> issue a warning and then ignore it anyway in script mode.

Well, it's a warning that isn't a big deal.  OTOH, if the fs is
BIGGER than it's geom, THAT's a big deal and it will complain.

> 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.

> 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.

I dunno, error handling is SOOO hard to get right.  It seems like
an AI complete problem.  (i.e. it's always contentious as to what
the right solution is.  i.e. there's no Right Thing TM to do, as there
usually is in other things...).

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

Thanks,
Andrew