FileSystemWatcher 工作完成了吗？
我在本地文件系统目录上设置了 FsWatcher。我只想知道文件何时添加到目录中，以便可以将它们移动到另一个文件系统。我似乎能够检测到第一个文件何时进入，但实际上我想知道给定复制操作中的所有文件何时完成。
如果我使用 Windows 资源管理器将文件从一个目录复制到另一个目录，资源管理器会告诉我传输还剩 n 秒，因此虽然每个文件的开始传输和结束传输都有一些活动，但看起来所有文件的开始传输和结束传输都有一些东西。
我想知道是否可以使用 .NET Framework 做类似的事情。我想知道“所有”文件何时存在，而不仅仅是“事务”中的单个文件。如果没有任何内容，也许我应该想出某种等待/反击的方法，以便仅在工作“完成”时才进行我的活动。
不确定我是否百分百理解这一点，请大家发表评论。
谢谢。
I setup a FsWatcher on a local filesystem directory. I only want to know when files are added to the directory so they can be moved to another filesystem. I seem to be able to detect when the first file is in, but actually I want to know when all files from a given copy operation are done.
If I used Windows Explorer to copy files from one directory to another, Explorer would tell me that there are n seconds left in the transfer, so while there is some activity for the begin-transfer and end-transfer for each file, it appears that there is something for the begin-transfer and end-transfer for all files.
I wonder if there is something similar that I can do just with the .NET Framework. I would like to know when "all" files are in and not just a single file in a "transaction". If there is nothing baked in, maybe I should come up with some kind of waiting/countering in order to only do my activity when a job is "done".
Not sure if I'm making 100% sense on this one, please anyone comment.
Thanks.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我过去实现这一点的方法是拥有一个具有特殊名称的“标记”文件，例如“end”。该文件始终是最后写入的文件，并用作多文件事务何时完成的指示器。如果只有一个线程正在写入这些文件集，那么这种方法就可以正常工作。
如果有许多线程，每个线程都可能正在写入一组文件，那么您需要以某种方式将每个“结束”文件与其正在标记的文件集关联起来。一种方法是在文件名中包含 GUID（或其他唯一标识符），例如
{ GUID1.file1.bin、GUID1.file2.bin、 GUID1.end }
{ GUID2.file1.bin, GUID2.file2.bin, GUID2.end }
另一个方法是将每组中的所有文件压缩到一个 ZIP 文件中，这样您只需监视单个文件。
The way I have implemented this in the past is to have a 'marker' file with a special name, e.g. 'end'. This file is always the last file written and serves as an indicator for when a multi file transaction is complete. This would work just fine if there is only one thread which is writing these sets of files.
If there are many threads, each of which may be writing a set of files, then you'd need to somehow associate each 'end' file with the set of files it is marking. One way to do this would be to include a GUID (or some other unique identifier) in the filenames, e.g.
{ GUID1.file1.bin, GUID1.file2.bin, GUID1.end }
{ GUID2.file1.bin, GUID2.file2.bin, GUID2.end }
Another way to do it is to zip all the files from each set into a single ZIP file so you only have to watch for single files.
不存在文件副本事务这样的事情。您只能监视目录中的单个文件更改。
资源管理器可以做到这一点，因为它知道您想要做什么（将这些 x 文件从此处复制到此处）。
您甚至不知道何时写入（或更一般地修改）该文件已完成。您必须尝试独占锁定该文件，以便知道您是唯一访问该文件的人。
AdamRalph 提到的 .end 文件技巧是唯一真正接近您想要执行的操作的技巧。
马里奥
There is no such thing as a transaction for a file copy. You can only watch for single file changes in a directory.
Explorer can do this because it knows what you want to do (copy these x files form here to here).
You do not even know when writing (or more generally modifiying) this file is done. You have to try to exclusively lock the file so you know you are the only one accessing it.
The .end file trick that AdamRalph mentions is the only trick that actually comes close to what you want to do.
hth
Mario
第一步，编写一个文件来指示要添加的文件列表，您的应用程序会拾取它，读取它，然后等待文件被写入。当最终文件写完后，您可以将它们打包并发送。这样，如果发起多个“交易”，就不会出现“最终文件”踩到彼此的脚趾。为指标文件提供一个已知的模式名称，以查找在常规文件中不太可能出现的模式，并提供一些方法来表明多个指标文件可能在相似的时间出现。
如果我要实现这样的东西，我可能会使用某种文件名，例如
~.tmp 我的文件系统观察程序将监视该格式名称的单个文件这又告诉另一个文件系统观察程序等待里面列出的文件。文件移出后，可以删除临时文件。这种方法可以轻松地线程化，这样每个观察者就不会互相干扰并传输/删除其他观察者正在处理的文件。
不过，正如前面所建议的，将文件压缩到单个存档中并使用它，在目的地解压它们可能会更有效。
What about writing a file indicating a list of the files to be added as the first step, your application picks it up, reads it and then waits on the files to be written. When the final file is written, you can package them up and send them off. This way if multiple "transactions" are initiated you don't have "end files" stepping on each others toes. Give the indicator file a known pattern name to look for that would be unlikely to occur in regular files and provide some means that multiple indicator files could occur at similar times.
If I were to implement something like this I would probably use some kind of filename like
~<ANOTHER-UNIQUE-GUID>.tmpmy file system watcher would be watching for a single file of that format name which in turn tells another file system watcher to wait on the files listed inside. When the files have been moved out, the temporary file can be deleted.This kind of approach can be threaded easily so that each of your watchers aren't stepping all over each other and transferring/removing files that other watchers are working on.
As suggested previously though, it may be more effective to zip up the files into a single archive and use that, unpackaging them at the destination.