From cokane@ramen.cokane.org  Tue May  9 22:31:32 2006
Return-Path: <cokane@ramen.cokane.org>
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP id EB9DB16A404
	for <FreeBSD-gnats-submit@freebsd.org>; Tue,  9 May 2006 22:31:32 +0000 (UTC)
	(envelope-from cokane@ramen.cokane.org)
Received: from smtp3.fuse.net (mail-out3.fuse.net [216.68.8.176])
	by mx1.FreeBSD.org (Postfix) with ESMTP id 62AA143D46
	for <FreeBSD-gnats-submit@freebsd.org>; Tue,  9 May 2006 22:31:32 +0000 (GMT)
	(envelope-from cokane@ramen.cokane.org)
Received: from gx4.fuse.net ([72.49.162.239]) by smtp3.fuse.net
          (InterMail vM.6.01.04.04 201-2131-118-104-20050224) with ESMTP
          id <20060509223129.KFBI12345.smtp3.fuse.net@gx4.fuse.net>
          for <FreeBSD-gnats-submit@freebsd.org>;
          Tue, 9 May 2006 18:31:29 -0400
Received: from ramen.cokane.org ([72.49.162.239]) by gx4.fuse.net
          (InterMail vG.1.02.00.02 201-2136-104-102-20041210) with SMTP
          id <20060509223129.GCHQ14894.gx4.fuse.net@ramen.cokane.org>
          for <FreeBSD-gnats-submit@freebsd.org>;
          Tue, 9 May 2006 18:31:29 -0400
Received: (qmail 73045 invoked by uid 1001); 10 May 2006 06:33:03 -0000
Message-Id: <20060510063303.73044.qmail@ramen.cokane.org>
Date: 10 May 2006 06:33:03 -0000
From: Coleman Kane <cokane@FreeBSD.org>
Reply-To: Coleman Kane <cokane@FreeBSD.org>
To: FreeBSD-gnats-submit@freebsd.org
Cc:
Subject: pax(1): -b option description could be flawed
X-Send-Pr-Version: 3.113
X-GNATS-Notify:

>Number:         97059
>Category:       docs
>Synopsis:       pax(1): -b option description could be flawed
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    cokane
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          doc-bug
>Submitter-Id:   current-users
>Arrival-Date:   Tue May 09 22:40:11 GMT 2006
>Closed-Date:    Fri Feb 29 21:13:42 UTC 2008
>Last-Modified:  Fri Feb 29 21:13:42 UTC 2008
>Originator:     Coleman Kane
>Release:        FreeBSD 6.1-RC i386
>Organization:
FreeBSD
>Environment:
System: FreeBSD ramen.coleyandcheryl 6.1-RC FreeBSD 6.1-RC #3: Tue Apr 18 04:22:25 UTC 2006 root@ramen.coleyandcheryl:/usr/obj/usr/src/sys/RAMEN i386


>Description:
	The pax(1) manpage states the following for the -b flag:
     -b blocksize
           When writing an archive, block the output at a positive decimal
           integer number of bytes per write to the archive file.  The
           blocksize must be a multiple of 512 bytes with a maximum of 64512
           bytes.  Archives larger than 32256 bytes violate the POSIX standard
           and will not be portable to all systems.  A blocksize can end with
           k or b to specify multiplication by 1024 (1K) or 512, respectively.
           A pair of blocksizes can be separated by x to indicate a product.
           A specific archive device may impose additional restrictions on the
           size of blocking it will support.  When blocking is not specified,
           the default blocksize is dependent on the specific archive format
           being used (see the -x option).

        Specifically, the statement:
          Archives larger than 32256 bytes violate the POSIX standard
        
        This could be worded better as:
          Archive block sizes larger than 32256 bytes violate the POSIX
          standard

        This sounds more like what the author might have meant. 

        However, searching around on the internet has yielded 32256 as being
        the enforced maximum by POSIX, while 10240 is described as the 
        "compatibility maximum".
>How-To-Repeat:
	man pax
>Fix:
        Rewrite: 
          "Archives larger than 32256 bytes violate the POSIX standard"
             to say:
    "Archive block sizes larger than 32256 bytes violate the POSIX standard"
>Release-Note:
>Audit-Trail:

From: Giorgos Keramidas <keramida@freebsd.org>
To: Coleman Kane <cokane@freebsd.org>
Cc: bug-followup@freebsd.org
Subject: Re: docs/97059: pax(1): -b option description could be flawed
Date: Wed, 10 May 2006 23:04:14 +0300

 > The pax(1) manpage states the following for the -b flag:
 >
 >   -b blocksize
 >         When writing an archive, block the output at a positive
 >         decimal integer number of bytes per write to the archive
 >         file.  The blocksize must be a multiple of 512 bytes with
 >         a maximum of 64512 bytes.  Archives larger than 32256
 >         bytes violate the POSIX standard and will not be portable
 >         to all systems.  A blocksize can end with k or b to
 >         specify multiplication by 1024 (1K) or 512, respectively.
 >         A pair of blocksizes can be separated by x to indicate a
 >         product.  A specific archive device may impose additional
 >         restrictions on the size of blocking it will support.
 >         When blocking is not specified, the default blocksize is
 >         dependent on the specific archive format being used (see
 >         the -x option).
 >
 >   Specifically, the statement:
 >
 >         Archives larger than 32256 bytes violate the POSIX
 >         standard
 >
 >   This could be worded better as:
 >
 >         Archive block sizes larger than 32256 bytes violate the
 >         POSIX standard
 >
 >   This sounds more like what the author might have meant.
 
 True.  Limiting the _full_ archive size to 32KB is contradictory
 with the previous sentence about 64512 bytes, and would render
 pax(1) pretty useless anyway.
 
 Feel free to make the manpage change, or let me know and I'll do it.
 

From: Coleman Kane <cokane@FreeBSD.org>
To: Giorgos Keramidas <keramida@freebsd.org>
Cc: bug-followup@freebsd.org
Subject: Re: docs/97059: pax(1): -b option description could be flawed
Date: Thu, 11 May 2006 04:22:06 +0000

 On Wed, May 10, 2006 at 11:04:14PM +0300, Giorgos Keramidas wrote, and it was proclaimed:
 > > The pax(1) manpage states the following for the -b flag:
 > >
 > >   -b blocksize
 > >         When writing an archive, block the output at a positive
 > >         decimal integer number of bytes per write to the archive
 > >         file.  The blocksize must be a multiple of 512 bytes with
 > >         a maximum of 64512 bytes.  Archives larger than 32256
 > >         bytes violate the POSIX standard and will not be portable
 > >         to all systems.  A blocksize can end with k or b to
 > >         specify multiplication by 1024 (1K) or 512, respectively.
 > >         A pair of blocksizes can be separated by x to indicate a
 > >         product.  A specific archive device may impose additional
 > >         restrictions on the size of blocking it will support.
 > >         When blocking is not specified, the default blocksize is
 > >         dependent on the specific archive format being used (see
 > >         the -x option).
 > >
 > >   Specifically, the statement:
 > >
 > >         Archives larger than 32256 bytes violate the POSIX
 > >         standard
 > >
 > >   This could be worded better as:
 > >
 > >         Archive block sizes larger than 32256 bytes violate the
 > >         POSIX standard
 > >
 > >   This sounds more like what the author might have meant.
 > 
 > True.  Limiting the _full_ archive size to 32KB is contradictory
 > with the previous sentence about 64512 bytes, and would render
 > pax(1) pretty useless anyway.
 > 
 > Feel free to make the manpage change, or let me know and I'll do it.
 > 
 
 I'll tackle it.
 
State-Changed-From-To: open->patched 
State-Changed-By: keramida 
State-Changed-When: Fri May 12 15:27:08 UTC 2006 
State-Changed-Why:  
This has been fixed in HEAD. 


Responsible-Changed-From-To: freebsd-doc->cokane 
Responsible-Changed-By: keramida 
Responsible-Changed-When: Fri May 12 15:27:08 UTC 2006 
Responsible-Changed-Why:  
Assign this PR in `patched' state to cokane, as an MFC reminder. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=97059 
State-Changed-From-To: patched->closed 
State-Changed-By: cokane 
State-Changed-When: Fri Feb 29 21:13:10 UTC 2008 
State-Changed-Why:  
The change has been MFC'd 

http://www.freebsd.org/cgi/query-pr.cgi?pr=97059 
>Unformatted:
