Date: Fri, 10 Nov 2000 22:20:32 +0200 From: "Eli Zaretskii" Sender: halo1 AT zahav DOT net DOT il To: ad354 AT FreeNet DOT Carleton DOT CA (James Owens) Message-Id: <8011-Fri10Nov2000222032+0200-eliz@is.elta.co.il> X-Mailer: Emacs 20.6 (via feedmail 8.3.emacs20_6 I) and Blat ver 1.8.6 CC: djgpp AT delorie DOT com In-reply-to: <8uhepu$kk5$1@freenet9.carleton.ca> (ad354@FreeNet.Carleton.CA) Subject: Re: InfoZIP vol label: force it, but please advise References: <8ubi1t$j7k$1 AT freenet9 DOT carleton DOT ca> <1659-Wed08Nov2000195636+0200-eliz AT is DOT elta DOT co DOT il> <8uc9gb$mvn$1 AT freenet9 DOT carleton DOT ca> <9003-Thu09Nov2000002038+0200-eliz AT is DOT elta DOT co DOT il> <8uee2v$1v7$1 AT freenet9 DOT carleton DOT ca> <2110-Thu09Nov2000195846+0200-eliz AT is DOT elta DOT co DOT il> <8uhepu$kk5$1 AT freenet9 DOT carleton DOT ca> Reply-To: djgpp AT delorie DOT com Errors-To: nobody AT delorie DOT com X-Mailing-List: djgpp AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk > From: ad354 AT FreeNet DOT Carleton DOT CA (James Owens) > Newsgroups: comp.os.msdos.djgpp > Date: 10 Nov 2000 18:29:18 GMT > > #if (!defined(__GO32__) && !defined(__EMX__)) > > ... > > /**************************/ > /* Function volumelabel() */ > /**************************/ > > static int volumelabel(newlabel) > char *newlabel; > ... > > (I'm still not sure how this is excluded from the DJGPP compile.) DJGPP defines __GO32__, that's why the above gets excluded. > static int volumelabel(char *name) > { > int fd; > return _dos_creat(name, FA_LABEL, &fd) ? fd : _dos_close(fd); > } > ... > > A printf inserted here shows up. If the DJGPP version calls _dos_creat to create a label, it looks like a small wonder that it fails when there's already a label on the disk, right? You could try rewriting the code which uses intdosx like I suggested in my previous message; perhaps calling function 17h is the solution, and whoever used _dos_creat simply didn't know how to call such functions from a DJGPP program? > I was also puzzled by the __GO32__ condition for the > function, rather than the DJGPP condition I was expecting. It probably got left over from early DJGPP versions. The symbol __DJGPP__ was only added in DJGPP v2.0.