REPORT ON GTAR FAILURE
Author: Dave Allen     Date: Dec 14,2006


RELEASE PROBLEM DUE TO GTAR FAILURE:

Recently there was a problem doing an UPDATE release to Munich because the
untar in Munich using GTAR generated two bad links.

It is wise for any sys-admins and/or support developers to know this.

I will try to look for info on Google about gtar failures and I would
appreciate any help from sys-admins if you have heard of problems with
tar or gtar before.

If there is some one the sys-admins know to contact that would be good also.

Some facts about our use of tar/gtar: 

1) All cron jobs doing the nightly Mentor library transfers to Munich and
   Shanghai, (6 nights a week), use tar and gzip on the HP server bu980a0

   In addition to the nightly transfers for current library there is a 
   once-a-week transfer for the older rlslib_C2.

   I know of only one suspected failure with this over 7 years or so, for
   transfers to Elk Grove/Munich, and no known failures for the time it
   has been used for Shanghai. 

2) The design-transfers (design_xfer) between sites uses GTAR and gzip.

   Most designs now will have only 10-50 links perhaps under the design_geom
   and these are supposed to be purged or go away with time..  There is
   generally one other link under design_maps.

   I know of no recorded failure due to an untar.

3) Another note about current operation would be that Tinh Do and
   I worked, (together with Terry Lian), to get an updated gtar in Deerpark
   and Shanghai so as to allow tar files greater than 2 gig.

   All three sites now show a version of gtar of 1.15.1

4) I have saved the BAD copy of the gui directory in Munich at 
   /apps/elec/mentor/gui_BAD_links
   and the two bad links are under the sub-directory at 
   /apps/elec/mentor/gui_BAD_links/batch

   The possibly-bad tar file is at
   /apps/elec/mentor/d_untar/gui.tar_gave_bad_links
   
   It could have been a system glitch as I cant reproduce.
   See more details below.

5) The same exact gui.tar.gz file sent to Shanghai caused no such 
   problem, and when I repeat the untar in Munich I do not get those
   two bad links.

   The exact command I always use for an untar is:
   KSH> gunzip gui.tar.gz
        followed by 
   KSH> gtar -xf gui.tar

6) The five extra characters added to the links were 'ustar'.  Is it
   possible this means us-tar (or US-tar) and refers to localization??
   Wild guess..

7) SUN version in Munich on server zwg18srv01

   zwg18srv01> uname -a
   SunOS zwg18srv01 5.9 Generic_112233-12 sun4u sparc SUNW,Sun-Fire-V440
   
   gtar version is 1.15.1



UNTAR USING GTAR MADE TWO BAD LINKS:

## Doing an untar for a critical directory transferred to Munich resulted
## in two bad links under the /apps/elec/mentor/gui/batch directory.

## These caused Doug Low's problem with the Conti border update for 
## the drawings in a fablink session.

## I am going to CC sys-admins at all three SITES on this.
## Does any sys-admin with your vast knowledge and experience with
## any Unix anomalies know or have heard of gtar failures? 

## If you cant TRUST a gtar - then how can someone reliably do backups??
## Perhaps commercial backup systems dont trust tar and do by other means..  

## I can remember Farzad Omaraie warning about tar/gtar in a group 
## discussion on backup strategies in Northbrook a long time ago.

## The Munich site were unlucky enough that out of 400 or so files 
## and links under just one sub-directory mentor/gui there were two bad
## bad links that appeared out of the untar.

## This represents the first case of a tar.gz failure that I have
## seen in about five years or so. 

## The /apps/elec/mentor/gui/batch
## - is quite large
## - has many LONG links that point to about 70% of the scripts and
##   perl and binaries/exe's that we use..
## This directory wound up with at least TWO bad links that I can see
## after I did gunzip and gtar -xf 
## on the gui.tar.gz that I ftp'd from Deerpark to Munich.

## I know many years ago Unix tar had problems with LONG LINKS.
## I am VERY disappointed to see this in a GTAR especially after I and 
## the sys-admin Tinh Do here spent time to actually upgrade the gtar on
## our SUN server il106ee1.. to bring it in line with the gtar at
## Munich and Shanghai.


INFO THAT I FOUND:

## On Deerpark SUN server..

il106ee1> uname -a
SunOS il106ee1 5.8 Generic_117350-29 sun4u sparc SUNW,Sun-Fire-480R

il106ee1> gtar --version
tar (GNU tar) 1.15.1


## On Munich SUN server..

zwg18srv01> uname -a
SunOS zwg18srv01 5.9 Generic_112233-12 sun4u sparc SUNW,Sun-Fire-V440

zwg18srv01> gtar --version
tar (GNU tar) 1.15.1



## There are TWO links under the gui/batch directory that wuold up with 
## some extra characters at the end of the path.

zwg18srv01> pwd
/apps/elec/mentor/gui/batch

zwg18srv01> ls -dl * | grep star

### TWO BAD LINKS HERE.  NOT_AT Deerpark and NOT_IN Shanghai which got same gui.tar.gz as Munich

lrwxrwxrwx   1 g12112   users  107 Dec 11 03:09 do_lsxlR_for_veritas_restore.prl 
 -> /apps/elec/mentor/idea.common/d_tools/d_pcb_tools/d_veritas_restore/do_lsxlR_for_veritas_restore.prlustar  
lrwxrwxrwx   1 g12112   users  107 Dec 11 03:09 do_upd_formats_conti_in_design.ksh 
 -> /apps/elec/mentor/idea.common/d_tools/d_pcb_utils/d_CONTI_updates/do_upd_formats_conti_in_design.kshustar  

### Other links are fine.

lrwxrwxrwx  1 g12112   users    67 Dec 11 03:09 start_ee_cron_jobs 
 -> /apps/elec/mentor/idea.common/d_tools/d_cron/start_ee_cron_jobs.ksh
zwg18srv01> 


Regards,
Dave Allen
Mentor Support