Zip file is unreadable. Cause: java.util.zip.ZipException: invalid entry size

本文介绍了一种在Sterling File Gateway中处理超过4GB大小的ZIP64文件时遇到的异常情况及其解决办法。主要问题是Java标准库不支持ZIP64格式,导致文件无法正确读取。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

Zip file is unreadable. Cause: java.util.zip.ZipException: invalid entry size

Technote (troubleshooting)


Problem(Abstract)

A zip file is received to be routed and unzipped by the routing template in Sterling Filegateway(SFG) and it fails to route with:

FG_0455 Zip file is unreadable. Cause: java.util.zip.ZipException: invalid entry size.

This mainly happens with larger files (larger than 4GB) but it can also happen with smaller zip files if the file format is ZIP64.

This could also occur when using the compression service in a business process.

Symptom

File is not routed and the following error is in filegateway.log

[2015-02-12 13:02:13.955] ERROR Arrived File Failed
[2015-02-12 13:02:13.955] ERROR [1423764133955] Zip file is unreadable. Cause: java.util.zip.ZipException: invalid entry size (expected 778774528 but got 5073741824 bytes).
[2015-02-12 13:02:13.955] ERRORDTL [1423764133955]com.sterlingcommerce.fg.exception.FileGatewayRouteException: Zip file is unreadable. Cause: java.util.zip.ZipException: invalid entry size (expected 778774528 but got 5073741824 bytes).
at com.sterlingcommerce.fg.exception.FileGatewayRouteException.newZipUnreadable(FileGatewayRouteException.java:51)
at com.sterlingcommerce.fg.router.RouteIdentifier.extractZipEntry(RouteIdentifier.java:665)
at com.sterlingcommerce.fg.router.RouteIdentifier.crackOpenZip(RouteIdentifier.java:630)
at com.sterlingcommerce.fg.router.RouteIdentifier.getZipTOC(RouteIdentifier.java:601)
at com.sterlingcommerce.fg.router.RouteIdentifier.getMatches(RouteIdentifier.java:512)
at com.sterlingcommerce.fg.router.RouteIdentifier.findRoutePlansForChannel(RouteIdentifier.java:227)
at com.sterlingcommerce.fg.router.RouteIdentifier.findRoutePlans(RouteIdentifier.java:163)
at com.sterlingcommerce.fg.router.ArrivedFile.determineRoutes(ArrivedFile.java:544)
at com.sterlingcommerce.fg.router.ArrivedFile.startRoute(ArrivedFile.java:211)
at com.sterlingcommerce.fg.router.FileGatewayRouter.processRoute(FileGatewayRouter.java:136)
at com.sterlingcommerce.fg.services.FileGatewayRouteService.primitiveProcessData(FileGatewayRouteService.java:76)
at com.sterlingcommerce.fg.services.TransformingRouterService.processData(TransformingRouterService.java:79)
at com.sterlingcommerce.woodstock.workflow.activity.engine.ActivityEngineHelper.invokeService(ActivityEngineHelper.java:1818)
at com.sterlingcommerce.woodstock.workflow.activity.engine.ActivityEngineHelper.nextMainLogic(ActivityEngineHelper.java:631)
at com.sterlingcommerce.woodstock.workflow.activity.engine.ActivityEngineHelper.next(ActivityEngineHelper.java:362)
at com.sterlingcommerce.woodstock.workflow.queue.WorkFlowQueueListener.doWork(WorkFlowQueueListener.java:442)
at com.sterlingcommerce.woodstock.workflow.queue.WorkFlowQueueListener.run(WorkFlowQueueListener.java:236)
at com.sterlingcommerce.woodstock.workflow.queue.WorkFlowQueueListener.onMessage(WorkFlowQueueListener.java:197)
at com.sterlingcommerce.woodstock.workflow.queue.WorkFlowQueueListener.onMessage(WorkFlowQueueListener.java:184)
at com.sterlingcommerce.woodstock.workflow.queue.wfTransporter.run(wfTransporter.java:444)
at com.sterlingcommerce.woodstock.workflow.queue.BasicExecutor$Worker.run(BasicExecutor.java:508)
at java.lang.Thread.run(Thread.java:804)
Caused by: java.util.zip.ZipException: invalid entry size (expected 778774528 but got 5073741824 bytes)
at java.util.zip.ZipInputStream.readEnd(ZipInputStream.java:414)
at java.util.zip.ZipInputStream.read(ZipInputStream.java:206)
at java.io.FilterInputStream.read(FilterInputStream.java:118)
at com.sterlingcommerce.fg.router.RouteIdentifier.extractZipEntry(RouteIdentifier.java:656)
... 20 more


Cause

This has to do with the file format being ZIP64 which is currently not supported in any of the java.util.Zip classes.
The maximum file size made possible by the original, open source Zip file specification was 4 gigabytes. This limit applied both to the uncompressed and compressed sizes of files inside Zip files (.zip or .zipx), and also to the total size of a Zip file itself. To work around this, the ZIP64 extensions were introduced - but there has not been support for ZIP64 in the Java Zip classes.

If smaller than 4GB files run into this issue, then it is possible that the file format used by the compression client may still be using ZIP64 explicitly.

Diagnosing the problem

Analyze the file format of the zip file being unzipped in SI/SFG. If it is ZIP64 (or larger than 4GB) then this is the limitation within the JDK.

Resolving the problem

Customers are advised to use the Command Line Adapter 2 to run an external program that supports the ZIP64 extensions (e.g., on Windows the latest version of WinZip supports ZIP64) to decompress the files.


http://www-01.ibm.com/support/docview.wss?uid=swg21698692

<think>我们正在处理TrueNAS中硬盘/dev/sdc出现4个待处理扇区(Currently unreadable (pending) sectors)的问题。根据引用[1]和[3],我们知道待处理扇区是硬盘故障的早期预警。引用[2]表明,有时这些扇区可能会被硬盘自身修复(重新映射),但需要主动触发修复过程。 解决方案步骤: 1. **确认硬盘状态**: 通过SMART命令检查/dev/sdc的详细状态,特别是待处理扇区和重新分配扇区的计数。 命令: ```bash smartctl -a /dev/sdc | grep -E 'Current_Pending_Sector|Reallocated_Sector_Ct' ``` 如果输出显示`Current_Pending_Sector`为4,并且`Reallocated_Sector_Ct`有值(或为零),则说明有4个扇区等待处理。 2. **尝试修复待处理扇区**: 运行SMART测试来触发硬盘的自我修复机制: - 首先运行离线测试(offline test): ```bash smartctl -t offline /dev/sdc ``` 这个测试会尝试重新读取那些待处理的扇区,如果读取成功,则标记为正常;如果失败,则重新映射到备用扇区。 - 然后运行长测试(long test): ```bash smartctl -t long /dev/sdc ``` 长测试会对整个硬盘进行扫描,可能需要数小时(取决于硬盘大小)。在测试期间,硬盘性能可能会下降。 等待测试完成后,再次检查SMART属性: ```bash smartctl -a /dev/sdc | grep -E 'Current_Pending_Sector|Reallocated_Sector_Ct' ``` 期望的结果是:`Current_Pending_Sector`变为0,而`Reallocated_Sector_Ct`可能增加(增加的数量就是被成功重新映射的扇区数)。如果待处理扇区没有减少,则说明这些扇区无法修复,需要更换硬盘。 3. **数据备份和验证**: 在尝试修复期间或之后,立即进行以下操作: - 备份重要数据:使用ZFS的发送/接收功能将数据备份到另一个存储池或服务器。 ```bash zfs send poolname/dataset@snapshot | ssh user@backup_server "zfs receive backup_pool/dataset" ``` - 运行ZFS Scrub来验证和修复数据一致性: 在TrueNAS Web界面中,进入“存储”->“池”,选择相应的池,然后点击“Scrub池”->“立即开始”。或者使用命令行: ```bash zpool scrub poolname ``` 使用`zpool status`监控Scrub进度,直到完成。 4. **更换硬盘(如果修复失败)**: 如果待处理扇区仍然存在(即没有归零),那么这块硬盘已经不可靠,需要更换。 - 物理更换硬盘:关机后更换硬盘,然后重新启动。 - 在TrueNAS Web界面中替换硬盘: 1. 进入“存储”->“池” 2. 点击池的“状态”按钮(通常是一个图标,显示池的状态) 3. 找到状态为“DEGRADED”或“FAULTED”的磁盘(即/dev/sdc) 4. 点击该磁盘,选择“替换” 5. 选择新硬盘,然后开始替换(重建)过程。 - 监控重建进度: ```bash zpool status ``` 等待重建完成(resilver完成)。 5. **预防措施**: - 设置定期SMART测试:在TrueNAS的“任务”->“SMART测试”中,为所有硬盘添加短测试(每天)和长测试(每周)。 - 监控硬盘温度:确保硬盘工作温度在安全范围内(通常低于45°C),高温会加速硬盘老化。 - 检查SATA数据线和电源连接:如果SMART报告中出现`UDMA_CRC_Error_Count`(引用[3]中未出现,但作为常规检查),则可能需要更换数据线或尝试不同的SATA接口。 注意:待处理扇区是硬盘物理问题的征兆,即使暂时修复成功,该硬盘的可靠性也已经下降。建议在修复后持续监控该硬盘,并尽快在合适时机更换。 引用说明: - 引用[1]和[3]显示了待处理扇区的出现,引用[2]则显示了一个成功修复的例子(待处理扇区归零)。因此,我们按照上述步骤尝试修复,但也要做好更换硬盘的准备。 相关问题: 1. 如何解读TrueNAS的SMART报告中`Reallocated_Sector_Ct`和`Pending_Sector`的区别? 2. ZFS存储池重建(Resilvering)失败该如何处理? 3. TrueNAS中如何配置自动替换故障硬盘的预警阈值?</think>### TrueNAS 硬盘 /dev/sdc 出现 4 个待处理扇区的解决方案 根据您的日志信息(引用[1][3]),硬盘 `/dev/sdc` 检测到 **4 个待处理扇区**(Currently unreadable pending sectors)。这是硬盘物理故障的早期预警,需立即处理以避免数据丢失。以下是系统化解决流程: --- #### **1. 确认硬盘状态** ```bash smartctl -a /dev/sdc | grep -A 10 "Current_Pending_Sector" ``` - 预期输出示例: ``` 197 Current_Pending_Sector 0x0012 100 100 000 Old_age Always FAILING_NOW 4 ``` - **关键指标**: - `Current_Pending_Sector = 4`(待修复扇区数) - `Reallocated_Sector_Ct`(已重映射扇区数,若为0说明尚未修复)[^1] --- #### **2. 触发硬盘自我修复** 分三步强制硬盘尝试修复坏扇区: ```bash # 步骤1:运行离线测试(强制重映射) smartctl -t offline /dev/sdc # 步骤2:执行长测试(全面扫描坏块) smartctl -t long /dev/sdc # 步骤3:等待4小时后验证结果(引用[2]显示修复可能需数小时) smartctl -a /dev/sdc | grep -E "Pending_Sector|Reallocated_Sector" ``` **修复成功标志**(如引用[2]所示): - ✅ `Current_Pending_Sector` 归零 - ✅ `Reallocated_Sector_Ct` 增加(新增值≈原待处理扇区数) > ⚠️ 若数值未变化(如引用[1][3]持续告警),说明扇区无法修复,需更换硬盘。 --- #### **3. 紧急数据保护** 1. **立即备份数据**: ```bash zfs send tank/dataset@emergency_backup | ssh user@backup_server "zfs receive backup/tank" ``` 2. **执行ZFS Scrub**: ```bash zpool scrub tank # 替换tank为您的池名称 zpool status -v # 监控修复进度 ``` - 若出现类似引用[4]的XFS报错,说明文件系统已受损,需优先备份再修复 --- #### **4. 更换硬盘(若修复失败)** 1. **物理替换**:关机后更换 `/dev/sdc` 硬盘 2. **TrueNAS Web界面操作**: - 存储 → 池 → 状态 → 选择 `/dev/sdc` → 替换 → 选择新硬盘 3. **监控重建**: ```bash zpool status | grep -A 5 "scan: resilver" ``` 重建时间 ≈ 硬盘容量/100MB/s(如4TB硬盘需约11小时) --- #### **5. 根本原因分析与预防** | 可能原因 | 解决措施 | 检查命令 | |-------------------------|-----------------------------------|------------------------------| | 物理坏道(>70%案例) | 更换硬盘 | `smartctl -a /dev/sdc` | | 写入中断(强制关机) | 配置UPS电源 | 检查系统日志 `journalctl` | | SATA线/接口故障 | 更换数据线或切换主板接口 | `smartctl -a /dev/sdc \| grep UDMA_CRC` | | 高温导致介质老化 | 改善机箱散热(目标<45°C) | `smartctl -A /dev/sdc \| grep Temp` | **长期维护建议**: - 启用定期SMART测试: **TrueNAS任务 → SMART测试 → 添加** - 短测试:每日 - 长测试:每周 - 设置告警阈值:当 `Pending_Sector > 0` 时自动邮件通知(引用[3]) > 📌 **关键结论**: > 即使成功修复(如引用[2]),出现待处理扇区的硬盘可靠性已显著下降,建议6个月内更换[^1]。 --- #### **技术说明:待处理扇区机制** 当硬盘检测到读取失败的扇区时: 1. 标记为 "Pending Sector"(待处理) 2. 下次写入时尝试重映射到保留区(G-list) 3. 若重映射失败,则升级为永久坏道 保留区容量有限(通常约1000扇区),因此4个待处理扇区已属高风险状态[^1]。 ---
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值