4

私は次のサブを持っています：

  Private Sub Watcher_Changed(ByVal sender As System.Object, ByVal e As FileSystemEventArgs)
        If Path.GetExtension(e.Name) = ".p2p" Then
            Exit Sub
        Else
            Try
                ' multiple change events can be thrown. Check that file hasn't already been moved.
                While Not File.Exists(e.FullPath)
                    Exit Try
                End While

                ' throw further processing to a BackGroundWorker
                ChangedFullPath = e.FullPath
                ChangedFileName = e.Name

                FileMover = New BackgroundWorker
                AddHandler FileMover.DoWork, New DoWorkEventHandler(AddressOf ProcessFile)
                FileMover.RunWorkerAsync()
            Catch ex As Exception
                MessageBox.Show(ex.Message)
            End Try

        End If
    End Sub

ファイルが FTP によってアップロードされているときに、まだ複数の変更されたファイルの通知を受け取ります。

Try を変更して、過去 (時間) 内に発生した場合は変更通知もスローするようにします。たとえば、3 秒としましょう。些細なことのはずなのに、どういうわけか今日は思い浮かばず、Google で見つけた答えが頭に浮かびません。

ありがとう、スコット

4

7 に答える 7

10

数年前に FTP フォルダーにダンプされたファイルをアップロードするサービスを作成しました。問題を解決するために私が行ったいくつかのことを以下に示します。

  1. 私はすべての NotifyFilters をテストし、重複する通知をカットするものを選択しました ( NotifyFilters.Sizeのみを使用すると、作成されたすべてのファイルに対して信頼できる通知が得られ、ほぼすべての重複した通知が排除されました)。
  2. Watcher_Changed イベントでは、イベント引数に含まれるファイルを無視し、現在フォルダーにあるすべてのファイルを処理しました。フォルダー内のすべてのファイルをキューに追加しようとしましたが、それらが既にキューにある場合は、以下の 3 をスキップします。
  3. 見つかった一意の新しいファイルごとに新しいスレッドをスピンオフします。私のスレッドはファイルのロックを取得しようとしますが、それができない場合は、他のプロセスがまだアクセスしていることを意味するため (まだアップロード中など)、スレッドはスリープ状態になり、短い間隔で再試行します。
  4. ファイルが完全に処理されると、スレッドが最後に行うことは、ファイルをアーカイブ フォルダーに移動し、キューから削除することです。これにより、誤って再度処理されることはありません。

これは私にとってはうまくいったようで、そのサービスは、私がその仕事を辞めるまでの数か月間、ファイルを確実にアップロードしてくれました。

于 2008-12-20T06:11:55.623 に答える
3

私は以前に正確な状況に遭遇し、タイマーメカニズムを実装して、ファイルが「解決」するのを待つか、書き込みイベントが x 時間停止するのを待ちました。

少し不器用ですが、うまくいきました。

于 2008-12-19T21:14:41.357 に答える
3

同様の状況がありました。ただし、ファイルをバッチで書き込むシステムは一時名を使用し、それが完了すると「実際の」名前に変更しました。あなたの ftp クライアントは似たようなことをすることができますか? 可能であれば、新しいファイル名を確認し、拡張子またはプレフィックスで確認できます。予想される最終的なファイル名形式でない場合は、無視できます。

于 2008-12-19T21:03:44.310 に答える
2

注意すべきことの 1 つは、ファイルにアクセスすると、「アクセス時間」などのファイル プロパティの 1 つが変更される可能性があることです。通知フィルターが正しく設定されていない場合は、別のイベントが発生する可能性があります。

于 2008-12-31T15:21:41.483 に答える
1

私はこれと同じ問題を抱えていました。コードを介してアップロードされたファイルを保存していて、削除と作成が毎回2回発生しました。私が確認しなければならなかったのは、処理を行う前にファイルがそこにあったことだけでした。

private void fsw_Created(object sender, FileSystemEventArgs e)
{
   if (File.Exists(e.FullPath))
   {
      //process the file here
   }
}
于 2009-05-26T20:25:02.497 に答える
0

今日、変更時に構成ファイルを自動的にリロードしようとしているときに、同じ問題が発生しました。ファイルの MD5 ハッシュを計算して、ファイルが実際に変更されたかどうかを確認し、ハッシュが異なる場合にのみリロードしました。これが、重複を除外で​​きる唯一の決定的な方法でした。

タイマー メカニズムを使用して変更通知を除外することを簡単に考えましたが、ピートのように感じましたが、あまりにも不潔な解決策だと感じました。

LastWrite の時刻の変更のみを監視しようとしましたが、うまくいきませんでした。私はまだ重複した通知を受け取っていました。

于 2014-11-26T18:47:45.840 に答える