Some of my customers have run into a problem when upgrading from 4.0 to 5.0.
 
Previously accessible files in their accounts are inaccessible due to
security restrictions after the upgrade.
 
The inaccessible files were all originally :Store'd on a 5.0 system, tape
then :Restore'd with the Account= option on a 4.0 system.
 
The GUID field in a reserved portion of the file label was incorrectly
set to the ORIGINAL account name during the restore, not to the new
account name from the Account= option.  A similiar restore on a 5.0
system will correctly set the GUID (now, an implemented field, not a
reserved field as it was on 4.0).
 
Because the GUID (reserved) field is ignored on 4.0, access is allowed as
per the usual security.
 
However, upon upgrading from 4.0 to 5.0, all such files are now
inaccessible due to a difference between the accessor's GID and the file's.
 
There are two work-arounds as suggested by the response center:
 
One is to :store/purge/:restore all of the files with an Account= after
the conversion to 5.0 (IMHO, time consuming, dangerous).
 
The second is to :Listfile @.@,6 to a disc file, read the file and do an
:Altfile filename;Group=accountname to change the GID for each file.
 
The opinion of the Lab (as relayed through the Response Center) was that
this IS NOT A DEFECT. (IHMO, it is a major design defect).
 
Due to the limited (approx 1 year) support life left on 4.0, they would
not file an SR to fix the problem, nor would they, or the Response
Center, file an SR for visibility saying that a 5.0->4.0 Account= restore
is rare and would likely not affect many people.
 
So, THIRD PARTY SOFTWARE SUPPLIERS BEWARE, if you cut your tapes on 5.0
and send them to 4.0 or earlier clients and they use an Account= restore
option, they WILL run into this problem.
 
This is also a concern to those of you with multi-OS version shops, do
your development on 5.0, send it back with Account= (to go from the
development or release account to production account) and later upgrade
those 4.0 or earlier systems.
 
I will be submitting a written SR (along with complaints about their lack
of concern).  Once I receive the SR#, I will post it here so that those
of you who feel this problem should be addressed, can reference that SR#
when submitting your own SR.
 
 
Rick Gilligan
Sr. Software Engineer
Computer And Software Enterprises, Inc.
 
 
E-mail to: [log in to unmask]