データドリブン経営の前提として考えるMVV：ミッション・ビジョン・バリューと戦略・戦術・戦法
以前、Windowsサーバーのファイル更新をトリガー（ファイルの更新日時を監視）にしてデータ処理を実行する、といった運用をしているお客様からサポート依頼が届きました。
ファイル更新トリガーによる監視対象ファイルを、監視フォルダーに配置するのと同時に別ドライブにもバックアップしている。
通常であれば処理の実行後、監視フォルダーに残っている処理済みのファイルに上書きしても、同一ファイルなので処理は再実行されない。
ところが、処理済みファイルのコピーであるはずのバックアップファイルを監視フォルダーに上書きすると、処理が再実行されてしまうことがある。」
同じファイルのはずなのに、なぜバックアップ環境から再度コピーしたファイルでは処理が再実行されてしまったのでしょうか？
そして、なぜ常に実行されるわけでは無く、「実行されることがある」だったのでしょうか？
「元ファイルはバックアップ先でも同一」なので、ファイルの内容は一致。
ということは、「更新日時」が異なる状態になっていることが想像できます。
普通は、上記に書いてあるようなファイルコピーでは更新日時は変わりません。
ところが、ある条件のとき、更新日時が変わってしまうのです。
その条件とは、「異なるファイルシステム間でのファイルコピー」です。
ファイルシステムとは、簡単に説明すると、ファイルなどのデータを管理する方式です。
現在のWindowsでは、以下のファイルシステムを使用することができます（OSや適用しているサービスパックによっては利用できないファイルシステムも存在します）。
その名の通り「Windows NT系の標準ファイルシステム」で、それ以前の「FAT：File_Allocation_Table」に比べて、大容量対応や堅牢性、耐障害性、セキュリティなどが特徴です。
16ビットOSのファイルシステムとして、MS-DOSやWindows 9xの頃まで標準のファイルシステムとして用いられていました。
構造が簡単なので、SD / miniSD / microSDカードや4GBまでのUSBメモリーなど、外部ストレージでも用いられています。今でも、投げ売りされていたり家に転がっていたりする4GB以下のUSBメモリーや、デジカメや携帯・スマホで使用しているSD / microSDカードで見かけます。
32ビット化されたFATです。Windowsでは、Windows 95 OSR2から使用可能になりました。
構造が簡単で、各種OSからも読み書きすることができるため、データ受け渡し用途や、SDHC / miniSDHC（私は見たことがありませんが…） / microSDHCカードやUSBメモリーなど、外部ストレージやフラッシュストレージでも用いられています。
Windowsでは、2TBまでのFAT32を認識することができます。
しかし、Windows NT系では、ストレージを初期化：フォーマットするときの最大領域サイズが32GBに制限されています（Windows 9x系では、この制限はありませんでした）。
FAT32よりも大きな領域、ファイルを扱えるようにしたものです。
構造が簡単なので、現在はSDXC / microSDXCカードなど、大容量フラッシュストレージで用いられています。ですが、読み書きできるOSが少ないので、データ受け渡し用途としてはあまり使われていません。Windowsのフォーマットでは、最小領域サイズが32GBに制限されています。
ですので、作成（フォーマット）する領域が32GBより大きいときにexFATフォーマットを行うことができ、フォーマットする領域が32GB以下のときにFAT32フォーマットを行うことができます。
Windows Server 2012で新たに導入されたファイルシステムです。
が、システムドライブでは使用することができなかったりするので、使ったことのある方は少ないのではないでしょうか？
ここでは、比較するために、タイムスタンプは「作成」「更新」「アクセス」のみ記載しています。
このように、ファイルシステムによって保持されているタイムスタンプの仕様が異なります。
そして、1秒未満の単位で記録されているファイルシステムでも、プログラムで更新日時を取得するとDateTime型、つまり1秒単位の値が取得されてきます。
冒頭のサポート依頼に戻り、この例では何が起きていたのかというと、
「異なるファイルシステム間でのファイルコピー」と書いたとおり、
となっていたことが原因でした。
例を用いて説明すると、
トリガーファイル作成時のファイルを“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によって動作が異なる）と、「更新日時」が変わっていないのに違う更新日時に見えてしまう例を書きたいと思います。
20年以上の実績に裏打ちされた信頼のデータ連携ツール「Waha! Transformer」で、自社に眠るデータを有効活用。まずは無料のハンズオンセミナーや体験版で効果を実感していただけます。
Rankingランキング
New arrival新着
Keywordキーワード
