[mtools] Bug in Mtools-3.9.10 for _unix_loop

[Grant Erickson]

Greetings, I found a bug in mtools-3.9.10 this week that caused a makefile
which incorporated mcopy to silently fail. The general invocation was:

        rm -f C:/cygwin/home/gerickson/build/mtools.conf
        touch C:/cygwin/home/gerickson/build/mtools.conf
        printf "drive a:\n" >> C:/cygwin/home/gerickson/build/mtools.conf
        printf "\tfile=\"C:/cygwin/home/gerickson/build/root.dmg\"\n" >> 
C:/cygwin/home/gerickson/build/mtools.conf
        printf "\tmformat_only=1\n" >> 
C:/cygwin/home/gerickson/build/mtools.conf
        rm -f C:/cygwin/home/gerickson/build/root.dmg
        MTOOLSRC=C:/cygwin/home/gerickson/build/mtools.conf 
C:/cygwin/home/gerickson/build/i686-pc-cygwin/mformat -C -v root -h 16 -s 32 -t 
16 a:
        MTOOLSRC=C:/cygwin/home/gerickson/build/mtools.conf 
C:/cygwin/home/gerickson/build/i686-pc-cygwin/mcopy -v -m -s -Q 
/home/gerickson/build/root a:

The problem ended up being in _unix_loop(). It was set to always return
GET_ONE. So, even if unix_dir_loop() returned ERROR_ONE (possibly ORed in
with other status), the error would be ignored and 0 would always be
returned to the shell. This was disastrous since the disk image creation
failed but the build would silently continue in the face of it.

The following diff makes _unix_loop properly propagate status from
unix_dir_loop and makes mcopy/mtools return proper status to the parent
process (e.g. the shell) when there's an error:

--- mainloop.c.O        2005-09-29 08:57:28.613250000 -0700
+++ mainloop.c  2005-09-28 13:30:06.238250000 -0700
@@ -20,8 +20,7 @@

 static int _unix_loop(Stream_t *Dir, MainParam_t *mp, const char *filename)
 {
-        unix_dir_loop(Dir, mp);
-        return GOT_ONE;
+        return unix_dir_loop(Dir, mp);
 }

 int unix_loop(Stream_t *Stream, MainParam_t *mp, char *arg, int 
follow_dir_link)

Regards,

Grant Erickson
_______________________________________________
mtools mailing list
address@hidden
http://www.tux.org/mailman/listinfo/mtools