ビジネス課題への解決策(アイディア)と、新たな発想(+α)が見つかるIT情報メディア

Menu
  1. TOP
  2. データ活用
  3. Windowのファイル更新日時(前編) ファイルを別のドライブに置いたら更新日時が変わった?

Windowのファイル更新日時(前編) ファイルを別のドライブに置いたら更新日時が変わった?

  • LINEで送る
  • このエントリーをはてなブックマークに追加

以前、Windowsサーバーのファイル更新をトリガー(ファイルの更新日時を監視)にしてデータ処理を実行する、といった運用をしているお客様からサポート依頼が届きました。

ファイル更新トリガーによる監視対象ファイルを、監視フォルダーに配置するのと同時に別ドライブにもバックアップしている。
通常であれば処理の実行後、監視フォルダーに残っている処理済みのファイルに上書きしても、同一ファイルなので処理は再実行されない。
ところが、処理済みファイルのコピーであるはずのバックアップファイルを監視フォルダーに上書きすると、処理が再実行されてしまうことがある。」

同じファイルのはずなのに、なぜバックアップ環境から再度コピーしたファイルでは処理が再実行されてしまったのでしょうか?
そして、なぜ常に実行されるわけでは無く、「実行されることがある」だったのでしょうか?

発生する条件

「元ファイルはバックアップ先でも同一」なので、ファイルの内容は一致。
ということは、「更新日時」が異なる状態になっていることが想像できます。
普通は、上記に書いてあるようなファイルコピーでは更新日時は変わりません。
ところが、ある条件のとき、更新日時が変わってしまうのです。

その条件とは、「異なるファイルシステム間でのファイルコピー」です。

ファイルシステム?

ファイルシステムとは、簡単に説明すると、ファイルなどのデータを管理する方式です。
現在のWindowsでは、以下のファイルシステムを使用することができます(OSや適用しているサービスパックによっては利用できないファイルシステムも存在します)。

NTFS:NT File System

その名の通り「Windows NT系の標準ファイルシステム」で、それ以前の「FAT:File_Allocation_Table」に比べて、大容量対応や堅牢性、耐障害性、セキュリティなどが特徴です。

FAT16

16ビットOSのファイルシステムとして、MS-DOSやWindows 9xの頃まで標準のファイルシステムとして用いられていました。
構造が簡単なので、SD / miniSD / microSDカードや4GBまでのUSBメモリーなど、外部ストレージでも用いられています。今でも、投げ売りされていたり家に転がっていたりする4GB以下のUSBメモリーや、デジカメや携帯・スマホで使用しているSD / microSDカードで見かけます。

FAT32

32ビット化されたFATです。Windowsでは、Windows 95 OSR2から使用可能になりました。
構造が簡単で、各種OSからも読み書きすることができるため、データ受け渡し用途や、SDHC / miniSDHC(私は見たことがありませんが…) / microSDHCカードやUSBメモリーなど、外部ストレージやフラッシュストレージでも用いられています。

Windowsでは、2TBまでのFAT32を認識することができます。
しかし、Windows NT系では、ストレージを初期化:フォーマットするときの最大領域サイズが32GBに制限されています(Windows 9x系では、この制限はありませんでした)。

exFAT

FAT32よりも大きな領域、ファイルを扱えるようにしたものです。
構造が簡単なので、現在はSDXC / microSDXCカードなど、大容量フラッシュストレージで用いられています。ですが、読み書きできるOSが少ないので、データ受け渡し用途としてはあまり使われていません。Windowsのフォーマットでは、最小領域サイズが32GBに制限されています。

ですので、作成(フォーマット)する領域が32GBより大きいときにexFATフォーマットを行うことができ、フォーマットする領域が32GB以下のときにFAT32フォーマットを行うことができます。

ReFS

Windows Server 2012で新たに導入されたファイルシステムです。
が、システムドライブでは使用することができなかったりするので、使ったことのある方は少ないのではないでしょうか?

ファイルシステムごとのタイムスタンプ仕様

ここでは、比較するために、タイムスタンプは「作成」「更新」「アクセス」のみ記載しています。

NTFS

  • 作成日時 100ナノ秒単位
  • 更新日時 100ナノ秒単位
  • アクセス日時 100ナノ秒単位(分解能は1時間単位)
  • タイムスタンプの持ち方:UTC

FAT16

  • 作成日時 10ミリ秒単位
  • 更新日時 2秒単位
  • アクセス日時 1日単位(=アクセス日付)
  • タイムスタンプの持ち方:ローカルタイム

FAT32

  • 作成日時 10ミリ秒単位
  • 更新日時 2秒単位
  • アクセス日時 1日単位(=アクセス日付)
  • タイムスタンプの持ち方:ローカルタイム

exFAT

  • 作成日時 10ミリ秒単位
  • 更新日時 10ミリ秒単位
  • アクセス日時 2秒単位
  • タイムスタンプの持ち方:ローカルタイム、UTC(Windows Vista SP2から)

ReFS

  • 作成日時 100ナノ秒単位
  • 更新日時 100ナノ秒単位
  • アクセス日時 100ナノ秒単位
  • タイムスタンプの持ち方:UTC

このように、ファイルシステムによって保持されているタイムスタンプの仕様が異なります。
そして、1秒未満の単位で記録されているファイルシステムでも、プログラムで更新日時を取得するとDateTime型、つまり1秒単位の値が取得されてきます。

何が起きたのか?

冒頭のサポート依頼に戻り、この例では何が起きていたのかというと、
「異なるファイルシステム間でのファイルコピー」と書いたとおり、

  • 監視ファイルを作成した環境および監視フォルダのある環境のファイルシステムはNTFS
    (=更新日時は、100ナノ秒単位で記録)
  • バックアップした環境のファイルシステムはFAT32
    (=更新日時は、2秒単位で記録)

となっていたことが原因でした。

例を用いて説明すると、
トリガーファイル作成時のファイルを“A.txt”とします。

“A.txt”が、NTFS上で
 2015/01/13 10:10:59.0000
に更新されたとすると、このファイルの更新日時には
 2015/01/13 10:10:59.0000
が設定されます。

このファイルをNTFSにコピーしても、更新日時は
 2015/01/13 10:10:59.0000
のまま変わりません。

しかし、このファイルをFAT32にコピーすると、更新日時は2秒単位(偶数秒)にしか持つことができないので、FAT / FAT32が扱うことのできる最も近い未来日時である
 2015/01/13 10:11:00
となってしまいます。

このFAT32のファイルをNTFSに持ってくると、
 2015/01/13 10:11:00.0000
となります。

NTFSで作成したファイルその更新日時をプログラムで取得すると、
 2015/01/13 10:10:59
となりますが、FAT32から持ってきたファイルの更新日時をプログラムで取得すると、
 2015/01/13 10:11:00
となります。

このように、ファイルのコピーだけで、更新日時が1秒進んでしまいました。
その結果、「ファイルが更新された」と判断されてしまった、ということです。

補足

Windowsに付属している「robocopy」コマンド(堅牢性が高くリッチなファイルコピーコマンド)では、これに対応するために「/FFT」オプション(ファイルの新旧をFATファイル時間で判定するオプション)があります。

このオプションを使用すると、NTFSの更新日時(2015/01/13 10:10:59)とFATの更新日時(2015/01/13 10:11:00)を同じ時刻として判定するようになり、更新ファイルのみを上書きコピーすることができます。

後編

今回は、コピーによってファイルの更新日時自体が変わってしまった例を取り上げしました。

後編では、この更新日時が変わってしまったファイル同士をWindowsエクスプローラーがどう処理するか(実は、Windows OSによって動作が異なる)と、「更新日時」が変わっていないのに違う更新日時に見えてしまう例を書きたいと思います。


追記:Waha! Transformer 製品サイトの関連コンテンツ

Waha! Transformer の動作プラットフォーム

データの抽出や加工、連携にお悩みではありませんか?

20年以上の実績に裏打ちされた信頼のデータ連携ツール「Waha! Transformer」で、自社に眠るデータを有効活用。まずは無料のハンズオンセミナーや体験版で効果を実感していただけます。

> 純国産ETLツール「Waha! Transformer」

Waha! Transformer
メールマガジンの登録はこちらから
メルマガ登録 お問い合わせ