Subject: Pine/other/disk space (fwd)

From: Mike Roch <[email-masked]>
Date: Thu, 1 Apr 1993 12:29:58 +0100 (BST)

One of my colleagues has noticed a glich:-

> Does pine have a bug in the section where its offers to report on disk
> space used and available.  The used bit seems OK but 'available' always
> seems to report 0bytes? Am sure it's not urgent but may be easily fixed by
> a tweek in the installation, perhaps.

   Number of folders:                                     81
   Space used by mail folders:                     2,739,358 characters
								(2.7Mb)
   Free space available for mail on disk drive:         0 characters (0 bytes)
   Mail directory:          /home/sunserv/ru/su/suqroch/mail

Is this a bug in Pine or a problem with the way we've installed it? Does
the free space refer to the system mailbox, or the user's mail folder
partition?

We're not using imap; we have ~100 Suns that NFS mount a mail directory
(and it's not [often] full)!

Filesystem            kbytes    used   avail capacity  Mounted on
suma1:/var/spool/mail
                       99724   80357    9394    90%    /var/spool/mail

My folders live where hers do;

Filesystem            kbytes    used   avail capacity  Mounted on
sunserv:/home/sunserv/ru
                      108091   94155    3126    97%    /home/sunserv/ru

Mike

==============================================================================
Mike Roch, Computer Services Centre,                          Tel: 0734 318430
The University, Whiteknights, Reading, RG6 2AX.               Fax: 0734 753094

---

From: Laurence Lundblade <[email-masked]>
Date: Thu, 1 Apr 1993 07:55:59 -0500 (EST)

It probably should be classified as a bug in Pine. UNIX systems provide
system calls to figure out the space used in a directory, but they don't
provide system calls to get the amount of space available in a file
system. 

What Pine does to retrieve this value is run the "df" command and pick
apart the output. If the "df" command is not located in the right place or
the format doesn't match what Pine is expecting it'll get confused and
report the wrong value. There's a number of formats of "df" output on
different systems and vendors don't think twice about changing it.

What probably needs to be done is to tweek the code that runs and parses
the "df" output for suns, or at least your suns. (Maybe a different
version of SunOS?) If it's Pine 3.05 I think the code should be correct
for the some suns. 

LL

---

From: Barry Cornelius <[email-masked]>
Date: Thu, 1 Apr 1993 12:57:16 +0000 (GMT)

On Thu, 1 Apr 1993, Mike Roch wrote:

> > seems to report 0bytes? ...
> ... My folders live where hers do;
> 

Choosing "o" for "other" from the main menu followed by "d" for "disk"
will sometimes give the free space available on the disk drive as 0 bytes. 
This will happen if the name of the Filesystem is long, say, more than
about 17 characters.  In such situations, the output produced by df
(or bdf) straddles two lines.

The code (in both Versions 3.05 and 3.07 of pine) assumes that this output is 
all on one line.  The lines:
   /* Skip the filesystem */
   p = buf;
   for(;*p != ' '; p++);
can be replaced by:
   /* Skip the filesystem */
   p = buf;
   for(;*p != ' ' && *p != '\0'; p++);
   /* *p == ' ' || *p == '\0' */
   if (*p == '\0') {
     if(fgets(buf, sizeof(buf), df_s) == NULL)
       return(-2);
       p = buf;
   }

--
Barry Cornelius            Electronic mail: [email-masked]
Post:  Computing Service, University of Durham, Durham, DH1 3LE, England
Phone: Durham (091 or +44 91) 374 4717, Secretary:374 2892, Fax:374 3741

---

From: Gordon Good <[email-masked]>
Date: Thu, 01 Apr 93 08:25:34 -0500

>provide system calls to get the amount of space available in a file

Why wouldn't statfs(2) work?  Seems like a more standard way of doing things
than expecting df output to be the same across vendors.

-Gordon

---

From: Laurence Lundblade <[email-masked]>
Date: Thu, 1 Apr 1993 11:08:55 -0500 (EST)

> than expecting df output to be the same across vendors.

You're right this is the best solution and will hopefully get on the to do
list. 

I think this was a somewhat recent addition to UNIX systems (it wasn't in
4.1BSD when I learned all the system calls). It's also not on all systems
so some of the current code needs to be retained.

I think Barry's solution will also solve the problem.

LL

---

From: "David L. Miller" <[email-masked]>
Date: Thu, 1 Apr 1993 12:29:38 -0800 (PST)

It should be a pretty easy fix as well.  That code is already in the
system-dependant modules (os-unx.c) so the change should be pretty easy, and
transparent to other systems...

*****************************************************************************
David L. Miller                       Internet: [email-masked]
Systems Programmer/Network Analyst      BITNET: MILLERD@WSUVM1
Washington State University Tri-Cities    UUCP: ...!yoda!dmiller
100 Sprout Road                          
Richland, WA 99352                       Phone: (509)375-9245
*****************************************************************************