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>