Java implementation zip compression need to pay attention to the problem

Recently, the Institute of the two-dimensional code platform for 2.0 upgrade and transformation. Stepped on a huge pit yesterday. I hereby record ...

Demand from the Institute editor in the bulk download QR code, the system backend needs to download the QR code for renaming and zip packaging compression.

System testing when the discovery: the first time a bulk download, that is, the compressed file has not been generated, the background can be compressed files and provide download. However, the second time to request bulk download, the webpage has been unresponsive ...

After a few attempts, it still didn't respond. Had to look at the Tomcat log, surprised to find that the log was only half written, the second half lost (the first time this happened) ==| | |

But God bless, part of the write shows: No space left device.

I rub! is the hard drive full? Yesterday there was a margin of 68%. It's gone today?

The swift DF du command goes up. The du display is not full. But DF shows already 100%. It's a hair-blow.

Google, found that du DF does not show the same result because the file handle is not released, the file is still occupied by the process. DF counts the actual hard disk usage, and Du does not include files that have been flagged for deletion but are still occupied by the process and are not actually physically deleted. (File physical deletion and identity as deleted is not a concept)

Then call Lsof | grep deleted view File usage: Sure enough, the zip file size has broken through the horizon.

It appears that Java has made a mistake in packaging the zip file. Trapped in a dead loop???

Because zip packaging source is provided by colleagues, and not in-depth understanding. Had to go through the package and see what the logic was.

After a toss. Finally found the problem.

As an example:

A file has 1.jpg 2.jpg two files

The B.zip file was generated when a bulk download was requested for the first time.

So there's 1.jpg 2.jpg B.zip file under the A folder.

According to the source code logic, the A folder is searched first, and then each file is added to the zip file one by one.

Then, on the second request, on the surface, it may be rough to assume that B.zip will be overwritten and replaced with a new B.zip, which includes 1.jpg 2.jpg and the old B.zip.

Wrong!

When the file is being written, it is always the same b.zip operation!

Break down the process. The first step is to traverse the A folder to get a list of three file names: 1 2 b

When you create a new B, the old B file is deleted, but the file name of B remains in the file list above.

Next, add 1 to New B and add 2 to new B.

When adding the old B, actually in the new B operation!! If viewed from the point of view of the file read and write pointer, as shown in

Read Write

1 2 (12)

As you can see, because it is working on the same file, the read pointer is never going to catch up with write, or EOF, and the write is endless.

So fix the bug by placing the files you want to pack and the target zip files under two different folders.

Just the sauce ~

Java implementation zip compression need to pay attention to the problem