文件系统观察程序 - 文件夹已删除

发布于 2024-08-31 16:30:53 字数 166 浏览 7 评论 0原文

我正在编写一项服务来监视不同文件夹中是否存在不同的文件...... 我正在使用文件系统观察程序来获取事件。

作为部署的一部分,所监视的文件夹之一会被删除并不时创建新文件夹。

结果,服务抛出错误并停止...

是否可以捕获此类错误并通过服务在新文件夹上重新创建文件监视程序?

I´m writing on an service to watch for the existence different files in diffent folders...
I´m using filesystemwatchers to get the events.

As a part of the deployment one of the watched folders is deleted and new created from time to time.

As a result the service throws an error and is stopped...

Is it possible to catch that kind of error and recreate the filewatcher on the new folder by the service?

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

扫码二维码加入Web技术交流群

发布评论

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

评论(2

海之角 2024-09-07 16:30:53

捕获已删除的事件,然后使用定时轮询重新安排以观看新事件?

我现在手头没有编译器,但我敲出了这个伪代码:

using System;
using System.IO;


    public class Watcher : IDisposable{

    void Dispose(){ watcher.OnDeleted -= onDelete; }


    string file;
    FileSystemWatcher watcher; 
    FileSystemEventHandler onDelete;

        public class Watch(string file, FileSystemEventHandler onDelete) {
        this.file = file;   
        watcher = new FileSystemWatcher{ Path = file }
        this.OnDelete = onDelete;
        watcher.Deleted += onDelete;
        watcher.NotifyFilter = ...; // looking for delete event;
            // Begin watching.
            watcher.EnableRaisingEvents = true;
    }
    }


    public static class watch {

    Watcher watcher;

       public static void Main() {



        watcher = new Watcher("somedir", ondeleted);
        SetUpChangeWatchers();
        while(true){
            // stuff!

        }

        CleanUpChangeWatchers();    
       }    


    private static void ondeleted(object source, RenamedEventArgs e){ 
        CleanUpChangeWatchers();
        watcher.Dispose();

        while(!directoryRecreated(file)){
            Thread.Sleep(...some delay..);
        }
        SetUpChangeWatchers();  
        watcher = new Watcher("somedir", ondeleted);

    }
}

Catch the deleted event, and then reschedule with timed poll to watch a new one?

I don't have a compiler to hand right now but I knocked up this pseudo code:

using System;
using System.IO;


    public class Watcher : IDisposable{

    void Dispose(){ watcher.OnDeleted -= onDelete; }


    string file;
    FileSystemWatcher watcher; 
    FileSystemEventHandler onDelete;

        public class Watch(string file, FileSystemEventHandler onDelete) {
        this.file = file;   
        watcher = new FileSystemWatcher{ Path = file }
        this.OnDelete = onDelete;
        watcher.Deleted += onDelete;
        watcher.NotifyFilter = ...; // looking for delete event;
            // Begin watching.
            watcher.EnableRaisingEvents = true;
    }
    }


    public static class watch {

    Watcher watcher;

       public static void Main() {



        watcher = new Watcher("somedir", ondeleted);
        SetUpChangeWatchers();
        while(true){
            // stuff!

        }

        CleanUpChangeWatchers();    
       }    


    private static void ondeleted(object source, RenamedEventArgs e){ 
        CleanUpChangeWatchers();
        watcher.Dispose();

        while(!directoryRecreated(file)){
            Thread.Sleep(...some delay..);
        }
        SetUpChangeWatchers();  
        watcher = new Watcher("somedir", ondeleted);

    }
}
指尖微凉心微凉 2024-09-07 16:30:53

您可以使用 .deleted 事件来处理此问题。但是,如果删除分配给 filesystemwatcher.Path 的目录,可能会导致错误。解决这个问题的一种方法是将监视目录的父目录分配给 filesystemwatcher.Path。然后它应该捕获 .deleted 事件中的删除。

如果您尝试访问刚刚删除的目录,则处理程序内部也可能会出现错误。发生这种情况时,您可能无法获得正常的断点,这似乎是由删除本身引起的。

You can handle this with the .deleted event. However, if you delete the directory assigned to the filesystemwatcher.Path, it may cause an error. One way around this is to assign the parent of the watched directory to filesystemwatcher.Path. Then it should catch the deletion in the .deleted event.

It is also possible to have an error inside the handler if you try to access the directory just deleted. When this happens, you may not get the normal breakpoint and it seems like it's caused by the deletion itself.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文