[Bug-tar] win32 port of GNU tar unexpectedly dereferences shortcuts

[Mark Brand]

bug report for win32 port of GNU tar 1.13

Tar appears to try to resolve Windows shortcuts to the files they refer 
to when creating archives. If the referred to file does not exist, a 
pop-up dialog box appears with a message that windows is searching for 
the file!

I believe the desired default behavior would be to simply archive the 
.lnk file. I suppose that, if this default behavior were implemented, it 
might be OK, although not obviously desirable,  to let --dereference 
override it.  I myself would not accord the same status to windows 
shortcuts as to actual links in the file system. (I thought that 
shortcuts were supposed to operate at the level of the Explorer and GUIs 
but not at the command line. The "type" command doesn't dereference 
shortcuts.)

I observed this behavior on a Windows XP installation. The file system 
was NTFS.

To reproduce:

mkdir junk
cd junk
echo hello > file.txt
explorer .

(Make a shortcut by drag and drop called "Shortcut to file.txt.lnk" 
pointing to file.txt.)

tar -cvf ..\archive.tar  *
del  file.txt
tar -cvf ..\archive2.tar myshortcut.lnk *