tar & @LongLink - OS2

This is a discussion on tar & @LongLink - OS2 ; when using tar from GTAK248 to list the contents of a tar file with very long directory paths which can't be handled by tar it displays the line .././@LongLink What exactly is this and can I use it to identify ...

+ Reply to Thread
Results 1 to 12 of 12

Thread: tar & @LongLink

  1. tar & @LongLink

    when using tar from GTAK248 to list the contents of a tar file with very
    long directory paths which can't be handled by tar it displays the line

    .././@LongLink

    What exactly is this and can I use it to identify the full path name of
    a file not correctly extracted?

    BTW has anyone ever come across Andreas Kaiser - the porter of GTAK in
    recent years? There doesn't seem to be any available source with this
    port so it is not maintainable. It would be nice to get hold of the
    ported source...

  2. Re: tar & @LongLink

    jp wrote:
    > when using tar from GTAK248 to list the contents of a tar file with very
    > long directory paths which can't be handled by tar it displays the line
    >
    > ././@LongLink
    >
    > What exactly is this and can I use it to identify the full path name of
    > a file not correctly extracted?
    >
    > BTW has anyone ever come across Andreas Kaiser - the porter of GTAK in
    > recent years? There doesn't seem to be any available source with this
    > port so it is not maintainable. It would be nice to get hold of the
    > ported source...

    Does not surprise me... I have also seen problems with tar making files
    with EA's making the files 'hidden' how long were the paths' let me know
    I will try and reproduce this problem... I take it the files where tared
    on another OS using Tar... or am I mistaken, I thought tar OS2 came with
    sause, exept for the OS/2 bits EA bits.... ???

    adrian

  3. Re: tar & @LongLink

    asuri$nospam$ wrote:

    > jp wrote:
    >
    >> when using tar from GTAK248 to list the contents of a tar file with
    >> very long directory paths which can't be handled by tar it displays
    >> the line
    >>
    >> ././@LongLink
    >>
    >> What exactly is this and can I use it to identify the full path name
    >> of a file not correctly extracted?
    >>
    >> BTW has anyone ever come across Andreas Kaiser - the porter of GTAK
    >> in recent years? There doesn't seem to be any available source with
    >> this port so it is not maintainable. It would be nice to get hold of
    >> the ported source...

    >
    > Does not surprise me... I have also seen problems with tar making
    > files with EA's making the files 'hidden' how long were the paths' let
    > me know I will try and reproduce this problem...


    Try extracting files from this archive:-

    http://zope.org/Products/ZopeX3/3.0....peX3-3.0.0.tgz

    You should see what I mean.

    If you run tar ztf ZopeX3-3.0.0.tgz >tar.lst

    you should see plenty of entries which include:-

    .././@LongLink

    > adrian



  4. Re: tar & @LongLink

    jp wrote:

    > http://zope.org/Products/ZopeX3/3.0....peX3-3.0.0.tgz


    The tar file header can only have filenames up to 99 chars.
    with this format extension they save the full filename of
    the following file as an file with name ././@LongLonk,
    and the real file header will have the name cut...


    --
    Veit Kannegieser

  5. Re: tar & @LongLink


    Hi

    Think I have solved the problem, a few years ago I wrot a pm program
    OtarGzip (a little buggy and needs updating) to tar/gzip, I opened your
    file with it and all seemed fine, it listed OK and I was able to extract
    and read the readme file in it. My conclusion is their must be a
    problem with the way tar handles compresed tar files, my program
    otargzip used gzip on all compressed tar files exept for those ending
    with a Z, I therefore think this is your problem is that tar cannot
    decompress the file, try gzip -fd file, first then tar on the *.tar file
    ......

    regards

    Adrian Suri

  6. Re: tar & @LongLink


    Hi

    Think I have solved the problem, a few years ago I wrot a pm program
    OtarGzip (a little buggy and needs updating) to tar/gzip, I opened your
    file with it and all seemed fine, it listed OK and I was able to extract
    and read the readme file in it. My conclusion is their must be a
    problem with the way tar handles compresed tar files, my program
    otargzip used gzip on all compressed tar files exept for those ending
    with a Z, I therefore think this is your problem is that tar cannot
    decompress the file, try gzip -fd file, first then tar on the *.tar file
    ......

    regards

    Adrian Suri

  7. Re: tar & @LongLink

    Veit Kannegieser wrote:

    >jp wrote:
    >
    >
    >
    >>http://zope.org/Products/ZopeX3/3.0....peX3-3.0.0.tgz
    >>
    >>

    >
    >The tar file header can only have filenames up to 99 chars.
    >with this format extension they save the full filename of
    >the following file as an file with name ././@LongLonk,
    >and the real file header will have the name cut...
    >
    >
    >

    There is no sign of such a file when the archive is extracted. It is
    only shown when running 'tar ztf foo.tgz'. I don't understand this at
    all...


  8. Re: tar & @LongLink

    asuri$nospam$ wrote:

    >
    > Hi
    >
    > Think I have solved the problem, a few years ago I wrot a pm program
    > OtarGzip (a little buggy and needs updating) to tar/gzip, I opened
    > your file with it and all seemed fine, it listed OK and I was able to
    > extract and read the readme file in it. My conclusion is their must
    > be a problem with the way tar handles compresed tar files, my program
    > otargzip used gzip on all compressed tar files exept for those ending
    > with a Z, I therefore think this is your problem is that tar cannot
    > decompress the file, try gzip -fd file, first then tar on the *.tar
    > file .....
    >


    No, the problem is related to the length of the pathnames in the tar
    achive. It is a restriction in TAR v1.10 which is what GTAK is based on.


    > regards
    >
    > Adrian Suri



  9. Re: tar & @LongLink

    jp wrote:

    > There is no sign of such a file when the archive is extracted. It is
    > only shown when running 'tar ztf foo.tgz'. I don't understand this at
    > all...


    tar has a limit in file headers (each 512 byte) how
    long the filename can be: 99 chars+ #0.

    I assume the above archive unpacked to .tar.
    At offset E6200, there is an header with "././@LongLink" followed by
    content+padding at E6400:

    ZopeX3-3.0.0/Dependencies/zope.interface-ZopeX3-3.0.0/
    zope.interface/_zope_interface_coptimizations.c

    At E6600:

    a header for file
    ZopeX3-3.0.0/Dependencies/zope.interface-ZopeX3-3.0.0/
    zope.interface/_zope_interface_coptimizations

    At E6800:

    the real content of the file.

    In this case there 'long' filename is 2 chars longer than
    the allowed length, and thus cause an overhead of 512+512 bytes.

    In my opionion it would be better to rework the archive format
    than to add hack like this.

    --
    Veit Kannegieser


  10. Re: tar & @LongLink

    Veit Kannegieser wrote:

    >jp wrote:
    >
    >
    >
    >>There is no sign of such a file when the archive is extracted. It is
    >>only shown when running 'tar ztf foo.tgz'. I don't understand this at
    >>all...
    >>
    >>

    >
    >tar has a limit in file headers (each 512 byte) how
    >long the filename can be: 99 chars+ #0.
    >
    >


    AIUI this limit is in TAR v1.10 - the last one available for OS/2.

    >In my opionion it would be better to rework the archive format
    >than to add hack like this.
    >
    >
    >


    The best solution would be to upgrade tar. The tarball referenced is
    part of the standard distribution of Zope and there is no chance of
    getting it changed.

    I have actually managed to build GNU Tar v1.14 on OS/2 although it core
    dumps
    after every action so it isn't ideal, but does manage to extract all the
    files from the Zope archive successfully. There is also an alternative
    Tar called STAR which has also been built on OS/2 which also can handle
    archives with long paths. However neither of these are a drop in
    replacement for GTAK at this point in time.

  11. Re: tar & @LongLink

    Veit Kannegieser wrote on 19.11.04 20:17 :
    > jp wrote:
    >
    >
    >>There is no sign of such a file when the archive is extracted. It is
    >>only shown when running 'tar ztf foo.tgz'. I don't understand this at
    >>all...

    >
    >
    > tar has a limit in file headers (each 512 byte) how
    > long the filename can be: 99 chars+ #0.
    >
    > I assume the above archive unpacked to .tar.
    > At offset E6200, there is an header with "././@LongLink" followed by
    > content+padding at E6400:
    >
    > ZopeX3-3.0.0/Dependencies/zope.interface-ZopeX3-3.0.0/
    > zope.interface/_zope_interface_coptimizations.c
    >
    > At E6600:
    >
    > a header for file
    > ZopeX3-3.0.0/Dependencies/zope.interface-ZopeX3-3.0.0/
    > zope.interface/_zope_interface_coptimizations
    >
    > At E6800:
    >
    > the real content of the file.
    >
    > In this case there 'long' filename is 2 chars longer than
    > the allowed length, and thus cause an overhead of 512+512 bytes.
    >
    > In my opionion it would be better to rework the archive format
    > than to add hack like this.
    >


    I use "GNU tar version 1.10 - AK 2.58". This version supports long names
    while *creating* an archive when you use the cl-option "--posix". There
    is no remedy to an archive created without this option unless you have
    the logfile.

    --
    Bye/2
    Meinolf

  12. Re: tar & @LongLink

    Meinolf Sondermann wrote:

    > I use "GNU tar version 1.10 - AK 2.58". This version supports long names
    > while *creating* an archive when you use the cl-option "--posix". There
    > is no remedy to an archive created without this option unless you have
    > the logfile.


    Reverse option? That version will cut the name and print
    a warning with '--posix', and without that option it will
    rename the files to "@@MaNgLeD.0", "@@MaNgLeD.1", ...
    and then add an file "././@MaNgLeD_NaMeS" [NAMES]
    that looks like a batch file with rename commands.

    --
    Veit Kannegieser


+ Reply to Thread