本文介绍了iText升级后File.renameTo()返回false的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

在我们的一些应用程序中,我们已将iText版本从5.0升级到5.5.9.之后,我们面临File.renameTo调用中的问题.返回假.

We have upgraded iText version from 5.0 to 5.5.9 in few of our applications. After that we are facing issues in File.renameTo calls. Its returning false.

如果我们替换回旧版本的iText,它会正常工作.

If we replace back the previous version of iText, it is working fine.

一旦iText合并了pdf文件,这些pdf文件就不会移动到其他文件夹中.

Once iText merges the pdf's, those pdf's are not getting moved to different folder.

推荐答案

如果在Windows上运行代码,则文件可能未正确关闭,因此您需要依靠垃圾收集器来执行此操作.因此,您可以尝试在Linux上运行相同的程序来检查该假设.

If you are running your code on Windows, the file may not have been closed properly, and you rely on the garbage collector to do it.So you may try to run the same program on Linux to check this hypothesis.

这可能是iText中的回归,或者即使使用iText的先前版本,您的代码也被破坏了,但是由于实现方式的不同,垃圾回收器在调用File.renameTo之前就完成了工作.

This can be a regression in iText or your code was broken even with the previous version of iText, but with the difference of implementation, the garbage collector did its job before you called File.renameTo.

正如您对帖子的评论所言,单行File.renameTo(sourceFilePath, targetFilePath)不足以理解您的问题.我们需要上下文来理解问题.

As told on the comments of your post, the single line File.renameTo(sourceFilePath, targetFilePath) is not enough to understand your issue. We need the context to understand the problem.

提醒一下,Java文档说:

As a reminder the Java doc says :

请注意,Files类定义了move方法,以独立于平台的方式移动或重命名文件.

Note that the Files class defines the move method to move or rename a file in a platform independent manner.

这篇关于iText升级后File.renameTo()返回false的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持!

07-18 05:57
查看更多