[Gnu-arch-users] Re: arch on windows?

[Ron Parker]

On Mon, 12 Jul 2004 09:21:36 -0500, John Meinel <address@hidden> wrote:

> I just wanted to mention that Ron is also hoping to have tla run under
> MacOSX, which afaik has the same problem with long pathnames, but
> doesn't have a legacy 8.3 mode, or a long path API. I'm not positive on
> this, I'm just repeating what I remember from him.

Off of the top of my head, I do not remember the PATH_MAX limit on Mac
OS X.  Aaron has posted that there was a path length limit that would
be an issue for arch. I don't currently have my Mac in hand, so I
cannot verify this. But see,

http://lists.gnu.org/archive/html/gnu-arch-users/2004-07/msg00170.html
http://lists.gnu.org/archive/html/gnu-arch-users/2004-04/msg00523.html

The definite issue I am aware of on the Mac is the common usage of
"\(sp)" in filenames. This is mostly handled by the pika-escapes
changes in the address@hidden archive.  (I may have just run
into on more small issue WRT those patches.  I am investigating it
further.)

Also from some timing tests I ran this weekend, HFS+ on Mac OS X seems
to have a very slow hard-link speed, as a matter of fact doing a
"build-config --link" from a pre-existing revlib timed out at
virtually the same speed as one without the link directive.

I know this will aggravate somebody, but so far I have not run into a
need to preserve resource-forks on the Mac or alternate file streams
on Windows. So I am not attempting to address these issues currently.

There are two issues related to =dirname pathcompression that concern
me.  The more important one is the ability to create
source-distribution tar files that preserve the {arch} and .arch_ids
directories is such a manner that they are useful across all systems. 
The less important one is that I could envision someone wanting
(needing?) to host an archive on the wed using a system that lacks
good long file path support.

Originally I was advocating a change to the arch "protocol" that would
enable all arch implementations on all systems to deal with these
distribution files and archives, essentially optionally recognizing
and maintaining the =dirname file when in exists.

However, viewed in isolation the first issue can be handled by a
wrapper or higher level command in tla that would create a standard
source tarball by calling the patched tar implementation.  This could
be something along the lines of "tla build-inventory-tarball".

Alternatively, the patched tar could be made available to the end-user
via a link, either tla-tar or going along with Lode's naming, vu-tar.

I am certainly open to ideas of how to address the second issue in an
upwardly compatible manner as neither Microsoft's Internet Information
Server (at least version 5.0) nor Apache on Cygwin will serve up files
with a file path longer than 260 characters.