Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 5 Apr 1997 17:40:02 -0800 (PST)
From:      Bruce Evans <bde@zeta.org.au>
To:        freebsd-ports
Subject:   Re: ports/3205: Mtools-3.0 fails to WRITE to dos partition under 2.2 (fix supplied)
Message-ID:  <199704060140.RAA13997@freefall.freebsd.org>

next in thread | raw e-mail | index | archive | help
The following reply was made to PR ports/3205; it has been noted by GNATS.

From: Bruce Evans <bde@zeta.org.au>
To: FreeBSD-gnats-submit@FreeBSD.org, mmcg@heraclitus.cs.monash.edu.au
Cc:  Subject: Re: ports/3205: Mtools-3.0 fails to WRITE to dos partition under 2.2 (fix supplied)
Date: Sun, 6 Apr 1997 11:26:48 +1000

 >On examination, it turns out that rather than using perror(),
 >the mtools source uses the following logic:
 >
 >If flock(device) fails
 >	and it's EINVAL
 >		Then assume we don't need to lock the device
 >	otherwise
 >		print `device busy'
 >
 >FreeBSD doesn't return EINVAL for this purpose - it uses EOPNOTSUPP.
 
 Perhaps mtools is "right".  POSIX.1 specifies EINVAL for unsupported
 fcntl() locks, but the FreeBSD file systems return all lots of different
 error numbers for it - often EOPNOTSUPP and sometimes EBADF as well as
 EINVAL.  I fixed fcntl() for a couple of file systems but tried not to
 change fclock().  EOPNOTSUPP is actually documented for flock(), but it
 is easy to interpret the docs as saying that EOPNOTSUPP never occurs:
 
     EBADF:  fd is an invalid descriptor
     EINVAL: fd refers to an object that is not a file
     EOPNOTSUPP: fd refers to an object that does not support file locking
 
 I don't know what a file is ;-), but (non-special) files should support
 file locking by definition.
 
 Bruce



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199704060140.RAA13997>