Re: Supporting arbitrary file attributes

[Eli Zaretskii]

> From: Joerg Schilling <address@hidden>
> Date: Sun, 31 Mar 2002 16:28:47 +0200 (MEST)
> 
> How about lokking into star's sources?

When I have time, perhaps.  Right now, I have too much on my todo.

> Star uses abstract internal data structures. Porting star to Cygwin mainly 
> ended up in introducing a line like:
> 
> setmode(fileno(tarf), O_BINARY); 

I was specifically talking about native DOS/Windows ports, not about
Cygwin.  Cygwin conceals many issues in the library, which presents a
Posix-like appearance to the application (although some Windows
problems cannot be solved in their entirety that way).

> And some code to make star know about the 2 second granularity of the DOS
> filesystem.

I cannot say anything intelligent about code I didn't see and study.
So let me instead tell you something about the kind of changes I
needed to make in GNU Tar.  I don't know which ones of them are
relevant to star, but anyway...

First, there are more than 50 DOS/Windows-related #ifdef's in the
ported Tar.

Next, here are some of the issues these ifdef's needed to take care
of:

  - 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);

  - use of inodes to avoid archiving the tar being created
    (DOS/Windows systems generally don't have a notion of an inode);

  - use of rdev (also not supported on non-Posix systems);

  - 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);

  - 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);

  - comparison (under --diff) of files on disk with archived files,
    when the archived files are links (either hard or symlinks),
    which the Windows/DOS port simulates by copying;

  - also under --diff, the comparison of mode bits should ignore bits
    not supported by the underlying filesystem;

  - inodes need to be ignored by --diff, even if the library simulates
    inodes (like the DJGPP library does), because the inodes cannot be
    preserved when unpacking links; instead, the files' contents need
    to be compared;

  - 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);

  - unpacking archives with files whose names include characters
    disallowed by DOS/Windows filesystems (like `:', `<', `?', etc.);

  - failure to set time stamps of directories on some Windows
    filesystems;

  - comparison of file times under 2-second granularity;

  - --backup with non-regular files (DOS/Windows won't allow that);

  - handling file names with forward and backslashes alike;

  - support for --owner and --group options on systems that don't know
    what's a file owner or a user group;

If star handles these problems, or makes them non-issues, my hat's off
to its maintainer(s).

> >I ported GNU Tar 1.12.x to MS-DOS and MS-Windows, and I can tell you that 
> >it was a kind of effort I would never wish to go through again.  (You can 
> >see the results at http://www.simtel.net/pub/djgpp/v2gnu/.)  That is why 
> >I didn't roll back that port into Tar 1.13.x series--the pain of going 
> >through all that code is just too much for me...
> 
> Sorry I cannot find any description about porting problems on this page.

Download tar112as.zip from that page, and grep the sources for
"DOSWIN".  Hopefully, the above list will also give you some idea of
the magnitude of changes required, even without reading the ported
code.  In general, there wasn't an option, of the 20-something options
Tar offers, that didn't need meticulous testing and eventually some
kind of code change somewhere, to preserve the functionality under
such a different environment.

> But you may have had the same unneeded problems like in GNUmake.

Porting Tar was nowhere near GNU Make.  The latter is much, much
easier.  Basically, there's only one source file in GNU Make that
needs extensive porting changes fior non-Posix systems (job.c).