[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Supporting arbitrary file attributes
From: |
Joerg Schilling |
Subject: |
Re: Supporting arbitrary file attributes |
Date: |
Wed, 3 Apr 2002 01:33:59 +0200 (MEST) |
>From address@hidden 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:address@hidden (home) Jörg Schilling D-13353 Berlin
address@hidden (uni) If you don't have iso-8859-1
address@hidden (work) chars I am J"org Schilling
URL: http://www.fokus.gmd.de/usr/schilling ftp://ftp.fokus.gmd.de/pub/unix
- Re: Supporting arbitrary file attributes,
Joerg Schilling <=