🚀 go-pugleaf

In article <ti6ls.718300894@tuhhco>  writes:
> As the man pages say "The current limit on file name length is 100  
characters."
> Has anyone fixed this bug?
> 
> 
>  
/*****************************************************************************/
> /*      Ludger Solbach, AB Techn. Inf. VI, TU Hamburg-Harburg, Germany        
*/
> /*                         Tel.: 040/7718-3357                                
*/
> /*                   Email: solbach@tu-harburg.dbp.de                         
*/
>  
/*****************************************************************************/

YEP, GNU! get GNUtar... (it's all over the places, on many different servers)
--
Robert Frank                         tel. + (061) 321 99 67                 
Institut fuer Informatik             fax  + (061) 321 99 15                 
University of Basel, Switzerland                                            
Mittlere Strasse 142      rfc822: frank@ifi.unibas.ch (NeXT mail accepted)  
CH-4056 Basel          X400: S=frank;OU=ifi;O=unibas;P=switch;A=arcom;C=ch
                   ( if all fails try frank@urz.unibas.ch )

In article <1992Oct6.084806.10760@urz.unibas.ch> frank@ifi.unibas.ch writes:
>In article <ti6ls.718300894@tuhhco>  writes:
>> As the man pages say "The current limit on file name length is 100  
>characters."
>> Has anyone fixed this bug?
>> 
>/*****************************************************************************/
>> /*      Ludger Solbach, AB Techn. Inf. VI, TU Hamburg-Harburg, Germany        
>YEP, GNU! get GNUtar... (it's all over the places, on many different servers)
>--
>Robert Frank                         tel. + (061) 321 99 67                 


I do not understand the answer. The gnutar still has the default NAMSIZ set
to (only ?) 100 characters. Maybe Robert thought about the path length ?

	-Z.

frank@ifi.unibas.ch (Robert Frank) writes:

>In article <ti6ls.718300894@tuhhco>  writes:
>> As the man pages say "The current limit on file name length is 100  
>characters."
>> Has anyone fixed this bug?
>> 
>YEP, GNU! get GNUtar... (it's all over the places, on many different servers)

Also there is some variant of tar that handles >100 char filenames
buried in 3.0, in Installer.app.  I think it's called
installer_bigtar.
-- 
David Lemson                                                (217) 244-1205
University of Illinois NeXT Campus Consultant / CCSO NeXT Lab System Admin
Internet : lemson@uiuc.edu                UUCP :...!uiucuxc!uiucux1!lemson 
NeXTMail accepted                                  BITNET : LEMSON@UIUCVMD

In article <1992Oct6.204852.16384@wam.umd.edu> elitman@nxstep.com (Eric A. Litman) writes:
>Ludger Solbach (ti6ls@tuhhco.rz.tu-harburg.de) wrote:
>: As the man pages say "The current limit on file name length is 100 characters."
>: Has anyone fixed this bug?
>
>GNU tar is definitely the answer, but it is not necessary to "get" it off of
>some archive site somewhere. Under 3.0, it's /usr/bin/gnutar.
>
>--
>Eric A. Litman  #import <std/disclaimer.h> | NeXTMail, MIME accepted - please 
>U. of Maryland, NeXT Campus Consultant     | indicate in Subject line.

The original posting was about tar-like program which should handle names
longer than 100 characters.
MANY PEOPLE answered, that the gnutar is the solution. Somebody is wrong   :)
because the following test shows, that the gnutar also does not like long
names:

	% echo > /tmp/aaaaa...aaaa	(repeat this 'a' more than 100 times)

	% gnutar cvf /tmp/x.tar /tmp/aaaaa*

	    and the gnutar protests: ...aaaa is too long: mangling to ...

Yes, the /NextAdmin/Installer.app/installer_bigtar accepts longer names,
but the resulted archive-file is not compatible with "normal" tar.

	-Z.

PS
And in the GNUtar sources the NAMSIZ parameter is set to 100.

Robert Frank suggests:

>> YEP, GNU! get GNUtar... (it's all over the places, on many different servers)

Actually, it's already on your NeXT 3.0 system.  It's called (suprise)
gnutar.

David Lemson suggests:

>> Also there is some variant of tar that handles >100 char filenames
>> buried in 3.0, in Installer.app.  I think it's called installer_bigtar.

Right.  I linked it to the name "bigtar" in my path, and I use that
to manually extract selected items out of NeXT .tar.Z files inside
.pkg files, since bigtar is what made them.  I do not know if bigtar
and gnutar use incompatible methods for storing longer names or not.
I do know that bigtar and gnutar are different.

Mark Adler
madler@cco.caltech.edu

Ludger Solbach (ti6ls@tuhhco.rz.tu-harburg.de) wrote:
: As the man pages say "The current limit on file name length is 100 characters."
: Has anyone fixed this bug?

GNU tar is definitely the answer, but it is not necessary to "get" it off of
some archive site somewhere. Under 3.0, it's /usr/bin/gnutar.

--
Eric A. Litman  #import <std/disclaimer.h> | NeXTMail, MIME accepted - please 
U. of Maryland, NeXT Campus Consultant     | indicate in Subject line.

In article <1992Oct6.084806.10760@urz.unibas.ch> frank@ifi.unibas.ch writes:
>In article <ti6ls.718300894@tuhhco>  writes:
>> As the man pages say "The current limit on file name length is 100  
>characters."
>> Has anyone fixed this bug?


Actually, try out /NextAdmin/Installer.app/installer_bigtar

It is NOT NOT compatible with "tar" but works fine for over 100
character lines.

- darcy

>> 
>> 
>>  
>/*****************************************************************************/
>> /*      Ludger Solbach, AB Techn. Inf. VI, TU Hamburg-Harburg, Germany        
>*/
>> /*                         Tel.: 040/7718-3357                                
>*/
>> /*                   Email: solbach@tu-harburg.dbp.de                         
>*/
>>  
>/*****************************************************************************/
>
>YEP, GNU! get GNUtar... (it's all over the places, on many different servers)
>--
>Robert Frank                         tel. + (061) 321 99 67                 
>Institut fuer Informatik             fax  + (061) 321 99 15                 
>University of Basel, Switzerland                                            
>Mittlere Strasse 142      rfc822: frank@ifi.unibas.ch (NeXT mail accepted)  
>CH-4056 Basel          X400: S=frank;OU=ifi;O=unibas;P=switch;A=arcom;C=ch
>                   ( if all fails try frank@urz.unibas.ch )

In article <Bvpnv8.1w4@ux1.cso.uiuc.edu> lemson@ux1.cso.uiuc.edu (David Lemson) writes:
>Also there is some variant of tar that handles >100 char filenames
>buried in 3.0, in Installer.app.  I think it's called
>installer_bigtar.

My backup script has broken pretty badly under 3.0 with more file names
containing space and upper ASCII characters.  So I just don't back up such
files since they tend to be system files or MiniExamples.

But the long path problem has plagued me as well, so I tried installer_bigtar.
It seems to be a good news/bad news story.  It doesn't seem to create a table
of contents (-t reports nothing).  -v prints nothing.  Either tar or gtar
complains about the installer_tar file format (can't remember which).  So I'd
recomment caution before depending on installer_tar; gnutar (1.10) is in
/usr/bin and seems to support long paths, but in a slightly different way than
the current gnutar (1.11.1).
-- 

Art Isbell                                                      Cubic Solutions
NeXT Registered Developer #745         NeXT software development and consulting
Email: isbell@cats.UCSC.EDU                                Voice: (408)335-1154
USmail: 95018-9442                                           Fax: (408)335-2515

Zenon Fortuna admirably does some testing and concludes:

>> The original posting was about tar-like program which should handle names
>> longer than 100 characters.
>> MANY PEOPLE answered, that the gnutar is the solution. Somebody is wrong   :)

gnutar is indeed *a* solution.  You did not follow your test through to
its conclusion, which is to reextract the files.  Yes, the names (including
paths) longer than 100 characters get renamed to @@MaNgLeD.n, where n is
an integer.  BUT, there is a file written at the end of the tar file that
contains the *real* names for these "mangled" file names, and when doing
a "gnutar x", this file is read and the mangled names are renamed to their
proper, longer than 100 character, full names.

I tried this on /NextDeveloper/Apps/InterfaceBuilder.app, which has many
name/paths longer than 100 characters.

I said "a" solution as opposed to "the" solution, since this doesn't
help when you want to extract a particular file without extracting all
of them.  There may be a way to do that with gnutar that I don't know,
but it would take two passes of the file, since the name information is
at the end.  Or one pass in which all the files with mangled file names
are extracted.  Actually, let me try that ...

Hmm, doesn't quite work.  A "gnutar xvf - @@MaNgLeD.\*" got all the
files like that, but at the end it was not able to rename them to where
they belonged, since the directories did not exist.  I might call this a
bug in gnutar, since I can imagine a situation in which a long name is
the only one in that directory, and then the original extract might
fail.  gnutar does seem to be able to make at least one directory down,
but maybe not more.

As someone else mentioned, bigtar is also only a partial solution, since
much of the tar functionality seems to be missing in bigtar.  Though it
does work for long names.  For backups though, I would prefer gnutar,
since I may have to restore the files on a non-NeXT machine.  I can find
or make gnutar on another machine, but not bigtar.

Mark Adler
madler@cco.caltech.edu

In article <1992Oct6.084806.10760@urz.unibas.ch> frank@ifi.unibas.ch writes:
>In article <ti6ls.718300894@tuhhco>  writes:
>> As the man pages say "The current limit on file name length is 100  
>characters."
>> Has anyone fixed this bug?
>
>YEP, GNU! get GNUtar... (it's all over the places, on many different servers)
>--
However, the one that comes on the NeXT in /usr/bin/gnutar doesn't
really fix the problem exactly.  When it encounters a path that is too
long it converts it to something like %%mangled1 and displays this info
on the terminal window.  You have to make a note of it in order to
recover the file to the right place.  Somebody says this is an older
version of gnutar so a newer version might do the right thing. 
-- 
Bob Peirce, Pittsburgh, PA         rbp@investor.pgh.pa.us         412-471-5320
venetia@investor.pgh.pa.us [NeXT Mail]  !uunet.uu.net!pitt!investor!rbp [UUCP]

>> However, the one that comes on the NeXT in /usr/bin/gnutar doesn't
>> really fix the problem exactly.  When it encounters a path that is too
>> long it converts it to something like %%mangled1 and displays this info
>> on the terminal window.  You have to make a note of it in order to
>> recover the file to the right place.

No, you don't have to make a note of anything.  That information also
goes into a special file at the end of the tar file, and that information
is used automatically by gnutar to rename all the mangled names to their
correct, > 100 character names.

>> Somebody says this is an older
>> version of gnutar so a newer version might do the right thing. 

The gnutar in 3.0 is an older version, and it is true that the newer
versions work better, since they store that name closer to the file
instead of at the end of the tar file, which facilitates extracting
individual files.  But for entire archive creation and extraction, the
gnutar in 3.0 works for long names.

Mark Adler
madler@cco.caltech.edu