当前位置：文江博客话题详情

在 Java 中跟踪文件夹更改的最简单方法是什么？

发布于 2024-07-25 01:17:43 字数 129 浏览 6 评论 0原文

我有一组源文件夹。我使用 Java 类从这些文件夹中构建分发文件。我想用 Java 编写另一个小类，它每半秒运行一次，检查文件夹中的任何文件是否已更改，如果是，则运行构建类。

那么，如何轻松检测文件夹已被修改呢？

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

多谢你的绝情让我学会死心 2024-08-01 01:17:44

我认为您需要检查目录和子目录修改时间（对于添加/删除的文件）和文件修改时间（对于每个文件中的更改）。

编写一个递归例程来检查目录的修改时间以及是否已更改，以及每个文件。然后检查目录内容，并递归调用任何子目录。您应该能够检查是否有比上次运行检查时更长的修改时间。

请参阅 File.lastModified()

编辑：自从我写了上面的内容后，Java 7 就推出了

回复收藏 0 原文

假情假意假温柔 2024-08-01 01:17:44

如果您可以被允许使用Java 7，它支持独立于平台的目录/文件更改通知。

JNA 有一个跨平台更改通知示例此处。不知道你会发现它有多容易。

回复收藏 0 原文

输什么也不输骨气 2024-08-01 01:17:44

我不知道这是否有什么好处，但是这是一个人对这个问题的看法。

听起来 .NET 有内置的东西： FileSystemWatcher

更新：感谢 kd304，我刚刚了解到 Java 7 将具有相同的功能< /a>. 今天对您没有多大好处，除非您可以使用预览版。

回复收藏 0 原文

梦在夏天 2024-08-01 01:17:44

您需要观察每个文件并跟踪File.lastModified属性，并检查File.exists标志以及一些简单的递归遍历目录结构。

回复收藏 0 原文

‘画卷フ 2024-08-01 01:17:44

是的，有许多可用的目录侦听器，但它们都相对复杂，并且大多数涉及线程。

几天前，我与我们的一位工程师就是否允许（在 Web 应用程序中）创建一个新线程（在 Web 应用程序中）仅仅为了监视目录树进行了一场近乎激烈的讨论。最后我同意了他的观点，但由于我想出的东西如此之快，以至于不需要听众。注意：仅当您不需要知道哪个文件已更改，而只需知道某个文件已更改时，下面描述的解决方案才有效。

您向以下方法提供文件集合（例如，通过 Apache IO 的 FileUtils.listFiles() 方法获得），这将返回集合的哈希值。如果添加、删除任何文件或其修改日期发生更改，则哈希值将会更改。

在我的测试中，50K 文件在 3Ghz Linux 机器上大约需要 750 毫秒。触摸任何文件都会改变哈希值。在我自己的实现中，我使用了不同的哈希算法（DJB），它的速度要快一些，但这就是它的要点。我们现在只需存储哈希并每次检查，因为它非常轻松，特别是对于较小的文件集合。如果有任何变化，我们会重新索引该目录。在我们的应用程序中，观察者的复杂性并不值得。

/**
 *  Provided a directory and a file extension, returns
 *  a hash using the Adler hash algorithm.
 *   
 * @param files  the Collection of Files to hash.
 * @return       a hash of the Collection.
 */
public static long getHash( Collection<File> files )
{
    Adler32 adler = new Adler32();
    StringBuilder sb = new StringBuilder();
    for ( File f : files ) {
        String s = f.getParent()+'/'+f.getName()+':'+String.valueOf(f.lastModified());
        adler.reset();
        adler.update(s.getBytes());
        sb.append(adler.getValue()+' ');
    }
    adler.reset();
    adler.update(sb.toString().getBytes());
    return adler.getValue();
}

是的，还有改进的空间（例如，我们使用哈希方法而不是内联它）。上面的内容是从我们的实际代码中截取的，但应该可以让您很好地了解我们做了什么。

Yes, there are a number of available listeners for directories, but they're all relatively complicated and most involve threads.

A few days ago I ended up in an almost heated discussion with one of our engineers over whether it was a permissible creating a new thread (in a web application) simply to monitor a directory tree. In the end I agreed with him, but by virtue of coming up with something so fast that having a listener is unnecessary. Note: the solution described below only works if you don't need to know which file has changed, only that a file has changed.

You provide the following method with a Collection of Files (e.g., obtained via Apache IO's FileUtils.listFiles() method) and this returns a hash for the collection. If any file is added, deleted, or its modification date changed, the hash will change.

In my tests, 50K files takes about 750ms on a 3Ghz Linux box. Touching any of the files alters the hash. In my own implementation I'm using a different hash algorithm (DJB) that's a bit faster but that's the gist of it. We now just store the hash and check each time as it's pretty painless, especially for smaller file collections. If anything changes we then re-index the directory. The complexity of a watcher just wasn't worth it in our application.

/**
 *  Provided a directory and a file extension, returns
 *  a hash using the Adler hash algorithm.
 *   
 * @param files  the Collection of Files to hash.
 * @return       a hash of the Collection.
 */
public static long getHash( Collection<File> files )
{
    Adler32 adler = new Adler32();
    StringBuilder sb = new StringBuilder();
    for ( File f : files ) {
        String s = f.getParent()+'/'+f.getName()+':'+String.valueOf(f.lastModified());
        adler.reset();
        adler.update(s.getBytes());
        sb.append(adler.getValue()+' ');
    }
    adler.reset();
    adler.update(sb.toString().getBytes());
    return adler.getValue();
}

And yes, there's room for improvement (e.g., we use a hash method rather than inlining it). The above is cut down from our actual code but should give you a good idea what we did.

回复收藏 0 原文