26

呼び出し中FileInfo(path).LastAccessTimeまたはFileInfo(path).LastWriteTime書き込み中のファイルを呼び出すと、最後に書き込まれた時刻（つまり現在）ではなく、ファイルが作成された時刻が返されます。

この情報を取得する方法はありますか？

編集：これまでのすべての応答に。私は試しRefresh()ていませんでしたが、それもしません。ファイルの書き込みが開始された時刻が返されます。同じことが静的メソッドにも当てはまり、の新しいインスタンスを作成しますFileInfo。

Codymanixに答えがあるかもしれませんが、私は（Windows 7を使用して）Windows Serverを実行しておらず、設定をテストする場所がわかりません。

編集2：この関数が機能していないように見えるのは誰も面白いとは思いませんか？

4

7 に答える 7

16

FileInfo値は一度だけロードされてからキャッシュされます。現在の値を取得するにはRefresh()、プロパティを取得する前に呼び出します。

f.Refresh();
t = f.LastAccessTime;

現在の値を取得する別の方法は、Fileクラスの静的メソッドを使用することです。

t = File.GetLastAccessTime(path);
于 2009-09-19T15:08:42.787 に答える
9

Windows Vista 以降、最終アクセス時刻は既定では更新されません。これは、ファイル システムのパフォーマンスを向上させるためです。ここで詳細を見つけることができます：

http://blogs.technet.com/b/filecab/archive/2006/11/07/disabling-last-access-time-in-windows-vista-to-improve-ntfs-performance.aspx

コンピューターで最終アクセス時刻を再度有効にするには、次のコマンドを実行できます。

fsutil 動作セット disablelastaccess 0

于 2010-12-07T20:29:32.637 に答える
4

Refresh()プロパティにアクセスする直前に呼び出してみましたか（キャッシュされた値を取得しないようにするため）？それでもうまくいかない場合は、Explorerが同時に表示する内容を確認しましたか？Explorerが間違った情報を表示している場合、それはおそらく実際には対処できないものです。たとえば、ファイルハンドルが閉じられたときにのみ情報が更新される可能性があります。

于 2009-09-19T15:07:43.460 に答える
4

MSDNから：

FileSystemInfoは、最初に呼び出されると、Refreshを呼び出し、APIにキャッシュされた情報を返し、属性などを取得します。以降の呼び出しでは、Refreshを呼び出して、情報の最新のコピーを取得する必要があります。

FileSystemInfo.Refresh（）

アプリケーションが書き込みを行うアプリケーションである場合は、書き込むデータの各バッファの間にLastWriteTimeプロパティを自分で設定して、ファイルに「触れる」必要があると思います。いくつかの擬似コード：

while(bytesWritten < totalBytes)
{
   bytesWritten += br.Write(buffer);
   myFileInfo.LastWriteTime = DateTime.Now;
}

これが書き込みパフォーマンスにどれほど深刻な影響を与えるかはわかりません。

于 2009-09-19T15:08:51.727 に答える
4

Windowsには、特にサーバーシステムで設定されることがある設定があり、パフォーマンスを向上させるためにファイルの変更時刻とアクセス時刻が設定されないようになっています。

于 2009-09-19T15:49:59.357 に答える
0

トミー・カーリエの答えは私に考えさせました…。

違いを視覚化する良い方法は、sysinternals Process Monitorを実行しながら、以下と同様の2つのスニペット（私はLinqPADを使用しました）を別々に実行することです。

while(true)
    File.GetLastAccessTime([file path here]);

と

FileInfo bob = new FileInfo(path);

while(true){
    string accessed = bob.LastAccessTime.ToString();
}

最初のスニペットの実行中にProcessMonitorを見ると、LinqPADプロセスのファイルへの繰り返しの継続的なアクセス試行が表示されます。2番目のスニペットは、ファイルへの最初のアクセスを実行します。このアクセスについては、プロセスモニターでアクティビティが表示され、その後はほとんど表示されません。

ただし、ファイルを変更すると（FileInfoを使用して監視していたテキストファイルを開き、文字を追加して保存したところ）、LinqPADプロセスによるファイルインプロセスモニターへの一連のアクセス試行が表示されます。

これは、それぞれ2つの異なるアプローチのキャッシュされていない動作とキャッシュされた動作を示しています。

キャッシュされていないアプローチは、ハードドライブに穴を開けますか？！

編集

私は自分のテストを賢く感じて去り、WindowsサービスでFileInfoのキャッシュ動作を使用しました（基本的にはループに座って、処理を行う前に「Has-file-changed-has-file-changed ...」と言います）

このアプローチは私の開発ボックスでは機能しましたが、本番環境では機能しませんでした。つまり、ファイルが変更されたかどうかに関係なく、プロセスは実行を続けました。結局、チェックへのアプローチを変更し、その一部としてGetLastAccessTimeを使用しました。実稼働サーバーでの動作が異なる理由はわかりませんが、現時点ではあまり心配していません。

于 2012-10-25T05:53:14.133 に答える