*Synopsis*: /usr/bin/chksum changed output in snv_128
Due to a change requested by <User 1-5Q-9201>,
<User 1-5Q-9201> is now the responsible engineer for:
CR 6904780 changed on Jan 20 2010 by <User 1-5Q-9201>
=== Field ============ === New Value ============= === Old Value =============
Hook 5 <email address omitted>
Keyword oss-sponsor
Responsible Engineer <User 1-5Q-9201> <User 1-5Q-4707>
====================== =========================== ===========================
*Change Request ID*: 6904780
*Synopsis*: /usr/bin/chksum changed output in snv_128
Product: solaris
Category: utility
Subcategory: file
Type: Defect
Subtype:
Status: 3-Accepted
Substatus:
Priority: 2-High
Introduced In Release:
Introduced In Build:
Responsible Engineer: <User 1-5Q-9201>
Keywords: ksh93, oss-request, oss-sponsor
=== *Description* ============================================================
During SST snv_128(RE) interoperability testing we've found that
/usr/bin/chksum after 6828692 RFE: Update /usr/bin/cksum to AT&T AST "cksum"
produces different output from the former implementation.
snv_127:
bash-4.0$ cd /etc
bash-4.0$ /usr/bin/cksum ./services
1768203470 5572 ./services
snv_128:
bash-4.0# cd /etc/
bash-4.0# /usr/bin/cksum ./services
3405350139 5572 services
leading "./" is stripped.
Although 6828692 states that "it passes the VSC test suite and the usual row of
other tests." There is no warning in case the change in behavior is intentional.
It could break many things very easily e.g. find produces names with leading ./
bash-4.0$ find . -name services -print
./inet/services
./services
./avahi/services
./net/ticlts/services
./net/ticots/services
./net/ticotsord/services
*** (#1 of 1): 2009-11-25 13:59:48 GMT+00:00 <User 1-60DXVZ>
=== *Public Comments* ========================================================
Comments from Roland Mainz:
Keerthi>> Posting Don Cragun's responses to Roland's comments:
1. It looks the AST implementation (AST=="Advanched Software
Technology") is doing a path normalisation here which is AFAIK legal
from a standards point of view... but I ask Don Cragun (POSIX/SUS guru)
about this
Don Cragun: My reading of the standard is that the standard is not clear on
this issue. The standard does not specify how a "file" operand is to be
transformed into a <pathname> in the output file format specification in the
STDOUT section of the description of cksum. My personal belief is that the
intent is that the <pathname> specified in the STDOUT section should match the
"file" operand that is being processed (without normalization). There could
easily be an exception to this in the case where a "file" operand is "-".
If you believe this is important, you need to file an interpretation request
for this issue.
2. Question is whether this hurts or not... I am not sure. We discuss this in
the next project meeting this Friday.
3. Quick fix for this bug __may__ be...
-- snip --
--- a/usr/src/lib/libcmd/common/cksum.c Mon Nov 23 22:09:40 2009 +0100
+++ b/usr/src/lib/libcmd/common/cksum.c Wed Nov 25 20:45:12 2009 +0100
@@ -454,7 +454,7 @@
cmdinit(argc, argv, context, ERROR_CATALOG, ERROR_NOTIFY);
memset(&state, 0, sizeof(state));
setlocale(LC_ALL, "");
- flags = fts_flags() | FTS_TOP | FTS_NOPOSTORDER |
FTS_NOSEEDOTDIR;
+ flags = fts_flags() | FTS_TOP | FTS_NOPOSTORDER ;
state.flags = SUM_SIZE;
state.warn = 1;
logical = 1;
-- snip --
... but this has to be checked twice or three times since my stomach
feeling tells me something is wrong...
4. Just for the log to catch this discussion before it pops-up again:
There was a POSIX bug in the old Solaris implementation of
/usr/bin/cksum which we fixed. Technically you're hitting two issues
here:
1. /usr/bin/cksum (and the ksh93 builtin version of "cksum") now use
<space> instead <tab> to fully conform to POSIX. That issue was clearly
defined in
http://arc.opensolaris.org/caselog/PSARC/2009/249/20090420_roland.mainz.2
Don Cragun: The output format using <tab> instead of <space> fully conformed to
the POSIX, SUS, and SVID3 requirements. Changing the <tab> to a <space> will
also fully conform to the POSIX, SUS, and SVID3 requirements. The specification
of the output format in the STDOUT section of the cksum description in the
standard uses file format notation; not a printf() format specification. Using
file format notation, " " must be replaced by one or more <space> and <tab>
characters in the output. Using file format notation, a single uppercase Greek
delta character would have been used in the output format to indicate that a
single space had to be output instead of one or more <space> and <tab>
characters.
-- snip --
Note that the implementation will take the specified output format
string "%u %d %s\n" <checksum>, <# of octets>, <path name> now
literally, previously implementation used a <tab> instead of
<space> between %u and %d (the POSIX standard allows both <tab>
and <space>, however GNU and BSD implementations use <space> and
no other implementation except Solaris was found which uses
<tab>).
-- snip --
The issue went unnoticed since the POSIX test suite had a bug (and
technically has a "loophole" which - in theory - would allow the use of
<tab> (but noone actually used this except Solaris (and even that
"loophole" was closed for the following POSIX revision, leaving no
choice for us))) but now this is being tested and the old implemetation
will fail.
Don Cragun: There is no loophole and there was no bug in the test suite. The
only change to the description of cksum in the latest revision of the standard
was in the wording specifying whether "-" is allowed to be interpreted as a
synonym for standard input when used as a file operand.
And AFAIK this is not a backwards-compatibity issue since /usr/bin/cksum
was added to match POSIX/SUS certification requirements and has to match
the standard. I discussed that with John Beck and AFAIK C team, too...
and it was ruled that this is a bug and should be fixed (and
backwards-compatiblity does not matter in this case).
Don Cragun: As stated above, the standard allows any combination of one or more
<space> and <tab> characters. The POSIX standard requirements are met by the
old and by the new behavior. PSARC case 2009/249/20090420 documented this
change in behavior and correctly noted in the discussion that either output was
acceptable according to the standard.
*** (#1 of 1): 2009-11-25 20:36:19 GMT+00:00 <User 1-5Q-1267>
*** Last Edit: 2009-12-10 21:31:16 GMT+00:00 <User 1-5Q-4707>
=== *Workaround* =============================================================
Workaround provided by Roland Mainz:
Please use the "cksum" option "-P" to force a "physical view" of the
path:
-- snip --
$ /usr/bin/cksum -P /usr/bin/sparcv9/../ls
375514533 42212 /usr/bin/sparcv9/../ls
-- snip --
We're currently investigating whether the current behaviour is a bug or
standard-conformant (backwards-compatibility only plays a minor role
since "cksum" was invented by the POSIX/SUS people themselves as
_portable_ and _interoperable_ cross-platform hash sum facility and
interoperablity matters more in this case).
Keerthi>>Following is the response from Don Cragun:
Don Cragun: It is true that cksum was a committee invention, but that was over
17 years ago. Interoperability is the major concern, but after 17 years
backwards-compatibility shouldn't be dismissed. (Clearly, any portable
applications depending on cksum output will be happy with any number of <space>
and <tab> characters between the checksum and the number of octet fields in the
output. Therefore, I think the <space> versus <tab> is a non-issue.)
Don Cragun: Matching the <pathname> output field to a file operand is likely to
be much more significant to portable applications.
*** (#1 of 1): 2009-11-25 20:36:19 GMT+00:00 <User 1-5Q-1267>
*** Last Edit: 2009-12-10 21:31:16 GMT+00:00 <User 1-5Q-4707>
=== *Additional Details* =====================================================
Targeted Release: solaris_nevada
Commit To Fix In Build:
Fixed In Build:
Integrated In Build:
Verified In Build:
See Also: 6828692
Duplicate of:
Hooks:
Hook1:
Hook2:
Hook3:
Hook4:
Hook5: <email address omitted>
Hook6: <email address omitted>
Program Management:
Root Cause:
Fix Affects Documentation: No
Fix Affects Localization: No
=== *History* ================================================================
Date Submitted: 2009-11-25 13:59:47 GMT+00:00
Submitted By: <User 1-60DXVZ>
Status Changed Date Updated Updated By
3-Accepted 2009-11-30 19:25:31 GMT+00:00 <User 1-5Q-4707>
=== *Service Request* ========================================================
Impact: Significant
Functionality: Primary
Severity: 2
Product Name: solaris
Product Release: solaris_nevada
Product Build:
Operating System: snv_128
Hardware: generic
Submitted Date: 2009-11-25 13:59:48 GMT+00:00
=== *Multiple Release (MR) Cluster* - 0 ======================================
