Application X-zip-compressed File Extension

[Dion Worles]

TheZIP file format was developed to compress and archive data. It is a popularly used format for archiving and/or compressing data. A file in ZIP format is likely to contain one more files inside. The files inside the ZIP formatted file can be of any format and they do not affect the package file (the ZIP file) in any way. The files stored within it may be compressed to save space or they may be stored "as-is". Multiple compression algorithms have been used with the ZIP file format so far but the "Deflate" method has proven to be the most popular till date.

The ZIP file format was originally developed for an archiving application called PKZIP in 1985. It was made through advancing the ARC format that had been developed earlier. Since then, the format has gained a lot of popularity and the two major OS platforms Microsoft Windows (versions since 1998) and Apple"s Mac OS (versions since 10.3) have made it the de facto compression tool. A lot of other applications use this format with their own assigned extensions, like Firefox (.xpi) and JAVA (.jar).

I have the "Attachments on the filesystem" plugin Enabled, I tried with the database option with the same results. Also I made a "clean install" with this guide -osticket-from-1-14-x-to-1-15-x/, and the error continues.

All the troubleshooting above was made following other threads with similar issues, but not quite the same, so I think my problem could be around permissions. On that I can also say that I have not SElinux or mod_security configured, and all the files and directories have a "www-data" read, write on the osTicket folder.

First thing I would check is: Admin panel -> Settings -> Tickets

Scroll all the way down to the bottom e and click on the Config button to the right of Ticket Attachment Settings.

Ensure that the file extension is listed in Additional File Type Filters

Click Save, and then retest adding the file to a ticket.

Thanks for your answer @ntozier , I forgot to add that to the list of actions that I did or checked before posting this. Anyway, I tried adding the pdf extension with the same results. Still trying to figure it out from the server, I think the app is ok. Thanks again for your time.

Hi, I tried your suggestion but same results.

I would try to migrate to another server this week, restoring a db backup maybe to a new installation or other things that come to my mind so I can isolate my problem.

I had a similar issue but managed to fix it. In my case it was a MIME type mismatch for .zip files. My computer used application/x-zip-compressed while osTicket expected application/zip. It appears there are many different MIME types in use for .zip files. And it appears osTicket compares MIME type instead of file extensions. Curious design choice; especially considering the UI allowes additional file extension to be added (to no apparent affect.)

We used to verify the mime-types all the time to prevent someone from doing a mime-type bypass and other similar attacks. If you enable the setting it will check the given mime-type from the upload request against the file's true mime-type which is loaded from the server OS. You can see the method we use to check here:

As a test, I have zipped up a file and sent it in an attachment to the e-mail account where the Flow is set up. I already successfully set up a gateway. However, the "Create File [File System]" step does not appear to be outputting the zip file properly.

In the trigger "When a new email arrives", I see the attachment's ContentType is properly read as "application/x-zip-compressed". However, in the output of the "Create File" step, the file either comes out as "application/octet-stream" when I don't enter in an extension (like .zip) in the "File name" portion of this step or it comes out as "application/x-zip-compressed" when I enter in ".zip" at the end of the file name. The latter result appears desirable except when I go to my directory to open the newly written ".zip" file, it says "Windows cannot open the folder. The Compressed (zipped) Folder 'C:\xxx xxxx xxx\xxxxx\xxxx\xxxx\test.zip' is invalid."

Hypothetically, if a tarball were an official media type and following conventions, its MIME type would be application/tar (file extension .tar) and its compressed version would be application/tar+gzip (file extensions .tar.gz and .tgz).

ZIP is an archive file format that supports lossless data compression. A ZIP file may contain one or more files or directories that may have been compressed. The ZIP file format permits a number of compression algorithms, though DEFLATE is the most common. This format was originally created in 1989 and was first implemented in PKWARE, Inc.'s PKZIP utility,[2] as a replacement for the previous ARC compression format by Thom Henderson. The ZIP format was then quickly supported by many software utilities other than PKZIP. Microsoft has included built-in ZIP support (under the name "compressed folders") in versions of Microsoft Windows since 1998 via the "Plus! 98" addon for Windows 98. Native support was added as of the year 2000 in Windows ME. [citation needed] Apple has included built-in ZIP support in Mac OS X 10.3 (via BOMArchiveHelper, now Archive Utility) and later. Most free operating systems have built in support for ZIP in similar manners to Windows and macOS.

ZIP files generally use the file extensions .mw-parser-output .monospacedfont-family:monospace,monospace.zip or .ZIP and the MIME media type application/zip.[1] ZIP is used as a base file format by many programs, usually under a different name. When navigating a file system via a user interface, graphical icons representing ZIP files often appear as a document or other object prominently featuring a zipper.

The .ZIP file format was designed by Phil Katz of PKWARE and Gary Conway of Infinity Design Concepts. The format was created after Systems Enhancement Associates (SEA) filed a lawsuit against PKWARE claiming that the latter's archiving products, named PKARC, were derivatives of SEA's ARC archiving system.[3] The name "zip" (meaning "move at high speed") was suggested by Katz's friend, Robert Mahoney.[4] They wanted to imply that their product would be faster than ARC and other compression formats of the time.[4] The earliest known version of .ZIP File Format Specification was first published as part of PKZIP 0.9 package under the file APPNOTE.TXT in 1989.[citation needed] By distributing the zip file format within APPNOTE.TXT, compatibility with the zip file format proliferated widely on the public Internet during the 1990s.[5]

The .ZIP File Format Specification has its own version number, which does not necessarily correspond to the version numbers for the PKZIP tool, especially with PKZIP 6 or later. At various times, PKWARE has added preliminary features that allow PKZIP products to extract archives using advanced features, but PKZIP products that create such archives are not made available until the next major release. Other companies or organizations support the PKWARE specifications at their own pace.

The .ZIP file format specification is formally named "APPNOTE - .ZIP File Format Specification" and it is published on the PKWARE.com website since the late 1990s.[11] Several versions of the specification were not published. Specifications of some features such as BZIP2 compression, strong encryption specification and others were published by PKWARE a few years after their creation. The URL of the online specification was changed several times on the PKWARE website.

WinZip, starting with version 12.1, uses the extension .zipx for ZIP files that use compression methods newer than DEFLATE; specifically, methods BZip, LZMA, PPMd, Jpeg and Wavpack. The last 2 are applied to appropriate file types when "Best method" compression is selected.[28][29]

In April 2010, ISO/IEC JTC 1 initiated a ballot to determine whether a project should be initiated to create an ISO/IEC International Standard format compatible with ZIP.[30] The proposed project, entitled Document Packaging, envisaged a ZIP-compatible 'minimal compressed archive format' suitable for use with a number of existing standards including OpenDocument, Office Open XML and EPUB.

.ZIP files are archives that store multiple files. ZIP allows contained files to be compressed using many different methods, as well as simply storing a file without compressing it. Each file is stored separately, allowing different files in the same archive to be compressed using different methods. Because the files in a ZIP archive are compressed individually, it is possible to extract them, or add new ones, without applying compression or decompression to the entire archive. This contrasts with the format of compressed tar files, for which such random-access processing is not easily possible.

A directory is placed at the end of a ZIP file. This identifies what files are in the ZIP and identifies where in the ZIP that file is located. This allows ZIP readers to load the list of files without reading the entire ZIP archive. ZIP archives can also include extra data that is not related to the ZIP archive. This allows for a ZIP archive to be made into a self-extracting archive (application that decompresses its contained data), by prepending the program code to a ZIP archive and marking the file as executable. Storing the catalog at the end also makes possible hiding a zipped file by appending it to an innocuous file, such as a GIF image file.

The .ZIP format uses a 32-bit CRC algorithm and includes two copies of each entry metadata to provide greater protection against data loss. The CRC-32 algorithm was contributed by David Schwaderer and can be found in his book "C Programmers Guide to NetBIOS" published by Howard W. Sams & Co. Inc.[32]

A ZIP file is correctly identified by the presence of an end of central directory record which is located at the end of the archive structure in order to allow the easy appending of new files. If the end of central directory record indicates a non-empty archive, the name of each file or directory within the archive should be specified in a central directory entry, along with other metadata about the entry, and an offset into the ZIP file, pointing to the actual entry data. This allows a file listing of the archive to be performed relatively quickly, as the entire archive does not have to be read to see the list of files. The entries within the ZIP file also include this information, for redundancy, in a local file header. Because ZIP files may be appended to, only files specified in the central directory at the end of the file are valid. Scanning a ZIP file for local file headers is invalid (except in the case of corrupted archives), as the central directory may declare that some files have been deleted and other files have been updated.

3a8082e126