Windows服务无法删除文件且Tomcat服务器上传失败求助

1. 检查文件句柄是否泄漏 #

服务生成zip后，大概率是文件被自身进程锁定未释放，导致上传失败或无法删除。

• 用Resource Monitor（资源监视器）的「CPU」→「关联句柄」，搜索生成的zip文件名，确认服务进程是否还持有该文件的句柄。
• 修复：生成zip时必须用using语句包裹流或ZipArchive对象（比如C#里using (var zip = ZipFile.Open(outputPath, ZipArchiveMode.Create)) { ... }），确保所有资源被正确释放，避免句柄残留。

2. 核对文件路径与权限差异 #

服务生成文件的目录权限和手动创建时可能完全不同：

• 系统账户运行服务时，默认工作目录可能是C:\Windows\System32，这里的文件权限继承严格，Tomcat的访问账户可能没有读取权限；而手动创建的文件通常在用户目录，权限更宽松。
• 检查服务生成的zip文件的NTFS权限：右键→属性→安全，对比手动创建文件的权限列表，确保Tomcat服务器的访问账户（比如共享目录的访问用户）有读取权限。
• 修复：指定服务生成文件到权限明确的目录（比如C:\Temp\ServiceUploads），给该目录添加Everyone或Tomcat访问账户的「读取/写入」权限，同时确保服务进程对该目录有完全控制权限。

3. 验证zip文件的格式合法性 #

服务生成的zip可能存在格式损坏，导致Tomcat端拒绝接收：

• 把服务生成的zip手动复制到本地，尝试手动上传，如果同样失败，说明是zip生成逻辑有问题。
• 用7-Zip打开服务生成的zip，确认能正常解压；如果解压报错，检查压缩代码是否遗漏文件、是否用了非标准的压缩参数。
• 修复：调整压缩逻辑，使用标准的ZipArchiveMode.Create模式生成zip，避免用Update模式导致文件结构异常。

4. 排查服务的网络访问上下文 #

服务运行账户的网络凭据和手动操作时不同：

• 手动上传用的是当前登录用户的网络权限，而系统账户/管理员账户可能没有访问Tomcat服务器共享目录的权限（即使在同网络）。
• 测试：在服务上传代码中显式指定访问Tomcat共享的凭据（用户名/密码），不要依赖服务账户的默认凭据；或者把服务运行账户改成有Tomcat共享访问权限的域用户/本地用户。
• 修复：如果是通过SMB上传，用New-SmbMapping（PowerShell）或NetworkCredential（.NET）在上传前建立带凭据的网络连接。

5. 解决上传后的文件删除问题 #

上传后无法删除文件，多数是Tomcat进程在占用该文件：

• Tomcat会自动解压上传的zip/war文件，此时文件被Tomcat的Java进程锁定，本地服务无法删除。
• 验证：上传后等待5-10分钟（给Tomcat足够的解压时间）再尝试删除，或者停止Tomcat服务后删除，看是否成功。
• 修复：上传后延迟执行删除操作；或者修改Tomcat的conf/server.xml配置，关闭自动解压功能（设置unpackWARs="false"），上传后手动触发解压，再删除源文件。

内容的提问来源于stack exchange，提问作者Gokul