Install app:9tGpLNniojkX6rVCdDi7t6BK1sMqDjw32RFhxQUReiFH failed, err: (ZipError, invalid Zip archive: Invalid zip header, None)

[lizhihongTest]

Describe the bug
The default dec-app drops in the beta environment, the installation fails:

[2023-04-15 09:10:50.622562 +00:00] ERROR [ThreadId(10)] [service/app-manager/src/app_controller.rs:154] install app:9tGpLNniojkX6rVCdDi7t6BK1sMqDjw32RFhxQUReiFH failed, err: (ZipError, invalid Zip archive: Invalid zip header, None)

This seems to be an exception when downloading the file, unable to open the compressed package, reinstalling and reusing the wrong zip file, and not re-downloading

app-manager_3874026_rCURRENT.log

[lurenpluto]

For files already downloaded locally, is it possible to add a step to check the hash? Avoid the situation where you download the wrong file and it doesn't work, but there is no way to delete it and try again

[weiqiushi]

Consider that when the installation fails, the more likely cause of the error is .

• DecApp source OOD, or the source file error, resulting in download failure or decompression failure
• There is a problem with the user's OOD network, resulting in download failure
• There is a problem with the user's OOD environment, resulting in failure to execute the install command.

None of these reasons can be solved by a simple retry. Therefore, the strategy here is to notify the user that the app has entered the InstallFailed state and let the user retry manually.

In the process of manual retry, the DecApp file will be downloaded again, regardless of whether it has been downloaded before.

[weiqiushi]

The logs show app 9tGpLNniojkX6rVCdDi7t6BK1sMqDjw32RFhxQUReiFH, version 1.1.2. The web.zip file of the source file failed to unzip and retrying 3 times all failed to unzip. I will try to reproduce this error

[weiqiushi]

First, I ran app-tool.exe app show 9tGpLNniojkX6rVCdDi7t6BK1sMqDjw32RFhxQUReiFH，to get the dir id for version 1.1.2, it returns DirId 7jMmeXZck7E3dZvmsP9TYr2t29DePFiaeyAnhvRHsojp. I also get this id from above log.
Then, i use cyfs-client.exe get cyfs://7jMmeXZck7E3dZvmsP9TYr2t29DePFiaeyAnhvRHsojp/web.zip web.zip, to download the web.zip file to local, and try to decompress it. its success

[weiqiushi]

This is caused by an old problem:

DecApp is downloaded using the NamedDataClient module. Its logic is independent of the CYFS protocol stack. The data download is achieved by communicating with the file-manager and chunk-manager services of the target OOD

Here, chunk-manager, the first conceptual implementation of CYFS NDN, lacks some error handling logic.

After NamedDataClient finishes downloading data from the external network, it will try to save the data in the local chunk-manager, and the next time it downloads the same file, it will try to get the data from the local chunk-manager first.

When chunk-manager stores data, it does not delete the wrong file if the data write fails.
When chunk-manager fetches data from disk, it also does not do any data validation

These two errors lead to the fact that if chunk-manager fails to write the data when it writes to the disk because the disk is full, it will leave a 0-byte file on the disk. The next time it reads the file, it will directly read the 0-byte data and return it, causing the download to fail all the time.

[lurenpluto]

This is caused by an old problem:

DecApp is downloaded using the NamedDataClient module. Its logic is independent of the CYFS protocol stack. The data download is achieved by communicating with the file-manager and chunk-manager services of the target OOD

Here, chunk-manager, the first conceptual implementation of CYFS NDN, lacks some error handling logic.

After NamedDataClient finishes downloading data from the external network, it will try to save the data in the local chunk-manager, and the next time it downloads the same file, it will try to get the data from the local chunk-manager first.

When chunk-manager stores data, it does not delete the wrong file if the data write fails. When chunk-manager fetches data from disk, it also does not do any data validation

These two errors lead to the fact that if chunk-manager fails to write the data when it writes to the disk because the disk is full, it will leave a 0-byte file on the disk. The next time it reads the file, it will directly read the 0-byte data and return it, causing the download to fail all the time.

chunk-manager and file-manager are two very "old" services. Under the new NDN logic of cyfs-stack, these two services actually have a lot of problems, such as the problem of not being able to delete the error file in time is one of them.

These two services and relative components should be considered for refactoring based on the new NDN mechanism, including

• file-manager
• chunk-manager
• NamedDataClient component

[weiqiushi]

file-manager and chunk-manager as the first conceptual implementation of CYFS NON and NDN, when the NON and NDN implementations within the CYFS stack mature, these two services should be deprecated and NamedDataClient should be re-implemented as a version that relies on the functionality of the CYFS stack

I will discuss it in a new issue

[weiqiushi]

Issue #220 will tracking the replacement of file-manager and chunk-manager

[lizhihongTest]

This issuse has been tested and verified in version 1.1.0.751.