Re: Supporting arbitrary file attributes

[Eli Zaretskii]

> From: Joerg Schilling <address@hidden>
> Date: Wed, 3 Apr 2002 01:33:59 +0200 (MEST)
> 
> >  - use popen instead of pipe/fork/exec on systems that don't support
> >    them (mostly used for built-in compression and uncompression via
> >    external programs);
> 
> This would be needed inside star too. However as there already are 
> integrated autoconf tests for fork()/exec() the code would not need 
> #ifdef CYGWIN.

The question is: what do you do if fork/exec aren't supported?  Old
ports of GNU Tar disabled the -z option for such platforms, because
an alternative code, the one which uses popen, was missing.  I don't
consider such a solution as a good one.  I think if a feature can be
supported, it should be, even at a price of writing more code.

> >  - set the file handle for disk I/O to binary mode, but not if the
> >    archive is taken from a terminal device (I hope the snippet from
> >    the Cygwin port you mentioned above is not executed for a
> >    terminal);
> 
> I don't understand this. Do you like to write the TAR archive to a
> terminal device?

GNU Tar allows this ("tar -cvf - foo..."), so the ported Tar needs to
DTRT with that possibility.  It's not a porter's job (IMHO) to
second-guess the end user.  Users should be given the liberty of using
any feature the program has without unduly endangering their machines
(or their sanity ;-).

> >  - handle DOS/Windows-style absolute file names with drive letters
> >    (important when Tar decides whether to remove the leading slash
> >    from a file name, and how much to remove; also important to avoid
> >    handling x:/foo/bar as a remote file name);
> 
> Such a path should not be inside a tar archive.

As long as Tar can be used as a backup program, you must allow drive
letters in file names.  In addition, users can mention drive letters
on the command line even if they don't want them in the archive, and
Tar should remove the drive letter and the slash after that, like
what it does with the leading slash on Unix.

> >  - unpacking file names which on DOS/Windows are reserved by
> >    installed device drivers (seemingly innocent file names like
> >    aux.c or prn.txt can wedge the system, if this is not handled
> >    appropriately);
> 
> Looks like a OS design bug :-(

Sure; but Tar needs to avoid crashing the machine in those cases,
don't you think?  Since Tar is a vehicle for moving files between
different systems, it cannot ignore problems like this one.

> >  - unpacking archives with files whose names include characters
> >    disallowed by DOS/Windows filesystems (like `:', `<', `?', etc.);
> 
> Shouldn't this be handled by the OS?

The OS simply refuses to create files with such names.  It's IMHO not
a good idea for Tar to print the relevant error message and fail to
extract a file.  That file could be a crucial part of some package;
losing it might leave the user wondering why is the package broken.

My solution was to replace the offending characters with a safer
character (and print a message to that effect).

> >  - --backup with non-regular files (DOS/Windows won't allow that);
> 
> I don't understand this.

If the archive includes a non-regular file, and the user used the
"--backup" option, the user will get unhelpful error messages on
Windows.

> >  - handling file names with forward and backslashes alike;
> 
> I thought that M$ allows forward slashes.

That's true.  But what I meant was something different: suppose the
user types this command:

     tar -cvf \foo\bar\baz

Tar should DTRT with this command.  But that doesn't mean the archive
should include backslashes.

> So there may be a need for a function that converts illegal PATH
> names from the command line into POSIX compliant PATH names.

That's what the ported Tar does: it converts each file name, right
away, into Posix-compliant name that uses forward slashes.

The point is, there has to be code to do that, otherwise you will end
up with an archive with backslashes in it (and gobs of Tar's own code
will break, since it doesn't recognize `\' as a delimiter in file
names).

> BTW: what did you do with the autoconfiguration stuff?

There are good ports of Bash and other related tools (Fileutils,
Textutils, Grep, Sed, etc.) to DOS/Windows.  So the configure script
can simply be run almost unaltered, provided that you help it out by
setting a few ac* variables in advance.  Configuring Tar was the easy
part.