lucio@flagship.UUCP (Lucio) (11/10/89)
In sendbatch there is a test for the amount of free space available on the device containing the spool directory. On my machine the test should read: df /usr/spool but in this form it fails because, as df reports: df: /usr/spool not block special Whereas Xenix therefore seems to expect a special device (it says so in the manual pages), it seems that most other ports, including the MKS tools, are happy with a directory and determine the device that contains the given directory. Has this problem (?) been rectified in Xenix 2.3 and SCO Unix V.3.* and, if not in 2.3, has anybody a workaround? A technique (I presume the real df does this) to translate a directory name with the containing device seems a reasonable solution. Thanks, netfolks. ---------------------------------------------------------------------- Lucio de Re ...uunet!ddsw1!olsa99!flagship!lucio -------------------- plan to throw THIS one away -------lucio@flagship
bill@netagw.uu.net (Bill Aten) (11/14/89)
In article <228@flagship.UUCP> lucio@flagship.UUCP (Lucio) writes: >In sendbatch there is a test for the amount of free space available >on the device containing the spool directory. On my machine the test >should read: > > df /usr/spool > >but in this form it fails because, as df reports: > > df: /usr/spool not block special > The key here is the word DEVICE not DIRECTORY. When you issue the command 'df' from the prompt you will probably see '/' and '/u' devices listed. Depending on how you set up Xenix, you may see a '/usr' device. These are your filesystems and this is what sendbatch is trying to check. In the example you gave, sendbatch should either be looking at '/' or '/usr', depending on your setup. The fact that 'usr/spool' is part of '/' (or possibly 'spool' is part of '/usr') doesn't matter. When the '/' (or '/usr') device is full -- it's full. And that is what sendbatch is checking for. Hope this helps... -- ============================================================================= Bill Aten | Internet: bill@netagw.uu.net UUCP: ...!uunet!netagw!bill | Compuserve: 70270.451@compuserve.com =============================================================================
asp@puck.UUCP (Andy Puchrik) (11/16/89)
In article <251@netagw.uu.net>, bill@netagw.uu.net (Bill Aten) writes: > In article <228@flagship.UUCP> lucio@flagship.UUCP (Lucio) writes: delete..delete..delete... On a typical system things go under /usr/spool/uucp so the sendbatch script needs: SPOOLDISK=/dev/root -- Andy Puchrik Moonlight Systems ...!decuac!necntc!necis!puck!asp Concord, MA 01742 asp@puck.UUCP
perry@ccssrv.UUCP (Perry Hutchison) (11/17/89)
In article <228@flagship.UUCP> lucio@flagship.UUCP (Lucio) writes:
+ In sendbatch there is a test for the amount of free space available ...
+ On my machine the test should read:
+
+ df /usr/spool
+
+ [to which] df reports:
+
+ df: /usr/spool not block special
This may be a BSD vs Sys5 problem. In SunOS 3.5 (based on 4.2 BSD) you can
provide a directory name and df will figure out the proper device. Isn't
Xenix a Sys5 derivative?
Clearly the workaround is to change the df call to specify the proper device.ag@amix.commodore.com (Keith Gabryelski) (11/18/89)
In article <845@ccssrv.UUCP> perry@ccssrv.UUCP (Perry Hutchison) writes: >In SunOS 3.5 (based on 4.2 BSD) you can provide a directory name and df >will figure out the proper device. There is a bug in SysVR3 that will not allow one to use a relative path as an argument to df [devnm() does a chdir() to search the /dev directory for devices but never chdir()s back]. This code has propagated itself to SysVR4-k15. It may be fix in later k-loads. Pax, Keith Ps, you can specify absolute path names to df in SysVR3 with no ill effects. -- ag@amix.commodore.com Keith Gabryelski ...!cbmvax!amix!ag