*Synopsis*: /usr/bin/chksum changed output in snv_128
Due to a change requested by <User 1-5Q-4707>,
<User 1-5Q-4707> is now the responsible engineer for:
CR 6904780 changed on Nov 30 2009 by <User 1-5Q-4707>
=== Field ============ === New Value ============= === Old Value =============
Responsible Engineer <User 1-5Q-4707>
Status 3-Accepted 1-Dispatched
====================== =========================== ===========================
*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-4707>
Keywords: ksh93
=== *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:
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
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
-- 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.
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).
*** (#1 of 1): 2009-11-25 20:36:19 GMT+00:00 <User 1-5Q-1267>
=== *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).
*** (#1 of 1): 2009-11-25 20:36:19 GMT+00:00 <User 1-5Q-1267>
=== *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:
Hook6:
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 ======================================
