From owner-freebsd-ports Sat Apr 5 17:40:05 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id RAA14023 for ports-outgoing; Sat, 5 Apr 1997 17:40:05 -0800 (PST) Received: (from gnats@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id RAA13997; Sat, 5 Apr 1997 17:40:02 -0800 (PST) Date: Sat, 5 Apr 1997 17:40:02 -0800 (PST) Message-Id: <199704060140.RAA13997@freefall.freebsd.org> To: freebsd-ports Cc: From: Bruce Evans Subject: Re: ports/3205: Mtools-3.0 fails to WRITE to dos partition under 2.2 (fix supplied) Reply-To: Bruce Evans Sender: owner-ports@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk The following reply was made to PR ports/3205; it has been noted by GNATS. From: Bruce Evans 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