«

Not sure if this is a known problem or not, so here goes... I'm using
ActivePerl 5.8.3.809, trying to write a fairly simple piece of code that
will grab all of the management web pages from device that I have, and
then create a tar file with the all of the files inside of it. I have
no problem grabbing the html files, and even creating a flat tar file.
The problem occurs when I try to create some sort of directory structure
inside of the tar file (so that I can grab files from multiple devices,
and file them say by IP address). Every attempt that I have made to get
Archive::Tar to accept a nested file name is ignored. Here is sample code:

sub generateElement
{
my $hostName = shift;
my $pwd = shift;
my $deviceType = shift;

my @deviceTemplate = @{$Templates{$deviceType}};

for(my $i= 0; $i < scalar(@deviceTemplate); $i += 2)
{
print "$deviceTemplate[$i] -> $deviceTemplate[$i+1] \n";
if(!$www->doURLQuery("http://$hostName/$deviceTemplate[$i+1]"))
{
print "ERROR: $hostName = " . $www->getErrorMessage() . "\n";
} else {

$tar->add_data("dir1\\$deviceTemplate[$i+1]",$www->httpResponse());
}
}
}

The various webpages are successfully grabbed and stored in a .tar file,
but the "dir1\\" path is ignored. All files are in the root directory.

Any suggestions?

Thanks,

Mark

I tried that as well, with no success.

Michal Wojciechowski wrote:

>Mark Newman <> writes:
>
>[...]
>
>
>
>>The various webpages are successfully grabbed and stored in a .tar
>>file, but the "dir1\\" path is ignored. All files are in the root
>>directory.
>>
>>
>
>Just guessing: maybe Archive::Tar uses a '/' as directory separator,
>regardless of whatever character is used by the operating system?
>
>
>

Mark Newman wrote:

> The problem occurs when I try to create some sort of directory structure
> inside of the tar file (so that I can grab files from multiple devices,
> and file them say by IP address). Every attempt that I have made to get
> Archive::Tar to accept a nested file name is ignored. Here is sample code:
>
> for(my $i= 0; $i < scalar(@deviceTemplate); $i += 2)
> {
> print "$deviceTemplate[$i] -> $deviceTemplate[$i+1] \n";
> if(!$www->doURLQuery("http://$hostName/$deviceTemplate[$i+1]"))
> {
> print "ERROR: $hostName = " . $www->getErrorMessage() . "\n";
> } else {
> $tar->add_data("dir1/$deviceTemplate[$i+1]",$www->httpResponse());
> }
> }
>
> The various webpages are successfully grabbed and stored in a .tar file,
> but the "dir1/" path is ignored. All files are in the root directory.

I would have expected one of doURLQuery or add_data to use
$deviceTemplate[$i] instead of $deviceTemplate[$i+1] both places.

Anyway, it works for me.

linux% cat tar.pl
#!/usr/bin/perl
use Archive::Tar;
my $tar = Archive::Tar->new;
foreach (1 .. 5) {
$tar->add_data("dir1/$_.txt", 'xxxxx' x $_);
}
$tar->write('files.tar');
system "tar tvf files.tar";
linux% perl tar.pl
-rw-r--r-- jms/jms 5 2004-07-08 22:27:02 dir1/1.txt
-rw-r--r-- jms/jms 10 2004-07-08 22:27:02 dir1/2.txt
-rw-r--r-- jms/jms 15 2004-07-08 22:27:02 dir1/3.txt
-rw-r--r-- jms/jms 20 2004-07-08 22:27:02 dir1/4.txt
-rw-r--r-- jms/jms 25 2004-07-08 22:27:02 dir1/5.txt
linux% tar xvf files.tar
dir1/1.txt
dir1/2.txt
dir1/3.txt
dir1/4.txt
dir1/5.txt

-Joe

Just to be sure, I cut and paste your code, and tried running it, with
no success. I'm not surprised, as I've been wondering all along if this
was a Windows issue. The problem is that this script is desitined to be
used by our customers eventually, and they are running on both windows
and unix, so I need to make it work on both, or there is no point in
releasing it. I guess I may have to resort to brute force methods, i.e.
manually create the directory structure that I want on disk, and then
look and see if add_file works any better...

Joe Smith wrote:

> Mark Newman wrote:
>
>> The problem occurs when I try to create some sort of directory
>> structure inside of the tar file (so that I can grab files from
>> multiple devices, and file them say by IP address). Every attempt
>> that I have made to get Archive::Tar to accept a nested file name is
>> ignored. Here is sample code:
>>
>> for(my $i= 0; $i < scalar(@deviceTemplate); $i += 2)
>> {
>> print "$deviceTemplate[$i] -> $deviceTemplate[$i+1] \n";
>> if(!$www->doURLQuery("http://$hostName/$deviceTemplate[$i+1]"))
>> {
>> print "ERROR: $hostName = " . $www->getErrorMessage() . "\n";
>> } else {
>>
>> $tar->add_data("dir1/$deviceTemplate[$i+1]",$www->httpResponse());
>> }
>> }
>>
>> The various webpages are successfully grabbed and stored in a .tar
>> file, but the "dir1/" path is ignored. All files are in the root
>> directory.
>
>
> I would have expected one of doURLQuery or add_data to use
> $deviceTemplate[$i] instead of $deviceTemplate[$i+1] both places.
>
> Anyway, it works for me.
>
> linux% cat tar.pl
> #!/usr/bin/perl
> use Archive::Tar;
> my $tar = Archive::Tar->new;
> foreach (1 .. 5) {
> $tar->add_data("dir1/$_.txt", 'xxxxx' x $_);
> }
> $tar->write('files.tar');
> system "tar tvf files.tar";
> linux% perl tar.pl
> -rw-r--r-- jms/jms 5 2004-07-08 22:27:02 dir1/1.txt
> -rw-r--r-- jms/jms 10 2004-07-08 22:27:02 dir1/2.txt
> -rw-r--r-- jms/jms 15 2004-07-08 22:27:02 dir1/3.txt
> -rw-r--r-- jms/jms 20 2004-07-08 22:27:02 dir1/4.txt
> -rw-r--r-- jms/jms 25 2004-07-08 22:27:02 dir1/5.txt
> linux% tar xvf files.tar
> dir1/1.txt
> dir1/2.txt
> dir1/3.txt
> dir1/4.txt
> dir1/5.txt
>
> -Joe

Mark Newman <> wrote:
[...]
> no success. I'm not surprised, as I've been wondering all along if this
> was a Windows issue. The problem is that this script is desitined to be
> used by our customers eventually, and they are running on both windows
> and unix, so I need to make it work on both, or there is no point in
> releasing it. I guess I may have to resort to brute force methods, i.e.
[...]

did you read in the Archive::Tar documentation the paragraph that reads:

Although rich in features, it is known to not work on Win32
platforms. On those platforms, Archive::Tar will silently
and transparently fall back to the Archive::Tar::Win32
manpage. Please refer to that manpage if you are on a Win32
platform.

--
Glenn Jackman
NCF Sysadmin

Glenn Jackman wrote:

> did you read in the Archive::Tar documentation the paragraph that reads:
>
> Although rich in features, it is known to not work on Win32
> platforms. On those platforms, Archive::Tar will silently
> and transparently fall back to the Archive::Tar::Win32
> manpage. Please refer to that manpage if you are on a Win32
> platform.

Which version of Archive::Tar are you using? I don't see that message
in http://search.cpan.org/~kane/Archive...Archive/Tar.pm but I did
notice that http://search.cpan.org/src/KANE/Archive-Tar-1.10/README has this:

* important changes for version 0.071

It fixes a bunch of bugs, implements POSIX-style long pathnames and
adds a couple of useful methods. It has also been verified to work on
Win32.

-Joe

Actually, I just looked through the perldoc for the module, and I don't
see this...

Glenn Jackman wrote:

>Mark Newman <> wrote:
>[...]
>
>
>> no success. I'm not surprised, as I've been wondering all along if this
>> was a Windows issue. The problem is that this script is desitined to be
>> used by our customers eventually, and they are running on both windows
>> and unix, so I need to make it work on both, or there is no point in
>> releasing it. I guess I may have to resort to brute force methods, i.e.
>>
>>
>[...]
>
>did you read in the Archive::Tar documentation the paragraph that reads:
>
> Although rich in features, it is known to not work on Win32
> platforms. On those platforms, Archive::Tar will silently
> and transparently fall back to the Archive::Tar::Win32
> manpage. Please refer to that manpage if you are on a Win32
> platform.
>
>
>

I was using 1.08, but just now upgraded to 1.10. The problem still
exists, unfortunately.

Joe Smith wrote:

> Glenn Jackman wrote:
>
>> did you read in the Archive::Tar documentation the paragraph that reads:
>>
>> Although rich in features, it is known to not work on Win32
>> platforms. On those platforms, Archive::Tar will silently
>> and transparently fall back to the Archive::Tar::Win32
>> manpage. Please refer to that manpage if you are on a Win32
>> platform.
>
>
> Which version of Archive::Tar are you using? I don't see that message
> in http://search.cpan.org/~kane/Archive...Archive/Tar.pm
> but I did
> notice that http://search.cpan.org/src/KANE/Archive-Tar-1.10/README
> has this:
>
> * important changes for version 0.071
>
> It fixes a bunch of bugs, implements POSIX-style long pathnames and
> adds a couple of useful methods. It has also been verified to work on
> Win32.
>
> -Joe

Sorry to reply to my own message, but after a lot of playing around, it
seems that the directory structure IS being maintained, it's some sort
of issue with using Winzip to look at the archive that is the problem.
If I use tar.exe to examin/extract the archive, I see the directory
structure that I desired.... Weird.

Thanks for everyone's help.

Mark Newman wrote:

> I was using 1.08, but just now upgraded to 1.10. The problem still
> exists, unfortunately.
>
> Joe Smith wrote:
>
>> Glenn Jackman wrote:
>>
>>> did you read in the Archive::Tar documentation the paragraph that
>>> reads:
>>>
>>> Although rich in features, it is known to not work on Win32
>>> platforms. On those platforms, Archive::Tar will silently
>>> and transparently fall back to the Archive::Tar::Win32
>>> manpage. Please refer to that manpage if you are on a Win32
>>> platform.
>>
>>
>>
>> Which version of Archive::Tar are you using? I don't see that message
>> in http://search.cpan.org/~kane/Archive...Archive/Tar.pm
>> but I did
>> notice that http://search.cpan.org/src/KANE/Archive-Tar-1.10/README
>> has this:
>>
>> * important changes for version 0.071
>>
>> It fixes a bunch of bugs, implements POSIX-style long pathnames and
>> adds a couple of useful methods. It has also been verified to work on
>> Win32.
>>
>> -Joe
>
>