Re: Supporting arbitrary file attributes

>From [email protected] Sun Mar 31 20:42:50 2002
>> 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).

Well, then it looks like a miss understanding.

I was looking for someone who likes to add DOS file flag support to a Cygwin
port of star. In this case, it should be sufficient to add a call to translate
the POSIX filename into a filename that contains backslashes and then 
retrieve the DOS flags and convert them into a string suitable for the
encoding I use in the POSIX extended TAR header.


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

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.


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

Well, as this is not POSIX, I never thought about this aspect.
You would definitely look at the hard link detection code.

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

May need to be changed in star too.


>  - 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?

>  - 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. It may be a variant of
the code to avoid absolute path names.

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

Star has a -diff option that is more flexible than the --dif option from GNUtar.
There is a run-time definable mask for diff tasks.

>  - 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 :-(

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

Shouldn't this be handled by the OS?

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

OK

>  - comparison of file times under 2-second granularity;

Star already knows this.

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

I don't understand this.

>  - handling file names with forward and backslashes alike;

I thought that M$ allows forward slashes. So there may be a need for a
function that converts illegal PATH names from the command line into
POSIX compliant PATH names. Names generated by star will not add
backslashes.


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

These options are not in star but may appear in later versions.

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

I am sure that it is easier to hack than GNUtar but I never really thought
about such a port.

Note that there are several problems like remote tar archive support which cannot
be handled in such a port. 

>> >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...

As the star code is using more abstract data structures than GNUtar,
it is very likely that a native DOS port would not break with future 
releases of star as star is structured in a way that does not require to
modify OS dependant code in order to add featureas and vise versa.

>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.

I'll see if I can find the time...

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

BTW: what did you do with the autoconfiguration stuff?

Jörg

 EMail:[email protected] (home) Jörg Schilling D-13353 Berlin
       [email protected]		(uni)  If you don't have iso-8859-1
       [email protected]		(work) chars I am J"org Schilling
 URL:  http://www.fokus.gmd.de/usr/schilling   ftp://ftp.fokus.gmd.de/pub/unix