Home_area_content_templates_fullupdate.zip is no valid archive

Hello SDN,
I just tried to follow the steps to complete the Collaboration-Configuration on my Sneak Preview SP15. When I tried to Upload the ICE-Package als said in http://help.sap.com/saphelp_erp2004/helpdata/en/be/6ca0404dd52b54e10000000a1550b0/content.htm
I get an IO-Error. I alos cannot open the ZIP-file in WinRAR, so I think the file is somwehow damaged. Does anybody have a working version of this file?

Hi Fabian,
I recently discovered the same problem: I downloaded the file using IE and the zip was corrupted.
I was about to went made as I tried it with about 3 different portal instances and always had the same issue.
Then I downloaded the file with firefox, and it worked
I do not know what exactly the problem is, but seems like an IE <-> SAP EP issue.
best regards,
Stefan Brauneis

Similar Messages

Input file not a valid archive

Hi
Originally the application was written in CVI 6.0. I have now created a completly new project and workspace and added all the files.
The compilation works fine. But the error message I get when linking (build) is " error: Input file is not a valid archive: 'c:\Projects\........\bin\i7000.lib'. "
With another library I get the same problem: "uart.lib"
The other lib-files just work fine.
I saw in an old post a solution: to just recreate the project which I did. But it didn't work in my case.
Any help?
Cheers Andreas
Solved!
Go to Solution.

Hi Maha
Thanks for your investigations.
The LIBs I use "i7000.lib" resp. "i7000.dll" and "uart.lib" resp. "uart.dll" have an age of about 10 years AND are from a vendor/manufacturer that doesn't support these LIBs anymore.
So first of all we don't have access to the original c code and therefore can't compile/build any new LIB. And most probably they were not made with CVI.
Then as a second thought: these LIB/DLLs follow the standard and conventions of a microsoft LIB/DLL. So this should be some standard interface, even for CVI.
Third, I think there are 1000s of such old (Microsoft standard) libraries still in use all over the industry. Therefore I cannot understand why CVI 2013 is not capabable of linking them to the rest of the code.
Maybe I miss something in my thoughts. Like you mention already an older CVI is not a solution for us. Do you see maybe the possibility of another workaround?
For your understanding I attach the 2 LIBs in a zip-file. Maybe it helps?
Anyway have a nice wekend.
Andreas
Attachments:
i7000.zip ‏96 KB

Cannot open file it does not appear to be a valid archive

While trying to download Oracle 8i/9i i keep getting the message
'Cannot open file it does not appear to be a valid archive'
Can someone please help me with this
i have tried to download this 10 times already but of no use
Thanks
Rimpy

I was getting a similar, if not the same, problem when I used IE 5.5 to download the file. It used to start extracting then stop about 75% of the way through and dump some error about the archive being corrupt and not being able to open it. After installing Netscape and disabling the download manager application, I was able to download and extrac the zip files with winzip 8 and also winrar without any problems.

Orale 9i client for woindows does not appear to be a valid archive

Can download the zip file but cannot open it because
it does not appear to be a valid archive.
Any hint ?
Thanxs, Reno

use winRAR

Problem installing Personal 8.1.7, 'not a valid archive file'??

So that we may better diagnose DOWNLOAD problems, please provide the following information.
- Server name : ??
- Filename : nt817personal.zip
- Date/Time Mon 2/9-2002
- Browser + Version : IE 5
- O/S + Version : Win 2000 (upgraded from Win NT)
- Error Msg : "Cannot open file, it does not appear to be a valid archive. If you downloaded this file, try downloading the file again" ...coming from WinZip 7.0(I've tried downloading again a couple of time, no difference!)
Help!

Dear Bertil,
I assume that you are Oracle rep. hope this is right.
here we go:
for last 5 days or so i can't get anything from oracle9i download page. this includes 9 rel 2 for linux/nt:
( i know this thread is for 8i, but looks like you are the only one guy here)
- Server name : download-east.oracle.com
- Filename : all filenames for oracle 9i rel 2 for Linux and nt
- Date/Time all week of 2nd of Sept 2002 , from 6 -12 pm EST
- Browser + Version : IE 5 , Netsapce 4.73-7
- O/S + Version : Win 2000 , linux 7.3 with latest patchests
- Error Msg : All types of errors starting with host can't be find, document doesn't have any data, 1,5k/sec speed only on the 3rd file from the set for Linux.
file is missing , 500 error.
i can understand that you are might have problems because of whatever... but for ONE WEEK - are you working for government?
you don't have people to fix this? i think - nobody cares!
take care.

Downloaded Zip files not valid??

I have just downloaded 8.1.6 documentation libraries and find that the zipped files are being reported as being bad or not a valid archive. Perhaps someone from Oracle might get around to providing feedback when they have finally sobered up after xmas.
Regds
Fergus

go to...
http://otn.oracle.com/documentation/oracle8i_arch_816.html
under heading ...
Oracle8i Release 8.1.6 Documentation Libraries
the link...
A83908_02 - Oracle8i Server Online Documentation CD-ROM Release 2 (8.1.6) for Microsoft Windows NT
regds
Fergus

Adobe AIR Launchpad - Not a valid archived project

I am trying to import the Adobe AIR Launchpad application into Adobe Flash Builder and receive "Not a valid archived project" error.
I am using;
Adobe AIR Launchpad      version   airlaunchpad_p8_3-0-1_081911
Adobe Flash Builder          version   4.6 (Flex 4.6.0)
Adobe Flash Player           version   11.4.402.287
Adobe AIR Runtime          version   3.5.0.600

You are talking about browser based AIR help and you are saying that in RoboHelp 9 you are not seeing AIR as an option to create the layout?
See www.grainge.org for RoboHelp and Authoring tips
@petergrainge

When a zip file is un-archived, where does it go?

When a zip file is un-archived, where does it go?

Alan
It is in your downloads folder if that is where you saved it to. If you're unsure of where the unzipped file/application is simply open finder and do a search for it. You can also do a Spotlight search for it as well.
Joseph

The sqldeveloper-v1.0.0.zip file does not appear to be a valid archive.

Hi Guys!
Cud ne1 tell me why does the sqldeveloper-v1.0.0.zip file not show ne contents to me after I try to unzip/open it? I've a 98SE m/c.
Actually I know that sql developer wud work only on higher platforms, but currently i'm jst downloading the setup.
Pls help me on this, also tell me if the sql developer is available elsewhere on Oracle.com website.
Thanks & Regards.
-Rahul K.

In the page of download exists the information on the size of each available archive.
It compares this value with the one of the archive that you have in its machine.
Perhaps the archive has not been transferred completely.

Corrupt (?) zipped files from "Create Archive"

I am repeatedly having trouble with files I zip using "create archive." Whether it's fonts or images, the recipients are not able to use the files I send (they seem to uncompress, but aren't readable). This is happening often enough that I wonder if there is a problem with the software. I didn't find this question asked when I did a search.
thanks!

Hi, casperr. Welcome to the Discussions.
1. Are the recipients using Windows? If so, you may want to purchase a copy of StuffIt Deluxe, which can create archives that are both Windows-friendly and self-extracting.
2. Have you tried opening the archives you have created with Create Archive to see if the contents of the archive you've created are AOK before sending them? That will help you determine if the problem is on your Mac, with the transmission, or a problem on the other user's computer.
3. You might want to enquire as to how the recipients are unzipping the archives you have sent that they are finding problematic.
Good luck!
Dr. Smoke
Author: Troubleshooting Mac® OS X

Validating Archive Link secKey from C#

All,
I have written a archive link service using C#, and all is working great except when security is enabled. I have been reading around and the most fesible solution appears to be using BouncyCastle to do the validation, however I keep getting the error 'message-digest attribute value does not match calculated value'.
The querystring is:
?info&pVersion=0045&contRep=IT&docId=001&accessMode=R&authId=CN%3DSAPHTTPCS000.pse,OU%3DI0020112593,OU%3DSAPWebAS,O%3DSAPTrustCommunity,C%3DDE&expiration=20100528121019&secKey=MIIBWQYJKoZIhvcNAQcCoIIBSjCCAUYCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHATGCASUwggEhAgEBMHYwcTELMAkGA1UEBhMCREUxHDAaBgNVBAoTE1NBUCBUcnVzdCBDb21tdW5pdHkxEzARBgNVBAsTClNBUCBXZWIgQVMxFDASBgNVBAsTC0kwMDIwMTEyNTkzMRkwFwYDVQQDExBTQVBIVFRQQ1MwMDAucHNlAgEAMAkGBSsOAwIaBQCgXTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMDA1MjgxMDEwMTlaMCMGCSqGSIb3DQEJBDEWBBTYx2fOt9K%2Fdui50Fz8sEgMiZSj1TAJBgcqhkjOOAQDBC8wLQIVAJ3iEzSAz%2BCHSmr7x6k7rrhrWhy3AhRQlSwXVnfYSp1%2FnWZc80R%2FXaAFWw%3D%3D
Which gives me the following string to validate with: IT001rCN=SAPHTTPCS000.pse,OU=I0020112593,OU=SAPWebAS,O=SAPTrustCommunity,C=DE20100528121019
(note: I have tried leavng the accessMode parameter in the same case as URL with no avail)
Here is the code I am trying to use to validate the values
byte[] auth = System.Text.Encoding.ASCII.GetBytes(authString.ToString());
                    Org.BouncyCastle.Cms.CmsSignedData csd = new Org.BouncyCastle.Cms.CmsSignedData(new Org.BouncyCastle.Cms.CmsProcessableByteArray(auth), sk);
                    Org.BouncyCastle.Cms.SignerInformationStore store = csd.GetSignerInfos();
                    System.Collections.ICollection signers = store.GetSigners();
                    foreach (Org.BouncyCastle.Cms.SignerInformation sinfo in signers)
                        try
                            //Sometimes failures error
                            if (!sinfo.Verify(cert)) return false;
                        catch(Exception ex) { return false; }
                    return true;
The error occurs on the sinfo.Verify line.
Any ideas where I am going wrong would be greatly appreciated.

Hi,
I am also facing the same problem.
Everything seems to be in line with SAP documentation, but the secKey is still not validating properly.
First I compute the hash from the message. The text form of message is similar on both sides of communication (SAP and Content Server). Then the message goes to be signed. It results in PKCS#7 message encoded with base64 sent in secKey by SAP.
On CS side I decode secKey and parse PKCS7 message. I find there messageDigest and the message itself. There is a first confusion: should the messageDigest or the message be the subject for verification? I put both of them to verification and it fails all the time.
Has anyone any ideas what can be wrong in this way?

Windows Explorer misreads large-file .zip archives

   I just spent about 90 minutes trying to report this problem through
the normal support channels with no useful result, so, in desperation,
I'm trying here, in the hope that someone can direct this report to some
useful place.
   There appears to be a bug in the .zip archive reader used by Windows
Explorer in Windows 7 (and up, most likely).
   An Info-ZIP Zip user recently reported a problem with an archive
created using our Zip program. The archive was valid, but it contained
a file which was larger than 4GiB. The complaint was that Windows
Explorer displayed (and, apparently believed) an absurdly large size
value for this large-file archive member. We have since reproduced the
problem.
   The original .zip archive format includes uncompressed and compressed
sizes for archive members (files), and these sizes were stored in 32-bit
fields. This caused problems for files which are larger than 4GiB (or,
on some system types, where signed size values were used, 2GiB). The
solution to this fundamental limitation was to extend the .zip archive
format to allow storage of 64-bit member sizes, when necessary. (PKWARE
identifies this format extension as "Zip64".)
   The .zip archive format includes a mechanism, the "Extra Field", for
storing various kinds of metadata which had no place in the normal
archive file headers. Examples include OS-specific file-attribute data,
such as Finder info and extended attributes for Apple Macintosh; record
format, record size, and record type data for VMS/OpenVMS; universal
file times and/or UID/GID for UNIX(-like) systems; and so on. The Extra
Field is where the 64-bit member sizes are stored, when the fixed 32-bit
size fields are too small.
   An Extra Field has a structure which allows multiple types of extra
data to be included. It comprises one or more "Extra Blocks", each of
which has the following structure:
       Size (bytes) | Description
      --------------+------------
            2       | Type code
            2       | Number of data bytes to follow
        (variable) | Extra block data
   The problem with the .zip archive reader used by Windows Explorer is
that it appears to expect the Extra Block which includes the 64-bit
member sizes (type code = 0x0001) to be the first (or only) Extra Block
in the Extra Field. If some other Extra Block appears at the start of
the Extra Field, then its (non-size) data are being incorrectly
interpreted as the 64-bit sizes, while the actual 64-bit size data,
further along in the Extra Field, are ignored.
   Perhaps the .zip archive _writer_ used by Windows Explorer always
places the Extra Block with the 64-bit sizes in this special location,
but the .zip specification does not demand any particular order or
placement of Extra Blocks in the Extra Field, and other programs
(Info-ZIP Zip, for example) should not be expected to abide by this
artificial restriction. For details, see section "4.5 Extensible data
fields" in the PKWARE APPNOTE:
      http://www.pkware.com/documents/casestudies/APPNOTE.TXT
   A .zip archive reader is expected to consider the Extra Block type
codes, and interpret accordingly the data which follow. In particular,
it's not sufficient to trust that any particular Extra Block will be the
first one in the Extra Field. It's generally safe to ignore any Extra
Block whose type code is not recognized, but it's crucial to scan the
Extra Field, identify each Extra Block, and handle it according to its
type.
   Here are some relatively small (about 14MiB each) test archives which
illustrate the problem:
      http://antinode.info/ftp/info-zip/ms_zip64/test_4g.zip
      http://antinode.info/ftp/info-zip/ms_zip64/test_4g_V.zip
      http://antinode.info/ftp/info-zip/ms_zip64/test_4g_W.zip
   Correct info, from UnZip 6.00 ("unzip -lv"):
Archive: test_4g.zip
Length   Method    Size Cmpr    Date    Time   CRC-32   Name
4362076160 Defl:X 14800839 100% 05-01-2014 15:33 6d8d2ece test_4g.txt
Archive: test_4g_V.zip
Length   Method    Size Cmpr    Date    Time   CRC-32   Name
4362076160 Defl:X 14800839 100% 05-01-2014 15:33 6d8d2ece test_4g.txt
Archive: test_4g_W.zip
Length   Method    Size Cmpr    Date    Time   CRC-32   Name
4362076160 Defl:X 14800839 100% 05-01-2014 15:33 6d8d2ece test_4g.txt
(In these reports, "Length" is the uncompressed size; "Size" is the
compressed size.)
   Incorrect info, from (Windows 7) Windows Explorer:
Archive        Name          Compressed size   Size
test_4g.zip    test_4g.txt         14,454 KB   562,951,376,907,238 KB
test_4g_V.zip test_4g.txt         14,454 KB   8,796,110,221,518 KB
test_4g_W.zip test_4g.txt         14,454 KB   1,464,940,363,777 KB
   Faced with these unrealistic sizes, Windows Explorer refuses to
extract the member file, for lack of (petabytes of) free disk space.
   The archive test_4g.zip has the following Extra Blocks: universal
time (type = 0x5455) and 64-bit sizes (type = 0x0001). test_4g_V.zip
has: PWWARE VMS (type = 0x000c) and 64-bit sizes (type = 0x0001).
test_4g_W.zip has: NT security descriptor (type = 0x4453), universal
time (type = 0x5455), and 64-bit sizes (type = 0x0001). Obviously,
Info-ZIP UnZip has no trouble correctly finding the 64-bit size info in
these archives, but Windows Explorer is clearly confused. (Note that
"1,464,940,363,777 KB" translates to 0x0005545500000400 (bytes), and
"0x00055455" looks exactly like the size, "0x0005" and the type code
"0x5455" for a "UT" universal time Extra Block, which was present in
that archive. This is consistent with the hypothesis that the wrong
data in the Extra Field are being interpreted as the 64-bit size data.)
   Without being able to see the source code involved here, it's hard to
know exactly what it's doing wrong, but it does appear that the .zip
reader used by Windows Explorer is using a very (too) simple-minded
method to extract 64-bit size data from the Extra Field, causing it to
get bad data from a properly formed archive.
   I suspect that the engineer involved will have little trouble finding
and fixing the code which parses an Extra Field to extract the 64-bit
sizes correctly, but if anyone has any questions, we'd be happy to help.
   For the Info-ZIP (http://info-zip.org/) team,
   Steven Schweda

> We can't get the source (info-zip) program for test.
   I don't know why you would need to, but yes, you can:
      http://www.info-zip.org/
      ftp://ftp.info-zip.org/pub/infozip/src/
You can also get pre-built executables for Windows:
      ftp://ftp.info-zip.org/pub/infozip/win32/unz600xn.exe
      ftp://ftp.info-zip.org/pub/infozip/win32/zip300xn.zip
> In addition, since other zip application runs correctly. Since it should
> be your software itself issue.
   You seem to misunderstand the situation. The facts are these:
   1. For your convenience, I've provided three test archives, each of
which includes a file larger than 4GiB. These archives are valid.
   2. Info-ZIP UnZip (version 6.00 or newer) can process these archives
correctly. This is consistent with the fact that these archives are
valid.
   3. Programs from other vendors can process these archives correctly.
I've supplied a screenshot showing one of them (7-Zip) doing so, as you
requested. This is consistent with the fact that these archives are
valid.
   4. Windows Explorer (on Windows 7) cannot process these archives
correctly, apparently because it misreads the (Zip64) file size data.
I've supplied a screenshot of Windows Explorer showing the bad file size
it gets, and the failure that occurs when one tries to use it to extract
the file from one of these archives, as you requested. This is
consistent with the fact that there's a bug in the .zip reader used by
Windows Explorer.
   Yes, "other zip application runs correctly." Info-ZIP UnZip runs
correctly. Only Windows Explorer does _not_ run correctly.

Urgent Help: Test Zip Archive

Hi everybody, I'd like to know if there's a safe way to check if a compressed file (zip file) is a valid archive or not.
Sometimes WinZip tool says that the archive is not valid, there's a way to have the same answer by java code?
Can java makes the same valid archive test as WinZip tool?
Anybody has some code examples?
Thanks a lot!!!

java.util.zip.ZipFile's constructor should throw a ZipException if the zip is not valid. I dont know whether the checks are exactly the same as winzip.

Cannot unzip .zip even with Archive Utility

Hi,
I have problem unzipping a .zip file. When I use the Archive Utility to unzip it, it yields a file with the same name with .zip.cpgz on its end. When I subsequently make another trial - to unzip this new file, it yields the very same file only with .zip.cpgz 2 in the end of its name. A repeated process (now with any of these files, either original, first .cpgz or second .cpgz 2) yields a file with appropriate .cpgz #. Repeating the process further seemed to me futile. I hope writing here would in the long run yield an unzipped original .zip file.
Many thanks for your help,
pwyll.

You probably won't see this, but did you ever zip a file during this time and then unzip it with another program and find data missing? The same thing happened to me where I zipped an assignment with archive utility, then when I tried to unzip it it would just make copy after copy. Once it was unzipped by my professior there was missing data. THen when I downloaded another program to unzip the original zipped file, that data was missing, too! I tried it again and zipping the file kep deleting part of my file!

Spotlight comments and zip archives

There have been a few posts in this forum that point out the difficulties of using Spotlight with zip files but it is only now that I have discovered (the hard way) that zipping files into an archive actually removes (or loses) my Spotlight comments.
The Spotlight comments I lost were all on jpg and gif files. Should I therefore be considering storing metadata actually within each graphic file rather than using Spotlight?

The so-called "Spotlight Comments" in the GetInfo window are just the old Finder Comments, and are actually stored in the .DS_Store file of the folder containing the files. If you zip the folder with the files in it the comments will be preserved. However, it is just too easy to forget about this. You really want all your important metadata as part of the file itself, so if you have a graphics program that will add metadata information to the files that would be the best way to go.
Francine
Francine
Schwieder

Home_area_content_templates_fullupdate.zip is no valid archive

Similar Messages

Maybe you are looking for