Re: Bug#28618: efax uses binary lockfiles
You can't be serious! Lockfiles are useless unless everybody uses the same
format!
At least minicom, mgetty, and wvdial all use ASCII lockfiles in Debian. I'm
sure there are others (uucp), but I don't use them. If you write a shell
script to lock the modem, the only way it'll work is to use an ASCII lock
file. fsstnd says you should do it, even if policy doesn't _quite_ say that
you have to comply, probably accidentally.
What on earth is the point of arbitrary non-fsstnd compliance when you just
have to change the program's default behaviour?
Sorry if I sound rude, but I just can't believe I'm hearing this. I was
sure this was a simple oversight on the part of the efax maintainer.
Avery
On Wed, Oct 28, 1998 at 01:02:14AM +0100, Wichert Akkerman wrote:
> Previously Avery Pennarun wrote:
> > I just noticed that the Debian efax package generates binary lockfiles in
> > /var/lock. That is, it includes the 4-byte representation of an integer
> > rather than its ASCII representation, and thus is incompatible with other
> > Debian software.
>
> Actually the fsstd, section 5.5 has this to say about this:
>
> The format used for Linux device lock files should be the HDB UUCP lock
> file format. The HDB format is to store the process identifier (PID) as
> a ten byte ASCII decimal number, with a trailing newline. For example,
> if process 1230 holds a lock file, it would contain the eleven
> characters: space, space, space, space, space, space, one, two, three,
> zero, and newline.
>
> But the policy says in section 3.1.1:
>
> The location of all installed files and directories must comply fully
> with the Linux Filesystem Structure (FSSTND).
>
> So only file location must be conformant, and not the format for the
> lock files.
>
> Wichert.
Reply to: