>Number:         26148
>Category:       bin
>Synopsis:       tar(1) issues, inconsistencies with GNU tar
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    bin-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sat Jul 03 01:26:00 UTC 2004
>Closed-Date:
>Last-Modified:
>Originator:     Matthew Mondor
>Release:        NetBSD 2.0_BETA
>Organization:
>Environment:
NetBSD ginseng.xisop 2.0_BETA NetBSD 2.0_BETA (GINSENG) #0: Sat Jun 26 09:56:57 EDT 2004  root@ginseng.xisop:/home/src/sys/arch/i386/compile/GINSENG i386

>Description:
tar(1) now requires an -h flag to allow following symbolic links. This means that by default, if one has for instance a symlink set to point /usr/src to /home/src directory, unpacking a source tarball will cause the symbolic link /usr/src to be overwritten by an /usr/src directory (causing the /usr filesystem to be filled instead of /home in this case).
This is also true for sysinst where upgrading a system will overwrite symbolic links which may have been set, and cause unexpected results.
Shouldn't this mode (-h) be the default, and we could provide a flag to not follow symbolic links?

I also noticed another problem where third party scripts (including in some pkgsrc packages, notably openoffice), are using tar and piping the result into gzip, generating an error (I yet need to check if this is because of gzip or tar however).
>How-To-Repeat:
Notice that your /usr is full enough and that you need pkgsrc and src moved to /data/src and /data/pkgsrc. Create symlinks /usr/src and /usr/pkgsrc pointing to /data/src and /data/pkgsrc, respectively. Extract pkgsrc.tgz or syssrc.tgz as you used to (without using the -h flag).
Notice that your symlinks are gone and that everything extracted into the /usr filesystem.
>Fix:
Suggestion is to follow symbolic links by default, but to have a flag to prevent that behavior when wanted.
>Release-Note:
>Audit-Trail:
>Unformatted: