home *** CD-ROM | disk | FTP | other *** search
- Newsgroups: comp.os.linux
- Path: sparky!uunet!uunet.ca!xenitec!mongrel!shrdlu!gdm
- From: gdm@shrdlu.kwnet.on.ca (Giles D Malet)
- Subject: Re: UUGETTY & Lock files...
- References: <1993Jan3.061828.27179@exucom.com> <C0EFGJ.706@jti.com>
- Organization: 3.141592653589793238462643383279502884197169399
- Date: Thu, 7 Jan 1993 16:45:53 GMT
- Message-ID: <C0Ht8H.tuI@shrdlu.kwnet.on.ca>
- Lines: 27
-
- In article <C0EFGJ.706@jti.com> richb@jti.com (Richard Braun) writes:
- >
- >My version of kermit uses binary PIDs so I had to change
- >and recompile uugetty to do likewise.
-
- A word of warning - the binary version of kermit doing the rounds is
- `wrong' in using binary PID's. I say `wrong' because all software has
- to agree on a format, and since the dark ages kermit has used straight
- ascii. uucp, uugetty, and various other programs all use ascii as well.
-
- You should be fixing kermit, and now your uugetty, else the following can
- happen : uucp starts using the line and writes an ascii lock. You fire
- up kermit, it reads the lock as binary, gets a PID about 15digits long,
- can't find that process, assumes it is dead, removes the lock and also
- tries to grab the line.... Next cron fires off a uucico which reads the
- binary file as ascii, ..... and grabs the line. Next uugetty wakes up,
- looks around... and grabs the line.
- I'll stop now - I'm breaking out in a cold sweat.
-
- Also, ascii lock numbers are easliy readable by scripts and humans.
-
- This is going to cause problems and more volume in the newsgroup if that
- kermit is not fixed !
-
- --
- Giles D Malet gdm@shrdlu.kwnet.on.ca
- Waterloo, Ont, Canada +1 519 725 5726 gdmalet@descartes.uwaterloo.ca
-