Author Topic: Creating archive > 4GiB from script  (Read 27549 times)

shmuel

  • Guest
Creating archive > 4GiB from script
« on: November 28, 2018, 07:56:29 pm »
I have a script on my ArcaOS system that I use to backup all of my logical drives, except those used by openSUSE, to a USB thumb drive. It works well except for drive M:, a rather large collection of manuals. The script uses zip, and when the archive file exceeds 4 GiB, unzip can't handle it. I tried using -s and concatenating the pieces, but that just changed the symptoms.

Plan B was p7zip, with the command 7za w:\temp\M.7z M:\

I get a message that no files were found and an empty archive. I tried adding an * to M:\* and I tried the -r option; neither helped. What is the correct syntax for creating an archive of the entire volume?

Note: except for FAT C: and D: dries for freedoms, everything is JFS.

FWIW, Arctool was able to create an 11 GiB archive of the volume; I'm not sure how large it would be with default compression.

Thanks.

Doug Bissett

  • Hero Member
  • *****
  • Posts: 1593
  • Karma: +4/-2
    • View Profile
Re: Creating archive > 4GiB from script
« Reply #1 on: November 28, 2018, 10:04:36 pm »
I use ZIP to backup my drives. One of mt ZIP files is about 12 GB, and it contains, at least one file that is about 5 GB. Be absolutely sure, that you are using the ZIP, and UNZIP, as distributed by RPM/YUM. Older versions of ZIP/UNZIP do not support files larger than 2 GB in, or out. The latest ZIP.EXE (from RPM/YUM) has a necessary fix for the -S parameter (capital 'S', parameters are case sensitive). I use the parameters -9yrS to do my backups. I have restored drives (including boot drives), a number of times, so I know that it works.

I do use Archive tool to manage the UNZIP activity. It makes it easy to pick out individual files, or directories, or do the whole thing. Be sure to set extract Full paths, to put files back in the original locations.

A typical backup command, for a full drive, is:
Code: [Select]
zip.exe -9yrS CDRIVE.ZIP C:\* -x@exclude.list 2>&1 | tee.exe CZIP.LOG
ZIP.EXE is in the path, the parameters use maximum compression, handle symlinks correctly, recurse through directories, and include system and hidden files. The exclude.list file contains a list of files that you don't need to back up. The rest redirects all output to TEE.EXE (available from RPM/YUM), which shows the progress in the window, and sends that to the log file. I use it to back up live boot drives, and there has never been a problem with that. Of course, that may depend on what else is actually running.

Bogdan

  • Jr. Member
  • **
  • Posts: 93
  • Karma: +1/-0
    • View Profile
Re: Creating archive > 4GiB from script
« Reply #2 on: November 28, 2018, 11:43:35 pm »
I have a script on my ArcaOS system that I use to backup all of my logical drives, except those used by openSUSE, to a USB thumb drive. It works well except for drive M:, a rather large collection of manuals. The script uses zip, and when the archive file exceeds 4 GiB, unzip can't handle it.
unzip can definitely handle large files. Also the klibc based build can unarchive a compressed zip archive larger than 4GB. The problem with the private klibc build is a broken directory handling combined with file name and path length problems. Almost every program that is linked dynamically against libcxx has problems with root directories and codepages in general. But the LARGEFILE stuff is handled in a proper way on supported file systems. So in real world you can use it for single file zip archives larger than 4 GB without issues, but there will be problems with large directory sizes, amount of files or deep path structures.

Quote
I tried using -s and concatenating the pieces, but that just changed the symptoms.

Plan B was p7zip, with the command 7za w:\temp\M.7z M:\

I get a message that no files were found and an empty archive. I tried adding an * to M:\* and I tried the -r option; neither helped. What is the correct syntax for creating an archive of the entire volume?
A simple solution or workaround when files can cause trouble for crappy tools is to avoid the usage of files completely or to some degree. You can do simply a complete disk dump of this volume and piping it through a compressor to create a large file for recovery. Or you collect all names in the volume (by a dir or find utility) and check if names and path length can be handled by those tools you mentioned earlier.

Silvan Scherrer

  • Full Member
  • ***
  • Posts: 200
  • Karma: +1/-0
    • View Profile
Re: Creating archive > 4GiB from script
« Reply #3 on: November 29, 2018, 11:07:15 am »
I have a script on my ArcaOS system that I use to backup all of my logical drives, except those used by openSUSE, to a USB thumb drive. It works well except for drive M:, a rather large collection of manuals. The script uses zip, and when the archive file exceeds 4 GiB, unzip can't handle it.
unzip can definitely handle large files. Also the klibc based build can unarchive a compressed zip archive larger than 4GB. The problem with the private klibc build is a broken directory handling combined with file name and path length problems. Almost every program that is linked dynamically against libcxx has problems with root directories and codepages in general. But the LARGEFILE stuff is handled in a proper way on supported file systems. So in real world you can use it for single file zip archives larger than 4 GB without issues, but there will be problems with large directory sizes, amount of files or deep path structures.

Quote
I tried using -s and concatenating the pieces, but that just changed the symptoms.

Plan B was p7zip, with the command 7za w:\temp\M.7z M:\

I get a message that no files were found and an empty archive. I tried adding an * to M:\* and I tried the -r option; neither helped. What is the correct syntax for creating an archive of the entire volume?
A simple solution or workaround when files can cause trouble for crappy tools is to avoid the usage of files completely or to some degree. You can do simply a complete disk dump of this volume and piping it through a compressor to create a large file for recovery. Or you collect all names in the volume (by a dir or find utility) and check if names and path length can be handled by those tools you mentioned earlier.
as you seem to know exactly whats wrong with those so called private builds (even I have no idea why those should be called like that), I wonder where your bug reports are.
Exactly such ports give me the feeling I should completely give up on either reading anything in this forum at all, or give up completely with porting software.
Just pointing to software which should not behave right, but not adding bug reports is not the way to go. Sorry
kind regards
Silvan
CTO bww bitwise works GmbH

Please help us with donations, so we can further work on OS/2 based projects. Our Shop is at https://www.bitwiseworks.com/shop/index.php

Bogdan

  • Jr. Member
  • **
  • Posts: 93
  • Karma: +1/-0
    • View Profile
Re: Creating archive > 4GiB from script
« Reply #4 on: November 29, 2018, 04:20:32 pm »
as you seem to know exactly whats wrong with those so called private builds (even I have no idea why those should be called like that), I wonder where your bug reports are.

There were several bugs fixed and patches will make it to the next release (https://sourceforge.net/p/infozip/bugs/search/). But I cannot find any information about which patches were applied by your private build.

Quote
Exactly such ports give me the feeling I should completely give up on either reading anything in this forum at all, or give up completely with porting software.
Sorry I don't realise your point of view. Zip and Unzip have been portable software for very loooooong time and OS/2 is still supported. About which kind of porting you're talking?

Quote
Just pointing to software which should not behave right, but not adding bug reports is not the way to go. Sorry
By providing private built binaries derived from Zip and Unzip sources you can at least point to your patches or modifications, so we can check the issues.

Dave Yeo

  • Hero Member
  • *****
  • Posts: 4787
  • Karma: +99/-1
    • View Profile
Re: Creating archive > 4GiB from script
« Reply #5 on: November 29, 2018, 05:14:55 pm »

By providing private built binaries derived from Zip and Unzip sources you can at least point to your patches or modifications, so we can check the issues.

Hi Bogdan, I don't know if private builds is the best description as these builds ship with the latest releases of ArcaOS, perhaps forks is a better term.
While the Bitwise people do make some choices that others don't agree with, they are some of the few developers actually doing something on our platform and though they do make some money doing it, considering the amount of time and effort they put in, much of the work is basically on a volunteer basis and it is hard to bitch about people doing stuff for free, even if not perfect.
One of the decisions they've made is not to spend time trying to get their patches accepted up stream. Be nice if they did, but understandable as getting patches accepted can and usually is, time consuming.
They have been very good about following licenses including being public with their fixes and other patches with many hosted at netlabs and others at Github.
In the case of zip and unzip, their trees are at http://trac.netlabs.org/ports/browser/zip/trunk and http://trac.netlabs.org/ports/browser/unzip/trunk with issue tracking also hosted at netlabs.

shmuel

  • Guest
Re: Creating archive > 4GiB from script
« Reply #6 on: November 29, 2018, 08:35:15 pm »
Be absolutely sure, that you are using the ZIP, and UNZIP, as distributed by RPM/YUM. Older versions of ZIP/UNZIP do not support files larger than 2 GB in, or out. The latest ZIP.EXE (from RPM/YUM) has a necessary fix for the -S parameter (capital 'S', parameters are case sensitive). I use the parameters -9yrS to do my backups. I have restored drives (including boot drives), a number of times, so I know that it works[/code]

From zip -v

Code: [Select]
Copyright (c) 1990-2008 Info-ZIP - Type 'zip "-L"' for software license.
This is Zip 3.0 (July 5th 2008), by Info-ZIP.
Currently maintained by E. Gordon.  Please send bug reports to
the authors using the web page at www.info-zip.org; see README for details.

Latest sources and executables are at ftp://ftp.info-zip.org/pub/infozip,
as of above date; see http://www.info-zip.org/ for other sites.

Compiled with emx+gcc 4.9.2 for OS/2 2.x/3.x (32-bit) on Sep 28 2018.

Zip special compilation options:
ASMV
USE_EF_UT_TIME       (store Universal Time)
SYMLINK_SUPPORT      (symbolic links supported)
LARGE_FILE_SUPPORT   (can read and write large files on file system)
ZIP64_SUPPORT        (use Zip64 to store large files in archives)
[encryption, version 2.91 of 05 Jan 2007] (modified for Zip 3)

Encryption notice:
The encryption code of this program is not copyrighted and is
put in the public domain.  It was originally written in Europe
and, to the best of our knowledge, can be freely distributed
in both source and object forms from any country, including
the USA under License Exception TSU of the U.S. Export
Administration Regulations (section 740.13(e)) of 6 June 2002.

Zip environment options:
             ZIP:  [none]
          ZIPOPT:  [none]
             EMX:  [none]
          EMXOPT:  [none]

From unzip -v

Code: [Select]
UnZip 6.00 of 20 April 2009, by Info-ZIP.  Maintained by C. Spieler.  Send
bug reports using http://www.info-zip.org/zip-bug.html; see README for details.

Latest sources and executables are at ftp://ftp.info-zip.org/pub/infozip/ ;
see ftp://ftp.info-zip.org/pub/infozip/UnZip.html for other sites.

Compiled with emx+gcc 4.9.2 for OS/2 (32-bit) on Jun 12 2018.

UnZip special compilation options:
        ASM_CRC
        COPYRIGHT_CLEAN (PKZIP 0.9x unreducing method not supported)
        OS2_EAS
        SET_DIR_ATTRIB
        SYMLINKS (symbolic links supported, if RTL and file system permit)
        TIMESTAMP
        UNIXBACKUP
        USE_EF_UT_TIME
        USE_UNSHRINK (PKZIP/Zip 1.x unshrinking method supported)
        USE_DEFLATE64 (PKZIP 4.x Deflate64(tm) supported)
        LARGE_FILE_SUPPORT (large files over 2 GiB supported)
        ZIP64_SUPPORT (archives using Zip64 for large files supported)
        USE_BZIP2 (PKZIP 4.6+, using bzip2 lib version 1.0.6, 6-Sept-2010)
        VMS_TEXT_CONV
        [decryption, version 2.11 of 05 Jan 2007]

UnZip and ZipInfo environment options:
           UNZIP:  [none]
        UNZIPOPT:  -C
         ZIPINFO:  [none]
      ZIPINFOOPT:  [none]
             EMX:  [none]
          EMXOPT:  [none]

I thought that was using the version installed by ArcaOS, but I'll double check the PATH.

Meanwhile, any thoughts why 7za gives

Code: [Select]
Tue 11-27-18 22:47:32{1}[h:\vendors\7-zip\p7zip-16.02-os2-1\bin] 7za a w:\temp\m.7z m:\

7-Zip (a) [32] 16.02 : Copyright (c) 1999-2016 Igor Pavlov : 2016-05-21
p7zip Version 16.02 (locale=en_US.IBM-850,Utf16=on,HugeFiles=on,32 bits,2 CPUs x
86)

Open archive: w:/temp/m.7z
--
Path = w:/temp/m.7z
Type = 7z
Physical Size = 32
Headers Size = 0
Solid = -
Blocks = 0

Scanning the drive:

WARNING: No more files
m:

0 files, 0 bytes

Updating archive: w:/temp/m.7z

Items to compress: 0


Files read from disk: 0
Archive size: 32 bytes (1 KiB)

Scan WARNINGS for files and folders:

m: : No more files
----------------
Scan WARNINGS: 1


Doug Bissett

  • Hero Member
  • *****
  • Posts: 1593
  • Karma: +4/-2
    • View Profile
Re: Creating archive > 4GiB from script
« Reply #7 on: November 30, 2018, 03:42:23 am »
Quote
I thought that was using the version installed by ArcaOS, but I'll double check the PATH.

What you show, is what the programs display, but it doesn't tell the whole story. It depends on which version of ArcaOS you have installed, and if you have properly updated the RPM/YUM stuff (use ANPM), to be sure that you have the correct versions. You may even need to install ZIP and UNZIP, using ANPM (RPM/YUM), to get the correct version installed. Look in the list in ANPM for that information. The description of your problems is exactly what happens if you are using an older version of ZIP/UNZIP. You also need to be sure that you do not have any older versions hanging around, just waiting to cause problems.

If it all looks correct, use ANPM to uninstall ZIP and UNZIP, then install them again, just to be sure that something didn't down level them in the background. Also, be aware, that ArcaOS has a copy of the older ZIP/UNZIP in the \SYS\INSTALL directory, but they are named ZIP2.EXE and UNZIP5.EXE. There is a reason for that, so don't mess with it.

Bogdan

  • Jr. Member
  • **
  • Posts: 93
  • Karma: +1/-0
    • View Profile
Re: Creating archive > 4GiB from script
« Reply #8 on: December 01, 2018, 07:28:31 pm »
Hi Bogdan, I don't know if private builds is the best description as these builds ship with the latest releases of ArcaOS, perhaps forks is a better term.
It's quite easy, these builds seem to be from a private codebase and not released officially by Infozip.

Quote
While the Bitwise people do make some choices that others don't agree with, they are some of the few developers actually doing something on our platform and though they do make some money doing it, considering the amount of time and effort they put in, much of the work is basically on a volunteer basis and it is hard to bitch about people doing stuff for free, even if not perfect.
They must be gods, usually only banks can make money in the Western world.

Quote
One of the decisions they've made is not to spend time trying to get their patches accepted up stream. Be nice if they did, but understandable as getting patches accepted can and usually is, time consuming.
I agree, applying some 2 minute patches to a 10 year old zip release can be very time-consuming. So there is no time left for compatibility checking any more or a functional test at all.

Quote
They have been very good about following licenses including being public with their fixes and other patches with many hosted at netlabs and others at Github.
In the case of zip and unzip, their trees are at http://trac.netlabs.org/ports/browser/zip/trunk and http://trac.netlabs.org/ports/browser/unzip/trunk with issue tracking also hosted at netlabs.
Sorry we are in 2018 now, I cannot see any reason for a fork of 10 year old code, where created binary packages don't follow the terms of the licence agreement and additionally are incomplete or break compatibility in different ways.

So my question to the original poster here: Which type of archive that should be greater than 4GB-1 was actually created? Which storage method was utilised? Without proper record information nobody can seriously help.

For some of the remaining OS/2 hobbyists: You can simply read ISO/IEC 21320-1:2015 before making claims that are totally untenable.

Valery Sedletski

  • Sr. Member
  • ****
  • Posts: 368
  • Karma: +2/-0
    • View Profile
Re: Creating archive > 4GiB from script
« Reply #9 on: December 02, 2018, 12:57:01 am »
2Bogdan:

> It's quite easy, these builds seem to be from a private codebase and not released officially by Infozip.

They are not private. They are publicly available from BWW GitHub.

> Sorry we are in 2018 now, I cannot see any reason for a fork of 10 year old code, where created binary packages don't follow the terms of the licence agreement and additionally are incomplete or break compatibility in different ways.

Do you think that fork is something bad? Anybody can fork any software with opensource license,
and add his own enhancements. Moreover, forks are encouraged with git, where multiple repositories
with the same program exist, and they may copy changes from one to another. Original OS/2 patches
from InfoZip are very old, and InfoZip can easily break the OS/2 version themself. I doubt they do
OS/2 version testing very much. So, there can be bugs. To fix these bugs, BWW needs extra patches.
Also, there are some enhancements like kLIBC symlinks support. I doubt that this feature present in
InfoZip version.

Binaries don't follow the license agreement? What do you mean? Both sources and binaries are
publicly available...

> I agree, applying some 2 minute patches to a 10 year old zip release can be very time-consuming. So there is no time left for compatibility checking any more or a functional test at all.

Why do you think it is 2-minute patches? Did you tried to build InfoZip yourself? I tried to build it
with OpenWatcom. It was very old version, and making the old OS/2 ACL patch work was very
hard. (There were some problems with calling 32-to-16-bit thunks. As some 16-bit API from
netapi.dll was called. I wonder how they work this around with 32-bit GCC build).
« Last Edit: December 02, 2018, 01:01:35 am by Valery Sedletski »

Bogdan

  • Jr. Member
  • **
  • Posts: 93
  • Karma: +1/-0
    • View Profile
Re: Creating archive > 4GiB from script
« Reply #10 on: December 02, 2018, 03:07:57 am »
2Bogdan:

> It's quite easy, these builds seem to be from a private codebase and not released officially by Infozip.

They are not private. They are publicly available from BWW GitHub.
I only know about the private Github company. Does it mean that BWW offers a similar service for the public?

Quote
> Sorry we are in 2018 now, I cannot see any reason for a fork of 10 year old code, where created binary packages don't follow the terms of the licence agreement and additionally are incomplete or break compatibility in different ways.

Do you think that fork is something bad? Anybody can fork any software with opensource license,
and add his own enhancements.
... under the restrictions of the licence agreement and the copyright. But that depends on local law.

Quote
Moreover, forks are encouraged with git, where multiple repositories
with the same program exist, and they may copy changes from one to another.
git is only a version control software that encourages nobody. I don't know about a special AI improvement or module that would offer this feature.

Quote
Original OS/2 patches from InfoZip are very old, and InfoZip can easily break the OS/2 version themself. I doubt they do
OS/2 version testing very much.
InfoZip releases of zip or unzip don't require any patches. They built on native OS/2 supported environments or can be cross-compiled from other development environments.

Quote
So, there can be bugs. To fix these bugs, BWW needs extra patches.
That's nothing special. Generally every software contains bugs that need to be fixed.

Quote
Also, there are some enhancements like kLIBC symlinks support. I doubt that this feature present in
InfoZip version.
Please provide the necessary information so I can answer the question. Do you mean symbolic links? The Zip format is from the PC DOS world and has only limited support for UNIX features. Hard link and symbolic link support can be provided with UNIX Extra Field, but seems to be useless for non-UNIX environments. Who wants to restore UNIX device names under OS/2? Can you provide a phone number of this support service or does it need a special contract?

Quote
Binaries don't follow the license agreement? What do you mean? Both sources and binaries are
publicly available...
Sorry I'm not a barrister or a spokesman for Infozip. Usually only 1% reads the licence agreement and 1% of them follows the terms.

Quote
Why do you think it is 2-minute patches?
Just a calculation of keystrokes by comparing with the sources of the release plus some extra time for creating a patch file. We use a plugin available for different environments which can automate this task, so we can monitor our Ukrainian workforce, and it saves a lot of money.

Quote
Did you tried to build InfoZip yourself?
I cannot count the platforms and different C compilers here, but mostly C/370 or the AIX C set.

Quote
I tried to build it
with OpenWatcom. It was very old version, and making the old OS/2 ACL patch work was very
hard. (There were some problems with calling 32-to-16-bit thunks. As some 16-bit API from
netapi.dll was called. I wonder how they work this around with 32-bit GCC build).
Which version of OpenWatcom was utilised? I remember of building it 20 years ago with Watcom C compiler for OS/2 and NT with the supplied makefile from an OS/2 hosted environment.

Valery Sedletski

  • Sr. Member
  • ****
  • Posts: 368
  • Karma: +2/-0
    • View Profile
Re: Creating archive > 4GiB from script
« Reply #11 on: December 02, 2018, 05:39:50 am »
2Bogdan:

> I only know about the private Github company. Does it mean that BWW offers a similar service for the public?

What do you mean? Most Github projects are opensource and provide sources and binaries
for free, including BWW. So, BWW repos are public, not private (only commercial sources are not
public, like InJoy, for example).

>>> Sorry we are in 2018 now, I cannot see any reason for a fork of 10 year old code, where created binary packages don't follow the terms of the licence agreement and additionally are incomplete or break compatibility in different ways.

>>    Do you think that fork is something bad? Anybody can fork any software with opensource license,
 and add his own enhancements.

>... under the restrictions of the licence agreement and the copyright. But that depends on local law.

InfoZIP seems to be under BSD-like license. BWW provide packages under the same license. So, what
terms they don't follow?

>>  Moreover, forks are encouraged with git, where multiple repositories
with the same program exist, and they may copy changes from one to another.

>git is only a version control software that encourages nobody. I don't know about a special AI improvement or module that would offer this feature.

Git and GitHub makes it easy to create and merge forks. Forks are just a convenient way to create
modified versions of sources. Fork doesn't denote anything bad. So, there's nothing bad that BWW
created a fork. This fork could be in the future merged into an original version, but this requires time.

> InfoZip releases of zip or unzip don't require any patches. They built on native OS/2 supported environments or can be cross-compiled from other development environments.

These patches are old and InfoZip cannot thoroughly test the OS/2 code with newer versions. Simply
because they don't use OS/2 for everyday  use. So, they can break something in new versions, without
noticing it. That's why newer versions can cointain bugs (related to combination of old OS/2 patches
with newer InfoZip code). So, this require fixes, which is done by BWW. So, no wonder if they require
modifications.

The OS/2 patches to InfoZip are very old, they were created by Kai Uwe Rommel in 90'ths. And I doubt
that this code was updated much by InfoZip.

>> Also, there are some enhancements like kLIBC symlinks support. I doubt that this feature present in
InfoZip version.

> Please provide the necessary information so I can answer the question. Do you mean symbolic links? The Zip format is from the PC DOS world and has only limited support for UNIX features. Hard link and symbolic link support can be provided with UNIX Extra Field, but seems to be useless for non-UNIX environments. Who wants to restore UNIX device names under OS/2?

This is you are kidding, or serious?  Yes, symbolic links. Don't you know that kLIBC contains symlink support?
No, it is not useless on non-UNIX environment. It is very useful in case you backup/restore your UNIX ports tree.
This tree contains many symlinks in /@unixroot/usr/bin subdirectory, for example. I suspect that you'll not like
if after restoring the UNIXROOT from backup, your symlinks are broken? And yes, InfoZIP contains support for
symlinks on UNIX environments (the same as ACL and EA's support on OS/2 platform), so, it can be desirable
to have symlinks support on kLIBC too. This is one reason for creating patches to original version.

>>Did you tried to build InfoZip yourself?

>I cannot count the platforms and different C compilers here, but mostly C/370 or the AIX C set.

So, you didn't tried to build the OS/2 version, ok.

>Which version of OpenWatcom was utilised? I remember of building it 20 years ago with Watcom C compiler for OS/2 and NT with the supplied makefile from an OS/2 hosted environment.

I used OW 1.9 I mean that there were some problems with calling a 16-bit API from netapi.dll for OS/2
ACL support. OW is good with building 16<->32 bits thunks, at least, I was able to create 16-bit wrappers for
32-bit DLL (a FS utility DLL from fat32.ifs, for example). So, this should work, though, I was unable to build
wrappers for ACL code in zip.exe. That's why I wonder how this was worked around in GCC builds. Maybe, they
just dropped the ACL code. I don't know.
« Last Edit: December 02, 2018, 05:52:41 am by Valery Sedletski »

Bogdan

  • Jr. Member
  • **
  • Posts: 93
  • Karma: +1/-0
    • View Profile
Re: Creating archive > 4GiB from script
« Reply #12 on: December 02, 2018, 06:55:08 pm »
> I only know about the private Github company. Does it mean that BWW offers a similar service for the public?

What do you mean? Most Github projects are opensource and provide sources and binaries
for free, including BWW. So, BWW repos are public, not private (only commercial sources are not
public, like InJoy, for example).
Sorry, I don't want to start a discussion about ideological issues. The definition of "public" seems to be different under different legal systems.

Quote
InfoZIP seems to be under BSD-like license. BWW provide packages under the same license. So, what
terms they don't follow?
Yes, the licence changed back in 1999, but please:
Note that the lack of the BSD "advertising clause" and the presence of the third and fourth restrictions are the two principal differences from the BSD license. Restriction #3 is intended only to protect us from having to support other people's code and from getting blamed for other people's bugs.

Quote
These patches are old and InfoZip cannot thoroughly test the OS/2 code with newer versions. Simply
because they don't use OS/2 for everyday  use. So, they can break something in new versions, without
noticing it. That's why newer versions can cointain bugs (related to combination of old OS/2 patches
with newer InfoZip code). So, this require fixes, which is done by BWW. So, no wonder if they require
modifications.
So which code breaks OS/2? Please use: http://infozip.sourceforge.net/zip-bug.html

Quote
The OS/2 patches to InfoZip are very old, they were created by Kai Uwe Rommel in 90'ths. And I doubt
that this code was updated much by InfoZip.
You're speaking about a time that predates Info-ZIP.

Quote
This is you are kidding, or serious?  Yes, symbolic links. Don't you know that kLIBC contains symlink support?
Sorry, I'm not an OS/2 systems programmer. The Programming Reference doesn't mention anything.

Quote
No, it is not useless on non-UNIX environment. It is very useful in case you backup/restore your UNIX ports tree.
This tree contains many symlinks in /@unixroot/usr/bin subdirectory, for example. I suspect that you'll not like
if after restoring the UNIXROOT from backup, your symlinks are broken? And yes, InfoZIP contains support for
symlinks on UNIX environments (the same as ACL and EA's support on OS/2 platform), so, it can be desirable
to have symlinks support on kLIBC too. This is one reason for creating patches to original version.
Zip and Unzip are programs for archiving and compression. The support for backup/restore is limited by several factors of the container format. There exist different third party extensions which can be used and Info-ZIP implements it this way.

Quote
So, you didn't tried to build the OS/2 version, ok.
Should I send you some generated object code and compiler list files?

Quote
>Which version of OpenWatcom was utilised? I remember of building it 20 years ago with Watcom C compiler for OS/2 and NT with the supplied makefile from an OS/2 hosted environment.

I used OW 1.9 I mean that there were some problems with calling a 16-bit API from netapi.dll for OS/2
ACL support. OW is good with building 16<->32 bits thunks,
It seems to be that v1.9 has some code generation problems. Perhaps for this reason v1.8 is mostly used by OS/2 developers (uniaud?).
It should not be necessary to do thunking by your own for the 32-bit OS/2 target. Only IBMLS 3.0 or later is supported, so there's no reason for interfacing with 16-bit libraries directly.

shmuel

  • Guest
Re: Creating archive > 4GiB from script
« Reply #13 on: December 02, 2018, 09:24:18 pm »
The installed packages are zip-3.0-8.oc00.i686.rpm and unzip-6.0-7.oc00.i686.rpm from Netlabs.

To clarify, without -s, zip seems to run normally:

Code: [Select]
ZIP -$9rSuyq -b W:\  --display-counts J:\M.zip M:\
zip of M:\ took 00:42:58 with rc=0

but unzip fails with
Code: [Select]
Fri 11-30-18 14:56:02{9}[h:\] unzip -t J:\M
Archive:  J:/M.zip
  End-of-central-directory signature not found.  Either this file is not
  a zipfile, or it constitutes one disk of a multi-part archive.  In the
  latter case the central directory and zipfile comment will be found on
  the last disk(s) of this archive.

See also http://trac.netlabs.org/ports/ticket/194

Bogdan

  • Jr. Member
  • **
  • Posts: 93
  • Karma: +1/-0
    • View Profile
Re: Creating archive > 4GiB from script
« Reply #14 on: December 03, 2018, 06:00:28 pm »
The installed packages are zip-3.0-8.oc00.i686.rpm and unzip-6.0-7.oc00.i686.rpm from Netlabs.

To clarify, without -s, zip seems to run normally:

Code: [Select]
ZIP -$9rSuyq -b W:\  --display-counts J:\M.zip M:\
zip of M:\ took 00:42:58 with rc=0

but unzip fails with

What happens when using a different unarchiver?

At least python -m zipfile -e should be available for this purpose.