JP4348036B2

JP4348036B2 - Method and system for creating and maintaining version-specific properties in a file

Info

Publication number: JP4348036B2
Application number: JP2001398349A
Authority: JP
Inventors: エス．ゴールディックジョナサン
Original assignee: Microsoft Corp
Current assignee: Microsoft Corp
Priority date: 2000-12-27
Filing date: 2001-12-27
Publication date: 2009-10-21
Anticipated expiration: 2021-12-27
Also published as: US7849054B2; US7058667B2; JP2002229826A; ATE431942T1; EP1235143A3; EP1235143A2; DE60138753D1; US20060242208A1; US20020116406A1; EP1235143B1

Abstract

A method and system creates and maintains a version-specific attribute or property that is stored as part of a file in a file system, contains specific version information relating to how or when the attribute was created and is automatically invalidated when a predetermined "update" event occurs. Third party applications generally create and access these versions-specific attributes to thereby eliminate the need for external logs or databases to store persistent state information. <IMAGE>

Description

【０００１】
【発明の属する技術分野】
本発明は一般にファイルシステムに関し、より詳細には、特定のファイルシステムで各ファイルの一部としてストアされるファイル属性の形式および管理に関する。さらに詳細には、本発明は、サードパーティのアプリケーション（the third party application）にステータス情報を提供するためのファイル属性の使用方法に関する。
【０００２】
【従来の技術】
コンピュータの情報は、通常、ファイルと呼ばれる構成要素にストアされる。本明細書で使用される「ファイル」とは、プログラムなどの名前の付いた完全な情報の集まり、プログラムが使用するデータのセット、またはユーザが作成した文書である。以下では、ファイル中に入れることのできる様々なタイプの情報のことを、集合的に「ファイルデータ」と呼ぶ。ファイルとは、コンピュータが複数の情報セットを区別できるようにする、ストレージの基本ユニットであると考えることもできる。したがってファイルとは、命令、数字、単語、画像などの寄せ集めを、ユーザが取出し、変更、削除、保存、または出力デバイスへの送信などを行える首尾一貫したユニットにまとめる「接着剤」である。
【０００３】
一般に、特定のコンピュータシステムでは、システム内にあるすべてのファイルが特定の形式に従っている。この形式は、ファイルシステムのプロトコルに従って事前に定義される。ファイルシステムとは、ファイルの命名、ストア、および組織化が行われる全体構造のことである。ファイルシステムは、ファイル、ディレクトリまたはフォルダ、およびこれらを探してアクセスするのに必要な情報からなる。
【０００４】
ファイル形式の定義に加え、ほとんどのファイルシステムでは、ファイル属性を作成できるようにするためのフレームワークも提供する。ファイル属性とは、ファイルに関する情報を提供するためにファイルデータと組み合せてストアされる情報ユニットであり、属性情報は実際のファイルデータとは異なるものである。通常、ほとんどのファイル属性は、ファイル名、ファイルサイズ、時間値などの情報を含む標準的な性質のものである。通常これらのものは、ヘッダの一部、すなわちそのファイルに関する情報を提供する各ファイルの一部として見分けることができる。例えば、ファイル属性は、値の変更と共に自動的に更新することが可能であり、例えばファイルサイズまたは時間値は、ファイルが修正され、その後保存されたときに、システムにより更新することができる。ファイル名などの他のファイル属性は、ファイルの内容を修正せずに変更することができる。
【０００５】
サードパーティのアプリケーションは、ウィルススキャン機能など、システムの追加の特徴または機能を提供するために、ファイルシステムとあいまって動作することが多い。これらのサードパーティのアプリケーションは、実際には各ファイルのアクセス試行を「傍受」し、実際のアクセス動作を実行する前に、ファイルのウィルスをスキャンするかまたは他のテストを行うことができる。ただし残念ながら、ファイルへのアクセスがあるたびにスキャン動作または他のテストを実行するには、かなりの時間がかかってしまう。したがって典型的には、各ファイルのバージョン情報をストアするために情報のログが保持される。例えばログは、システム上にあるファイルのリストと、各ファイルがスキャンされたかどうか、またスキャンされた場合には、どのバージョンのウィルス定義ファイルが使用されたのかを示す表示とを保持することができる。ウィルススキャナは情報のログを使用し、ファイルシステム内にある新しいファイルまたは修正されたファイル、あるいは古いウィルス定義ファイルでスキャンされたファイルのみをスキャンすることによって処理時間を短縮することができる。
【０００６】
情報ログを使用すると、あらゆるファイルをアクセス前にスキャンしていた以前のシステムが大幅に改善されるが、こうしたログの使用にはいくつかの欠点もある。例えば、こうした情報ログを保持するには、かなりのオーバヘッドを要する。さらに、項目がスキャンされたかどうかを判定するためにログにアクセスするプロセスでは、ディスク上にある別ファイルを探して調べなければならないため、システム全体のパフォーマンスが低下する。さらに、情報のログは、ファイルの複製やバックアップの際には更新されないため、情況によっては不要なスキャン動作が発生する。
【０００７】
【発明が解決しようとする課題】
情報ログを別ファイルとして保持することに関連したパフォーマンスの問題を解決する方法の１つが、「インメモリ」ログを作成し、これを揮発性メモリ、例えばＲＡＭ内にストアしておくことであった。インメモリログへのアクセスは、別ファイルへのそれよりも迅速に行うことができるため、前述のログファイルの代わりにインメモリログを使用すると、システムのパフォーマンスは上がる。ただし、システムのオフ、シャットダウン、リブートなどでシステムの電源が切れると、インメモリログは消去されるか、または失われる。したがって、電源停止後は、状態情報またはバージョン情報が即時に特定できない可能性がある。インメモリログに関連付けられた他の欠点は、そのようなログが、システムの使用する動作メモリを大量に消費することである。したがって、インメモリログは、前述の問題に適切な解決策を与えるものではない。
【０００８】
本発明の一目的は、上記またはその他の考慮すべき点に関する解決策を提供することである。
【０００９】
【課題を解決するための手段】
本発明は、ファイルの一部としてストアされ、属性がいつどのようにして作成されたかに関するバージョン固有の情報を含んでおり、所定の「更新」イベントが発生したときに自動的に無効となる、バージョン固有の属性またはプロパティを作成および使用することによって、これらの問題を解決する。サードパーティのアプリケーションは、一般に、これらのバージョン固有属性を作成し、これにアクセスすることによって外部のログまたはデータベースを不要とすることができる。
【００１０】
本発明の一態様は、コンピュータシステム内にストアされたファイルに関連付けられたバージョン固有の情報をアプリケーションに提供する方法に関する。この方法には、ファイルに関連付けられたバージョン固有属性を作成すること、所定のアクセス要求に応答してバージョン固有の情報を自動的に無効とすることにより関連するファイルの更新が常にバージョン固有属性に反映されるようにすること、並びにサードパーティのアプリケーションがバージョン固有属性を分析できるようにすることが含まれる。
【００１１】
本発明の他の態様によれば、アプリケーションとは、ウィルススキャンアプリケーション、あるいはバックアップまたはパフォーマンス上の目的でファイルの冗長複製を作成する反復子タイプのアプリケーションなどの、サードパーティのアプリケーションである。本発明のバージョン固有属性は、メタ情報、バージョン情報、およびマスク情報を含むことができる。バージョン情報は、バージョン固有属性の作成に使用されるアプリケーションのバージョンに関し、マスク情報はバージョン固有属性を無効にできる所定のイベントのポリシーまたは定義に関する。他の実施形態では、さらにバージョン固有属性は、属性またはファイルへの無許可のアクセスを防止するためか、あるいはファイルが破損しているかどうかを判定する場合に他のアプリケーションに検証要素を提供するための、デジタル署名または他のセキュリティ情報を含むことができる。
【００１２】
本発明の他の態様によれば、バージョン固有属性は、ファイル中のデータやファイルに関連付けられたメタデータの修正などの所定のイベントに基づいて、あるいは他のバージョン固有プロパティが変更されるときに、無効化することができる。無効化動作は、バージョン固有属性の削除または切り捨て、あるいはバージョン固有属性が無効であることを示す他の方法であってよい。
【００１３】
他の態様によれば、本発明は、バージョン固有属性を有するファイル形式に関し、属性にはメタ情報セクションと、ファイルのバージョンまたはバージョン固有属性の作成に使用されたアプリケーションのバージョンに関する情報をストアするためのバージョン情報セクションと、バージョン固有属性を無効にするための所定のイベントに関する情報をストアするためのマスク情報セクションとがある。さらに、本発明は、そのようなバージョン固有ファイル属性を作成および保持するためのプロトコルを提供するファイルシステムにも関する。
【００１４】
本発明は、コンピュータプロセス、コンピューティングシステム、およびコンピュータプログラムプロダクツなどの製造物として実施することができる。コンピュータプログラムプロダクツは、コンピュータシステム、およびコンピュータプロセスを実行するためのコンピュータプログラム命令の符号化によって読取り可能なコンピュータストレージ媒体であってよい。さらにコンピュータプログラムプロダクツは、コンピューティングシステム、およびコンピュータプロセスを実行するためのコンピュータプログラム命令の符号化によって読取り可能な搬送波上の伝搬信号であってもよい。
【００１５】
概略を簡潔に後述した添付の図面、本発明の現在の好ましい実施形態についての以下の詳細な説明、および添付の特許請求の範囲を参照すると、本発明およびその改良点についてより完全に理解することができる。
【００１６】
【発明の実施の形態】
本発明は、バージョン固有の属性またはプロパティを作成するためのファイルシステムに関する。バージョン固有属性は、ヘッダ識別ポインタを介する場合、または情報を常駐形式でファイルデータと共にストアする場合のいずれであっても、ファイルの一部としてストアできるという点で他のファイル属性と同様である。ただし、バージョン固有属性は、バージョン固有プロパティを作成したアプリケーションに関するバージョン固有情報をストアする機能を含む、異なる特徴を有する。さらにバージョン固有プロパティは、所定のイベントが発生すると同時に自動的に更新される。実際、無効化を発生させるイベントに関する情報も、バージョン固有プロパティの一部としてストアされる場合がある。
【００１７】
図１は、本発明を実施可能な、好適なコンピューティングシステム環境１００の一例を示す図である。コンピューティングシステム環境１００は、好適なコンピューティング環境の一例にすぎず、本発明の使用範囲または機能性に関してなんらかの制限を与えることを意図するものではない。さらにコンピューティングシステム環境１００は、例示的な動作環境１００に例示された任意の１構成要素またはその組合せに関してなんらかの依存性または要件を有するものでもない。
【００１８】
図１に示された動作環境１００に加え、本発明は、数多くの他の汎用または特殊用途向けコンピューティングシステム環境、または構成で動作可能である。本発明での使用に好適なよく知られたコンピューティングシステム、環境、および／または構成の例には、パーソナルコンピュータ、サーバコンピュータ、ハンドヘルドまたはラップトップ装置、マルチプロセッサシステム、マイクロプロセッサベースシステム、セットトップボックス、プログラム可能な家庭用電子機器、ネットワークＰＣ、ミニコンピュータ、メインフレームコンピュータ、任意の上記システムまたは装置を含む分散型コンピューティング環境などが含まれるが、これらに限定されるものではない。
【００１９】
さらに本発明は、コンピュータによって実行されるプログラムモジュールなどの、一般的なコンピュータ実行可能命令のコンテキストで説明することができる。通常、プログラムモジュールには、ルーチン、プログラム、オブジェクト、構成要素、データ構造などが含まれ、これらが特定のタスクを実行するか、または特定の抽象データタイプを実施する。本発明は、通信ネットワークを介してリンクされたリモート処理装置によってタスクが実行される、分散型コンピューティング環境において実施することもできる。分散型コンピューティング環境では、プログラムモジュールは、メモリストレージ装置を含む、ローカルおよびリモートのどちらのコンピュータストレージ媒体にも配置することができる。
【００２０】
図１を参照すると、本発明を実施するための例示的システムには、コンピュータ１０２の形態での汎用コンピューティングデバイスが含まれる。コンピュータ１０２の構成要素には、処理ユニット１０４、システムメモリ１０６、および、システムメモリを含む様々なシステム構成要素を処理ユニット１０４に結合させるシステムバス１０８が含まれるが、これらに限定されるものではない。システムバス１０８は、メモリバスまたはメモリ制御装置、周辺バス、並びに様々なバスアーキテクチャのうち任意のものを使用するローカルバスを含む、いくつかの種類のバス構造のうちのいずれかが可能である。限定的ではなく例示的なものとして例を挙げると、斯かるアーキテクチャには、ＩｎｄｕｓｔｒｙＳｔａｎｄａｒｄＡｒｃｈｉｔｅｃｔｕｒｅ（ＩＳＡ）バス、ＭｉｃｒｏＣｈａｎｎｅｌＡｒｃｈｉｔｅｃｔｕｒｅｓ（ＭＣＡ）バス、拡張ＩＳＡ（ＥＩＳＡ）バス、ＶｉｄｅｏＥｌｅｃｔｒｏｎｉｃｓＳｔａｎｄａｒｄｓＡｓｓｏｃｉａｔｉｏｎ（ＶＥＳＡ）ローカルバス、およびメザニンバスとしても知られるＰｅｒｉｐｈｅｒａｌＣｏｍｐｏｎｅｎｔＩｎｔｅｒｃｏｎｎｅｃｔ（ＰＣＩ）バスが含まれる。
【００２１】
コンピュータ１０２は、通常、様々なコンピュータ読取り可能媒体を含む。コンピュータ読取り可能媒体は、コンピュータ１０２がアクセス可能な任意の使用可能媒体であってよく、揮発性および不揮発性媒体、取外し可能および取外し不能媒体のどちらも含まれる。限定的ではなく例示的なものとして例を挙げると、コンピュータ読取り可能媒体は、コンピュータストレージ媒体および通信メディアを含むことができる。コンピュータストレージ媒体には、コンピュータ読取り可能命令、データ構造、プログラムモジュール、または他のデータなどの情報ストレージのための任意の方法または技術で実施された、揮発性および不揮発性、取外し可能および取外し不能のどちらの媒体も含まれる。コンピュータストレージ媒体には、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリ、または他のメモリ技術、ＣＤＥ−ＲＯＭ、デジタル汎用ディスク（ＤＶＤ）または他の光ディスクストレージ装置、磁気カセット、磁気テープ、磁気ディスクストレージまたは他の磁気ストレージ装置、あるいは、所望の情報をストアするのに使用可能であり、コンピュータ１０２がアクセス可能な他の媒体が含まれるが、これらに限定されるものではない。典型的に通信メディアは、コンピュータ読取り可能命令、データ構造、プログラムモジュール、または他のデータを、搬送波または他の移送メカニズムなどの被変調データ信号で具体化するものであって、任意の情報伝達メディアを含む。「被変調データ信号」という用語は、その特徴セットのうち１つ以上を有する信号、または信号内の情報を符号化する方法などで変更された信号を意味する。限定的ではなく例示的なものとして例を挙げると、通信メディアには、有線ネットワークまたは直接線接続などの有線メディアと、音響（ａｃｏｕｓｔｉｃ）、ＲＦ、赤外線、および他の無線メディアなどの無線メディアとが含まれる。上記いずれかを組み合わせる場合は、コンピュータ読取り可能媒体の範囲内であるものとする。
【００２２】
システムメモリ１０６には、読取り専用メモリ（ＲＯＭ）１１０およびランダムアクセスメモリ（ＲＡＭ）１１２などの、揮発性および／または不揮発性メモリ形態のコンピュータストレージ媒体が含まれる。起動時などにコンピュータ１０２内の要素間で情報を転送するのに役立つ基本ルーチンを含む、基本入出力システム１１４（ＢＩＯＳ）は、典型的にはＲＯＭ１１０にストアされており、ＲＡＭ１１２には、典型的には、即時アクセス可能および／／または現在処理ユニット１０４によって動作中であるファイルおよび／またはプログラムモジュールが含まれる。限定的ではなく例示的なものとして例を挙げると、図１は、オペレーティングシステム１３２、アプリケーションプログラム１３４、他のプログラムモジュール１３６、およびプログラムデータ１３８を例示している。さらにコンピュータ１０２は、以下で述べるように、システム１３２のファイル形式を定義し、バージョン固有プロパティ形式を定義するファイルシステムを備える。
【００２３】
コンピュータ１０２は、他の取外し可能／取外し不能、揮発性／不揮発性のコンピュータストレージ媒体を含むこともできる。例示的な目的でのみ例を挙げると、図１には、取外し不能、不揮発性磁気媒体との間で読取り／書込みを行うハードディスクドライブ１１６、取外し可能、不揮発性磁気ディスク１２０との間で読取り／書込みを行う磁気ディスクドライブ１１８、およびＣＤ−ＲＯＭまたは他の光学式媒体などの取外し可能、不揮発性光ディスク１２４との間で読取り／書込みを行う光ディスクドライブ１２２が例示されている。例示的な動作環境において使用できる他の取外し可能／取外し不能、揮発性／不揮発性のコンピュータストレージ媒体には、磁気テープカセット、フラッシュメモリカード、デジタル汎用ディスク、デジタルビデオテープ、ソリッドステートＲＡＭ、ソリッドステートＲＯＭなどが含まれるが、これらに限定されるものではない。ハードディスクドライブ１１６は、典型的にはインターフェース１２６などの取外し不能メモリインターフェースを介してシステムバス１０８に接続され、磁気ディスクドライブ１１８および光ディスクドライブ１２２は、典型的には、それぞれインターフェース１２８および１３０などのメモリインターフェースによってシステムバス１０８に接続される。
【００２４】
以上で説明し、図１に例示したドライブ、およびそれに関連するコンピュータストレージ媒体は、コンピュータ１０２に関するコンピュータ読取り可能命令、データ構造、プログラムモジュール、および他のデータのストレージを提供するものである。例えば図１では、ハードディスクドライブ１１６は、オペレーティングシステム１３２、アプリケーションプログラム１３４、他のプログラムモジュール１３６、およびプログラムデータ１３８をストアするものとして示されている。
【００２５】
ユーザは、キーボード１４０および、一般にマウス、トラックボール、またはタッチパッドと呼ばれるポインティングデバイス１４２などの入力装置を介して、コンピュータ１０２にコマンドおよび情報を入力することができる。他の入力装置（図示せず）は、マイクロフォン、ジョイスティック、ゲームパッド、衛星放送用パラボラアンテナ、スキャナなどを含むことができる。これらおよび他の入力装置は、システムバス１０８に結合された入力インターフェース１４８を介して処理ユニット１０４に接続されることが多い。モニタ１５０または他の種類のディスプレイ装置も、ビデオアダプタ１５２を介してシステムバス１０８に接続することができる。コンピュータは、モニタに加え、図示されていないスピーカおよびプリンタなどの他の周辺出力装置を含むこともできる。
【００２６】
コンピュータ１０２は、リモートコンピュータ１５４などの１つ以上のリモートコンピュータへの論理接続を使用するネットワーク環境において動作可能である。リモートコンピュータ１５４は、パーソナルコンピュータ、サーバ、ルータ、ネットワークＰＣ、ピアデバイス、または他の共通ネットワークノードであってよく、典型的には、コンピュータ１０２に関して上記で述べた多くのまたはすべての要素を含む。
【００２７】
ＬＡＮネットワーク環境において使用される場合、コンピュータ１０２はネットワークインターフェースまたはアダプタ１６２を介してＬＡＮに接続される。ＷＡＮネットワーク環境において使用される場合、コンピュータ１０２には典型的に、モデム１６４またはインターネットなどのＷＡＮを介して通信を確立するための他の手段が含まれる。モデム１６４は内蔵でも外付けでもよく、ユーザ入力インターフェース１４８または他の適切なメカニズムを介してシステムバス１０８に接続することができる。ネットワーク環境では、コンピュータ１０２に関連して描かれているプログラムモジュールまたはその一部を、リモートのメモリストレージ装置にストアすることができる。図示されたネットワーク接続は例示的なものであり、コンピュータ間に通信リンクを確立する他の手段も使用できることが理解できよう。
【００２８】
図２は、本発明が実施可能な好適なソフトウェア動作環境２００の一例を示す図である。ソフトウェア動作環境２００は、好適な動作環境の一例を示したものにすぎず、本発明の使用または機能性の範囲を限定する意図はない。ソフトウェア環境２００は、様々なファイル２０４、２０６、２０８、および２１０の形式および構造を定義する、ファイルシステム２０２を有する。通常、ファイルシステム２０２は、ファイルの命名、ストア、および組織化が行われる構造全体も提供する。さらにこのファイルシステムは、ファイルおよび任意のファイル関連項目にアクセスするためのプロトコルを提供する。本発明の一実施形態では、ファイルシステムは、Ｍｉｃｒｏｓｏｆｔ（登録商標）Ｃｏｒｐｏｒａｔｉｏｎが製造したＷｉｎｄｏｗｓ（登録商標）ＮＴファイルシステム（以下、「ＮＴＦＳ」という）である。ＮＴＦＳに関する詳細は、ＤａｖｉｄＳｏｌｏｍａｎ著「ＩｎｓｉｄｅＷｉｎｄｏｗｓ（登録商標）ＮＴ，ＳｅｃｏｎｄＥｄｉｔｉｏｎ」第９章、Ｍｉｃｒｏｓｏｆｔ（登録商標）Ｐｒｅｓｓ１９９８年を参照されたい。他の実施形態では、他のファイルシステムプロトコルを使用可能である。
【００２９】
図２に示されるように、ファイル２０４、２０６、２０８、および２１０は、それぞれヘッダ２１２、２１４、２１６、および２１８を有する。ヘッダ２１２、２１４、２１６、および２１８には、それぞれの各ファイルに関した情報が含まれる。ヘッダ情報は、ファイルが最後に修正された時間、ファイルが最後に保存された時間、ファイルの長さ、ファイルの名前など、ファイル属性を含むことができる。ヘッダ情報に加え、図２に示された２つのファイル２０８と２１０は、それぞれバージョン固有属性２２０と２２２も有する。このバージョン固有属性２２０と２２２はバージョン固有の情報を含み、それぞれファイル２０８と２１０に関して発生する他のイベントによって無効にすることができる。もちろん、ファイルシステムは、省略記号２２３と２２５で示されるように、バージョン固有属性を備えているか、または備えていない他の多くのファイルを含むことができる。
【００３０】
図２に示されたソフトウェア環境２００は、ファイルシステム２０２とアプリケーションプログラム２２４と２２６などのアプリケーションプログラムとの対話も図示している。一実施形態では、アプリケーションプログラム２２４と２２６は、サードパーティのアプリケーション、すなわち、ファイルシステム自体と一体になったアプリケーションとは対照的に、ファイルシステムと対話するアプリケーションである。アプリケーションプログラム２２４と２２６は、それぞれアプリケーションプログラムインターフェース２２８と２３０を介して、ファイルシステム２０２と対話することができる。さらにアプリケーションプログラムインターフェースは、例えばオペレーティングシステムインターフェース２３２などのオペレーティングシステムを介して、ファイルシステム２０２と通信する。別の実施形態（図示せず）では、アプリケーションプログラムインターフェース２２８は、ファイルシステム２０２と直接通信することができる。アプリケーションプログラムインターフェース２３０は、インターネット２３３などのコンピュータネットワークシステムを介して、オペレーティングシステムインターフェース２３４と通信する。さらに、オペレーティングシステムインターフェース２３４は、サーバコンピュータシステムのオペレーティングシステムインターフェースにも関係しており、アプリケーションプログラムインターフェースは、クライアントコンピュータシステムに関連付けられている。オペレーティングシステムインターフェース２３４は、ネットワークファイルシステムインターフェース２３５を介してファイルシステム２０２と通信する。
【００３１】
図示されていないが、本発明には、アプリケーションプログラム２２４と２２６がファイルシステム２０２と直接通信するか、制御モジュールの他の層を介してファイルシステム２０２と通信する実施形態などの、他の実施形態を組み込むことができる。したがって、本発明には、ファイル２０４、２０６、２０８、および２１０などのファイルにアクセスするために何らかの形でファイルシステムと通信する、アプリケーションプログラム２２４と２２６などのアプリケーションまたはプログラムモジュールが含まれ、アクセスには、読取り、実行、更新、またはファイル上で実行される何らかの他の機能が含まれる。
【００３２】
ファイルシステム２０２は、様々なシステム機能を提供する。ファイル２０４、２０６、２０８、および２１０に基本的な構造を与えることに加え、ファイルシステム２０２は、ファイルアクセス要求が既存のファイルに関するものであること、要求を作成しているモジュールが要求の作成および実行の許可を得ているかどうかなど、様々な機能を提供することができる。したがって、ファイルシステム２０２は、アプリケーションプログラム２２４と２２６並びに実際のファイル２０４、２０６、２０８、および２１０などの、アプリケーション間での対話をサービス層２３６に提供する。この対話層２３６は、アプリケーションプログラムインターフェース２２８、２３０が可能であるのに加え、オペレーティングシステムインターフェース２３２と２３４でも可能である。
【００３３】
バージョン固有属性２２０と２２２に関して、本発明の一実施形態では、アプリケーションプログラム２２４と２２６が、それぞれファイル２０８と２１０に関するバージョン固有属性２２０と２２２を作成および使用することができる。あるいは、サービス層２３６がバージョン固有属性を作成および使用することができる。バージョン固有属性がいったん作成されると、他のアプリケーションはこの属性にアクセスし、バージョン固有属性２２０または２２２の評価に基づいてファイルに関する動作の実行を決定することができる。さらに、他方のアプリケーションは、アプリケーションが有効なバージョン固有属性の有無をテストすると異なる結果を生じさせるようなバージョン固有属性を無効にできる、ファイルに関する動作を実行することができる。
【００３４】
特定の例では、サービス層２３６は、あるファイル、例えばファイル２０４、２０６、２０８、または２１０に任意の他のアプリケーションまたはモジュールがアクセスするたびに、ウィルスのスキャン機能およびクリーニング機能を実行するウィルススキャン機能を提供する。この例をさらに拡大すると、アプリケーションプログラム２２４は、ワードプロセッシングアプリケーションであってよく、ファイル２０４、２０６、２０８、および２１０は、テキストファイルなどのワードプロセッシングタイプのファイルである。このような場合、オペレーティングシステムインターフェースは、ウィルススキャンプログラムモジュールをサービス層２３６の一部として、実際にワードプロセッシングアプリケーションプログラム２２４がアクセスを要求するファイルのスキャンに使用することができる。この例でウィルススキャナは、ウィルスがスキャンされたファイルのバージョン固有属性２２０と２２２などの、バージョン固有属性を作成することができる。したがって、アプリケーションプログラム２２４が次にファイル２０８と２１０のうち１つに対して要求を作成した場合、ウィルススキャンアプリケーションは、他のスキャンオペレーションが必要であるかどうかを判定するために、バージョン固有属性２２０と２２２などの有効なバージョン固有属性の有無を識別するだけである。有効なバージョン固有属性が識別された場合、この特定例ではスキャンは不要である。これに対して、ファイル２０４または２０６にアクセスした際などにバージョン固有属性が識別されなかった場合、ウィルススキャンアプリケーションは、これらのファイルがスキャンされていないか、またはスキャンされてから修正されていると認識する。
【００３５】
さらにウィルススキャンの例を見ていくと、ウィルススキャンアプリケーションがサービス層２３６の一部として、ファイル２０４または２０６のうち１つをスキャンすると想定した場合、新しいバージョン固有属性（図示せず）が作成され、スキャン済みのファイルに関連付けられる。その後、新しく作成された属性（図示せず）がファイルと共にストアされるため、この属性を将来のアクセス要求に利用することができる。
【００３６】
他の実施形態では、バージョン固有属性を、他のアプリケーションがアクセスおよび評価できるデジタル署名を利用して符号化することができる。その後、このデジタル署名を調べて、ファイルが有効な複製であるかどうかを判定することができる。このような場合、ファイルが他のアプリケーションによって勝手に変更されていると、すなわち破損していると、デジタル署名は無効となる。無効化されたデジタル署名は、署名が存在しなかったものとして処理されるため、ファイルを無効として処理することができる。
【００３７】
バージョン固有属性は、属性またはファイルへの無許可のアクセスを防ぐためにさらに他のセキュリティ情報を含むことができる。サービス層２３６はこの情報を、属性をロックしてウィルスアプリケーションなどの不適切なアプリケーションが使用できないようにする手段として使用する。サービス層は、有効なアプリケーションのみが属性またはファイルそれ自体にアクセスすることを保証する目的で、アクセス毎にバージョン固有属性を評価するように構成することができる。
【００３８】
本発明を組み込んだファイル３００の態様が図３に示されている。ファイル３００には、ファイルデータ３１６、すなわちファイル情報それ自体と、この特定例では何らかの標準属性３０４を含み、その標準属性が時間やファイルの長さなどであってよい、一般情報を含んでいるヘッダ３０２とが含まれる。他の実施形態では、ヘッダには標準属性が含まれず、代わりに、図３に示すセクション３０６などの他のセクションに標準属性がストアされる場合がある。
【００３９】
ファイル３００は、図３に示されるようにバージョン固有属性３０８も有する。バージョン固有属性３０８には、３タイプの情報が含まれる。その１つがメタ情報セクション３１０であり、これは典型的には、属性の作成に使用されるサードパーティのアプリケーションの名前などの属性の名前、その他、属性の長さ、そのディスク上のアドレス位置などの情報を有する。
【００４０】
バージョン固有属性３０８には、バージョン情報セクション３１２も含まれる。バージョン情報セクション３１２には、属性の作成に使用されたサードパーティのアプリケーションのバージョンなど、バージョン固有属性３０８の作成に使用された最も新しい特定アプリケーションのバージョンに関する情報が含まれる。すなわち、こうしたバージョン情報は、属性を評価しているプログラムモジュールと関連させることができるため、このタイプの情報専用にセクションが割り当てられる。
【００４１】
バージョン固有属性３０８には、関連する更新に関する情報をファイルシステムに提供する際に使用されるマスク情報セクション３１４も含まれる。マスク情報セクション３１４は、本来、どのプロトコルまたはポリシーのイベントがバージョン固有属性３０８を無効化できるか、またはできないかを、他のアプリケーションまたはファイルシステムに指示するものである。
【００４２】
特定の実施形態では、ファイルシステムの一部であるかまたはそうでないウィルススキャンアプリケーションによってバージョン固有属性３０８が作成されると、メタ情報セクション３１０は、バージョン固有属性３０８の作成に使用されたウィルススキャンアプリケーションの名前を保持することができる。さらにバージョン情報セクション３１２には、バージョン固有属性が作成された時に使用された特定のウィルス定義ファイルに関連する情報が含められることになる。ウィルススキャンアプリケーションは、最近検出されたウィルスを含めるために頻繁に更新されるので、この特定の場合ではバージョン情報が重要である。したがって、ウィルススキャンアプリケーションは、ファイルが以前にスキャンされたことがあるかどうかを判定するだけでなく、更新済みのウィルス定義ファイルを使用してスキャンされたかどうかも判定しなければならない。
【００４３】
マスク情報セクション３１４に関して、ウィルススキャンアプリケーションがバージョン固有属性３０８を作成すると、マスク情報セクション３１４にはバージョン固有属性３０８の無効化を発生させるような特定のイベントが含められる可能性があり、このイベントはウィルススキャンアプリケーションに一意的に直接関係する場合がある。この特定の場合では、バージョン固有属性３０８の無効化を発生させることのあるこのようなイベントに、新しいファイルデータの追加またはファイルデータの消去のいずれかによるファイルデータセクション３０６の修正が含まれることがある。他の実施形態では、他の所定のイベントによってバージョン固有属性の無効化を発生させることがある。
【００４４】
この特定の例では、具体的にはマスク情報セクション３１４に含めることができないためにバージョン固有属性が無効化されることのない所定のイベントに、読取り専用アクセスイベント、ファイル名の変更、またはファイル３００のバックアップを含めることができる。実際には、イベントがバージョン固有属性を無効化しなければ、ファイル名が変更されたような場合でもその属性はファイルに付属のままとなる。
【００４５】
バージョン固有属性３０８は、サードパーティのアプリケーション、例えばファイルシステムとは別のアプリケーションによって作成される。バージョン固有属性を作成する場合、サードパーティのアプリケーションは、名前、バージョン、およびマスクの情報を、ファイルシステムに提供する。次いでファイルシステムが属性を作成し、これを特定ファイルに関連付ける。本発明の一実施形態では、バージョン固有属性３０８を作成する方法の１つに、Ｗｉｎｄｏｗｓ（登録商標）ＮＴＦＳに属性の作成を要求するサードパーティのアプリケーションが含まれる。この実施形態でバージョン固有属性を作成するのに使用されるコマンドが、表１に示される。表１に示されたコードは、ファイルａ．ｔｘｔがすでに作成されており、サードパーティのアプリケーションの名前が「Ｉｎｏｃｕｌａｎ」と想定したものである。
【００４６】
【表１】

【００４７】
表１に示されるように、サードパーティのアプリケーションはバージョン固有属性の作成を要求し、次いで、作成された属性が閉じる前に属性にデータを書き込むだけである。この機能を働かせるためには、ファイルシステムが事前にバージョン固有属性タイプを定義していなければならない。他の実施形態では、他の方法を使用してバージョン固有属性を作成し、これを配置することができる。バージョン固有属性３０８をいったん作成すると、ファイルがアクセスされたときに他のアプリケーションがこれを評価および／または無効化することができる。
【００４８】
本発明の他の実施形態では、ＮＴＷｒｉｔｅＦｉｌｅコマンドの前に、バージョン固有属性のセキュリティの設定に関する他のコマンドを挿入することができる。各バージョン固有属性に、別々のセキュリティ記述子を作成または定義することができる。あるいは、各アプリケーション、例えばＩｎｏｃｕｌａｎは、デジタル署名を使用して、そのアプリケーションが関係するバージョン固有プロパティの保全性を検証することができる。セキュリティのタイプがいったん定義されると、その情報をバージョン固有属性のＮＴＷｒｉｔｅＦｉｌｅコマンドの前にストアすることができる。
【００４９】
ＮＴＷｒｉｔｅＦｉｌｅ動作後、ＮＴＣｌｏｓｅ動作を使用してバージョン固有属性を閉じることができる。
【００５０】
ファイル３００はバージョン固有属性を１つだけ有するように図示および説明されているが、ファイル３００は、破断記号３１８で示されるような他のバージョン固有属性も含めて他の属性を有することもできる。実際に、いくつかのサードパーティのアプリケーションは、持続状態情報がファイルの一部としてストアされることを要求することが可能であり、したがってバージョン固有属性３０８などの多数のバージョン固有属性を作成し、ファイル３００と共にストアすることができる。
【００５１】
以上、例示的な物理環境について論じてきたが、以下のセクションでは、本発明の態様を具体化する動作モジュールについて説明する。本発明の様々な実施形態の論理的動作は、（１）コンピューティングシステム上で実行中のコンピュータが実施する一連のステップまたはプログラムモジュールとして、および／または（２）コンピューティングシステム内で相互接続されたハードウェアモジュールまたは論理モジュールとして実施される。この実施は、本発明を実施するコンピューティングシステムのパフォーマンス要件に依存する選択の問題である。したがって、本明細書に記載された本発明の実施形態を構成している論理動作は、動作（operation）、ステップ、またはモジュールと呼ばれることもある。
【００５２】
図４は、本発明の態様によるファイルへのアクセスに関連する動作特性を示すフローダイアグラムである。フロー４００が開始される前に、図２に示されたファイル２０４、２０６、２０８、または２１０などのファイルが、ファイルシステム２０２（図２）などのファイルシステム内に存在する。本発明の一実施形態では、いったんファイルが作成されると、そのファイルにアクセスしようと試みたときに、図４に関して図示および説明したフロー４００が開始される。実際には、プロセス４００はアクセス試行ステップＳ４０２で開始されるが、このアクセス試行ステップＳ４０２は、ファイルシステム内の任意のファイルの読取り、実行、または更新に関するものである。アクセス試行は、アプリケーションプログラム２２４（図２）などのサードパーティのアプリケーションによって、またはサービス層２３６（図２）によって実行することができる。
【００５３】
アクセス試行ステップＳ４０２に続き、判断行為（ｄｅｔｅｒｍｉｎａｔｉｏｎａｃｔ）ステップＳ４０４において、アクセスが無効化アクセスであるかどうかを判定する。アクセスが無効化アクセスであるかどうかの判定には、複数の特定ファイルにアクセスしていると想定した、各バージョン固有属性内にあるマスク情報の評価が含まれる。マスク情報を評価することにより、そのファイルへのどのタイプのアクセスが、特定のバージョン固有属性を無効にするように要求しているのかがわかる。したがって、マスク情報と実際のアクセス試行とを比較することにより、バージョン固有属性を無効にすべきかどうかがわかる。判断行為ステップＳ４０４でこのような適切な更新アクセス試行が識別されると、フローはＹＥＳの無効化動作ステップＳ４０６へと進む。
【００５４】
本発明の一実施形態では、バージョン固有属性はウィルススキャンアプリケーションによって作成および使用される。このような状況では、判断行為ステップＳ４０４において、アクセス試行が適切な更新アクセスであるかどうかがウィルススキャンアプリケーションにより設定した基準に基づき判定される。すなわち、ウィルススキャンアプリケーションは、アクセス試行が、古いデータを変更するかまたは新しいデータを追加することによって実際のファイルデータを修正するかどうかなど、適切な更新アクセスとは何であるかを事前に決定している。例えば、特定のウィルススキャンアプリケーションは、新しいデータの作成を含み、ファイル中のデータにどんな変更が行われる場合でも必ずそのバージョン固有プロパティが無効化されることを希望することができる。変更がバージョン固有プロパティまたは他のファイルのメタデータまたは他のメタ情報にだけ関係する場合には、無効化は発生しない。
【００５５】
別の実施形態では、反復子アプリケーションがバージョン固有属性を作成し、これを使用することができる。このような場合、反復子アプリケーションは、ファイルのデータまたはメタデータのいずれかにどんな変更が行われる場合でも必ず、そのバージョン固有プロパティが無効化されることを希望することができる。これら特定のバージョン固有プロパティは、このクラスのバージョン固有プロパティだけに影響を与えるのではないような変更が行われると、必ず無効化される。この場合、特定のクラスを定義することにより、複数の反復子が存在することでファイルが何度も反復されることを防いでおり、１つの反復子アプリケーションによる反復インスタンスは、それぞれ、第２の反復子アプリケーションによる反復の必要に応じて生じることになる。
【００５６】
無効化動作ステップＳ４０６において、バージョン固有プロパティまたはバージョン固有属性３０８（図３）などの属性を無効にする。一実施形態では、無効化行為ステップＳ４０６で、バージョン固有属性を「無効化」するためにバージョン固有属性を削除または切り捨てる。あるいは、無効化動作ステップＳ４０６でバージョン固有属性にマークを付けるか、そうでなければ属性が無効である旨の表示を与える。本来、属性を無効にする行為は、バージョン固有属性に依拠したアプリケーションが、バージョン固有属性が無効化されていることを認識できるようにするものでなければならない。バージョン固有属性を無効化する他の方法には、無効化アクセスまたはバージョン固有属性への情報の追加、あるいはその中に含まれる情報の修正も含むことができる。無効化行為ステップＳ４０６では、時間変更、最終書込み時間、または最終アクセス時間などの他の項目は変更しない。
【００５７】
ファイルが複数の関連するバージョン固有属性を有する場合、動作ステップＳ４０４およびＳ４０６は、それぞれのバージョン固有属性について繰返し行われる。
【００５８】
無効化行為ステップＳ４０６に続き、アクセス実行動作ステップＳ４０８において、ファイルに対して要求されたアクセスを実行する。ファイルに対するアクセスを実行する行為は、バージョン固有属性が無効化された後に開始することが重要である。そうでないと、バージョン固有属性が信頼できなくなる可能性がある。アクセス実行動作ステップＳ４０８に続き、フロー４００は終了動作ステップＳ４１０で終了する。
【００５９】
判断行為ステップＳ４０４においてアクセス試行が無効化アクセスに関連していないと判定されると、フローはＮＯの判断動作ステップＳ４１２に進む。判断動作ステップＳ４１２では、アクセスがバージョン固有属性に依存しているかどうか、例えば、アクセス試行が動作を実行する際にバージョン固有属性を使用しているアプリケーションによるアクセス試行であるかどうかを判定する。例えば、バージョン固有属性を使用するウィルススキャンアプリケーションはアクセス試行を生成することが可能であり、その場合、判断動作ステップＳ４１２において、そのアクセス試行がバージョン固有属性を使用するそのようなアプリケーションによって生成されたものであるかどうかを判定する。
【００６０】
アクセス試行がバージョン固有属性に依拠するアプリケーションによって実行されたものでない場合、フローはＮＯのアクセス実行動作ステップＳ４０８に進む。アクセス実行動作ステップＳ４０８では、最初に要求されたアクセス動作を実行する。判断動作ステップＳ４１２に続いてアクセス実行動作ステップＳ４０８が行われる場合、アクセス動作は、判断行為ステップＳ４０４が判定したような無効化を要求する動作には関連していない。例えば、このアクセス試行は、ユーザが実際のデータを修正できない読取り動作に関連していることがある。アクセス実行動作ステップＳ４０８に続き、プロセスのフローは前述のようにステップＳ４１０で終了する。
【００６１】
判断動作ステップＳ４１２において、アクセスがバージョン固有属性に依存していると判定した場合、フローはＹＥＳの判断行為ステップＳ４１４に進む。判断行為ステップＳ４１４において、バージョン固有属性が有効であるかどうかを判定するためにこれを分析する。属性が有効であるかどうかの判定には、属性が存在するかどうか、これが無効としてマークされているかどうか、または情報がすべて利用できないように切り捨てられているかどうかが含まれる。判断行為ステップＳ４１４において属性が有効でないと判定されると、フローはＮＯの無効属性に関するアクセス実行行為ステップＳ４１６に進む。
【００６２】
実行行為ステップＳ４１６では、アクセスが無効であるという判定に基づいて、所定の機能が実行される。一実施形態では、アクセス試行がウィルススキャンアプリケーションによって生成されたものである場合、実行動作ステップＳ４１６では、そのようなウィルススキャン機能をファイル上で実行する。
【００６３】
無効属性に関する動作実行ステップＳ４１６に続き、バージョン固有属性作成行為ステップＳ４１８では、そのファイルに関してバージョン固有属性を作成または有効化する。バージョン固有属性の有効化には、そのファイルのバージョン固有属性を作成すること、または既存のバージョン固有属性に情報を追加することが含まれる。他の実施形態では、属性が有効であるという表示を与えることによって、後に属性が有効であることがわかる限りは、他の方法で属性を有効化することができる。バージョン固有属性有効化行為ステップＳ４１８に続き、プロセス４００は終了動作ステップＳ４１０で終了する。
【００６４】
判断行為ステップＳ４１４においてバージョン固有属性が有効であると判定された場合、フローはＹＥＳの実行動作ステップＳ４２０に進む。実行動作ステップＳ４２０は、バージョン固有属性が有効であるという判定に関する任意の行為を実行することに関する。バージョン固有属性を使用する特定のアプリケーションによって、実行動作ステップＳ４２０には異なるタイプの動作が含まれることがある。一例では、属性が有効であると判定された場合、ウィルススキャン状況などでは何の動作も実行されない。このような場合、判断行為ステップＳ４１４においてバージョン固有属性が有効であると判定されると、ファイルは以前にスキャンされているため、他のスキャンは不要である。したがって、そのファイルについては何の動作も実行されず、動作ステップＳ４２０は終了動作ステップＳ４１０に制御を渡すだけである。他の実施形態では、バージョン固有属性が有効であると判定されると、ステップＳ４２０で動作が実行開始される場合がある。
【００６５】
前述のシステムおよび方法は、バージョン情報が別のログまたはデータベースファイルに常駐しているのではなく、ファイルの一部であるため、バージョン情報をプログラムモジュールまたはアプリケーションに提供するという従来の方法に比べてかなり有利である。アクセス側のアプリケーションは、利用不能、破損、その他管理不能になる可能性がある外付けタイプのファイルにアクセスする必要がない。さらに、電源が切断されてもファイル属性は失われず、属性は、インメモリ情報ログの場合のように大量の動作メモリを消費せずに済む。さらに、プロセスは自動的に更新され、すなわち、関連するイベントが発生したときにはバージョン固有情報が無効化される。バージョン固有情報を自動的に無効化することにより、関連する適切な更新は見逃されることがなく、不要な行為は実行されない確率が高くなる。例えば、ウィルススキャンの実施に関して言えば、従来技術の方法では、バックアップ機能および／または複製機能の後ではこのようなバージョン情報は保持されなかったため、追加の処理ステップが実行されていたが、バージョン情報はバックアップ機能や複製機能では無効化されなくなっているため、将来アクセスしたときにウィルススキャンは不要である。
【００６６】
前述のように、本明細書に記載した本発明は、コンピュータプロセス、コンピューティングシステム、またはコンピュータプログラムプロダクツなどの製造物として実施することができる。コンピュータプログラムプロダクツは、コンピュータシステム、およびコンピュータプロセスを実行するためのコンピュータプログラム命令の符号化によって読取り可能な、コンピュータストレージ媒体であってよい。さらにコンピュータプログラムプロダクツは、コンピューティングシステム、およびコンピュータプロセスを実行するためのコンピュータプログラム命令の符号化によって読取り可能な、搬送波上の伝搬信号であってもよい。
【００６７】
さらに、本発明は構造上の特徴および／または方法論的ステップに固有の言語で記述されているが、添付の特許請求の範囲で定義された本発明は、記載されている特定の特徴またはステップに限定されるものではないことを理解されたい。一例として、他のアプリケーションでは、ウィルススキャンアプリケーションおよび反復子の他にも、バージョン固有属性を利用することができる。さらに、他のタイプのファイルシステムも、本発明の原理から恩恵を受けることができる。したがって、特定の特徴およびステップは、記載された本発明を実施する好ましい形態として開示されたものである。
【図面の簡単な説明】
【図１】本発明を組み込むことのできるコンピュータシステムの機能図である。
【図２】本発明のソフトウェア構成要素を示す構成図である。
【図３】本発明によるファイルの構成要素を示す機能図である。
【図４】本発明の一実施形態の機能的な特徴を示すフローダイアグラムである。
【符号の説明】
１００コンピューティングシステム環境（動作環境）
１０２コンピュータ
１０４処理ユニット
１０６システムメモリ
１０８システムバス
１１４基本入出力システム
１１６ハードディスクドライブ
１１８磁気ディスクドライブ
１２０不揮発性磁気ディスク
１２２光ディスクドライブ
１２４不揮発性光ディスク
１２６ハードディスクドライブインターフェース
１２８磁気ディスクドライブインターフェース
１３２オペレーティングシステム
１３４，２２４，２２６アプリケーションプログラム
１３６プログラムモジュール
１３８プログラムデータ
１４０キーボード
１４２ポインティングデバイス
１４８ユーザ入力インターフェース
１５０モニタ
１５２ビデオアダプタ
１５４リモートコンピュータ
１６２アダプタ
１６４モデム
２００ソフトウェア動作環境
２０２ファイルシステム
２０４，２０６，２０８，２１０，３１６ファイルデータ
２１２，２１４，２１６，２１８，３０２ヘッダ
２２０，２２２，３０８バージョン固有属性
２２３，２２５省略記号
２２４アプリケーションプログラム
２２８，２３０アプリケーションプログラムインターフェース（ＡＰＩ）
２３２，２３４オペレーティングシステムインターフェース
２３３インターネット
２３５ネットワークファイルシステムインターフェース
２３６サービス層（対話層）
３００ファイル
３０４標準属性
３０６ファイルデータセクション
３１０メタ情報セクション
３１２バージョン情報セクション
３１４マスク情報セクション
３１８破断記号
４００プロセス（フロー）[0001]
BACKGROUND OF THE INVENTION
The present invention relates generally to file systems, and more particularly to the format and management of file attributes stored as part of each file in a particular file system. More particularly, the present invention relates to a method for using file attributes to provide status information to a third party application.
[0002]
[Prior art]
Computer information is typically stored in components called files. As used herein, a “file” is a complete collection of named information, such as a program, a set of data used by the program, or a user-created document. Hereinafter, various types of information that can be included in a file are collectively referred to as “file data”. A file can also be thought of as the basic unit of storage that allows a computer to distinguish multiple sets of information. Thus, a file is an “glue” that brings together a collection of instructions, numbers, words, images, etc. into a coherent unit that a user can retrieve, modify, delete, save, or send to an output device.
[0003]
In general, in a particular computer system, all files in the system follow a particular format. This format is predefined according to the file system protocol. A file system is the overall structure in which file naming, storage, and organization takes place. A file system consists of files, directories or folders, and information necessary to locate and access them.
[0004]
In addition to defining file formats, most file systems also provide a framework that allows file attributes to be created. A file attribute is an information unit that is stored in combination with file data to provide information about the file, and the attribute information is different from the actual file data. Usually, most file attributes are of a standard nature including information such as file name, file size, time value, etc. These can usually be identified as part of the header, ie the part of each file that provides information about the file. For example, file attributes can be updated automatically with changing values, for example, file size or time values can be updated by the system when the file is modified and then saved. Other file attributes, such as the file name, can be changed without modifying the contents of the file.
[0005]
Third party applications often work in conjunction with the file system to provide additional system features or functions, such as virus scanning capabilities. These third-party applications can actually “intercept” each file access attempt and scan the file for viruses or perform other tests before performing the actual access operation. Unfortunately, however, it takes a considerable amount of time to perform a scan operation or other test every time a file is accessed. Thus, a log of information is typically maintained to store version information for each file. For example, the log can hold a list of files on the system and an indication of whether each file was scanned and, if so, which version of the virus definition file was used. . Virus scanners use information logs to reduce processing time by scanning only new or modified files in the file system, or files scanned with old virus definition files.
[0006]
Using information logs can greatly improve previous systems that scanned all files before they were accessed, but the use of such logs also has some drawbacks. For example, maintaining such an information log requires significant overhead. In addition, the process of accessing the log to determine if an item has been scanned must look for and examine another file on the disk, thus reducing overall system performance. Furthermore, since the information log is not updated at the time of file replication or backup, an unnecessary scanning operation occurs depending on the situation.
[0007]
[Problems to be solved by the invention]
One way to solve the performance problem associated with keeping the information log as a separate file was to create an “in-memory” log and store it in volatile memory, eg RAM. . Since access to the in-memory log can be performed more quickly than that to another file, using the in-memory log instead of the aforementioned log file increases system performance. However, the in-memory log is erased or lost when the system is turned off, such as when the system is turned off, shut down, or rebooted. Therefore, there is a possibility that the state information or version information cannot be immediately identified after the power is stopped. Another drawback associated with in-memory logs is that such logs consume a large amount of the operating memory used by the system. Thus, the in-memory log does not provide an appropriate solution to the above problem.
[0008]
One object of the present invention is to provide a solution to these and other considerations.
[0009]
[Means for Solving the Problems]
The present invention is stored as part of the file and contains version specific information about when and how the attribute was created, and is automatically disabled when a predetermined "update" event occurs. Resolve these issues by creating and using version-specific attributes or properties. Third-party applications can generally create and access these version-specific attributes to eliminate the need for external logs or databases.
[0010]
One aspect of the invention relates to a method of providing an application with version-specific information associated with a file stored in a computer system. This method creates a version-specific attribute associated with the file and automatically invalidates the version-specific information in response to a given access request so that the associated file update is always a version-specific attribute. Including being reflected, as well as allowing third party applications to analyze version specific attributes.
[0011]
According to another aspect of the invention, the application is a third-party application, such as a virus scan application or an iterator-type application that creates redundant copies of files for backup or performance purposes. The version specific attribute of the present invention may include meta information, version information, and mask information. The version information relates to the version of the application used to create the version specific attribute, and the mask information relates to a policy or definition of a predetermined event that can invalidate the version specific attribute. In other embodiments, the version-specific attribute further prevents unauthorized access to the attribute or file, or provides a verification element to other applications when determining whether the file is corrupted. A digital signature or other security information.
[0012]
According to another aspect of the present invention, the version specific attribute is based on a predetermined event, such as modification of data in the file or metadata associated with the file, or when other version specific properties are changed. Can be disabled. The invalidation operation may be deletion or truncation of the version specific attribute, or other method indicating that the version specific attribute is invalid.
[0013]
According to another aspect, the present invention relates to a file format having a version specific attribute, the attribute stores a meta information section and information about the version of the file or the application version used to create the version specific attribute. And a mask information section for storing information on a predetermined event for invalidating the version-specific attribute. The present invention further relates to a file system that provides a protocol for creating and maintaining such version-specific file attributes.
[0014]
The present invention can be implemented as a product such as a computer process, a computing system, and a computer program product. A computer program product may be a computer system and a computer storage medium readable by encoding computer program instructions for executing computer processes. Further, a computer program product may be a propagated signal on a carrier wave readable by a computer system and the encoding of computer program instructions for executing a computer process.
[0015]
A more complete understanding of the present invention and its improvements will be obtained by reference to the accompanying drawings, briefly described below, the following detailed description of the presently preferred embodiments of the invention, and the appended claims. Can do.
[0016]
DETAILED DESCRIPTION OF THE INVENTION
The present invention relates to a file system for creating version-specific attributes or properties. The version-specific attribute is similar to other file attributes in that it can be stored as part of a file, whether via a header identification pointer or when information is stored with file data in a resident format. However, the version specific attribute has different features including the ability to store version specific information about the application that created the version specific property. Furthermore, the version specific property is automatically updated as soon as a predetermined event occurs. In fact, information about the event that causes invalidation may also be stored as part of the version specific property.
[0017]
FIG. 1 is a diagram illustrating an example of a suitable computing system environment 100 on which the invention may be implemented. The computing system environment 100 is only one example of a suitable computing environment and is not intended to provide any limitation as to the scope of use or functionality of the invention. Further, the computing system environment 100 does not have any dependency or requirement on any one or combination of components illustrated in the exemplary operating environment 100.
[0018]
In addition to the operating environment 100 shown in FIG. 1, the present invention is operational with numerous other general purpose or special purpose computing system environments or configurations. Examples of well-known computing systems, environments, and / or configurations suitable for use with the present invention include personal computers, server computers, handheld or laptop devices, multiprocessor systems, microprocessor-based systems, set tops. Including, but not limited to, boxes, programmable home electronics, network PCs, minicomputers, mainframe computers, distributed computing environments including any of the above systems or devices, and the like.
[0019]
Furthermore, the present invention can be described in the context of general computer-executable instructions, such as program modules, being executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types. The invention may also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules can be located in both local and remote computer storage media including memory storage devices.
[0020]
With reference to FIG. 1, an exemplary system for implementing the invention includes a general purpose computing device in the form of a computer 102. The components of computer 102 include, but are not limited to, processing unit 104, system memory 106, and system bus 108 that couples various system components including system memory to processing unit 104. . The system bus 108 can be any of several types of bus structures including a memory bus or memory controller, a peripheral bus, and a local bus using any of a variety of bus architectures. By way of example and not limitation, such architectures include: Industry Standard Architecture (ISA) bus, Micro Channel Architectures (MCA) bus, Enhanced ISA (EISA) bus, Video Electronics Standards Association Local buses and Peripheral Component Interconnect (PCI) buses, also known as mezzanine buses, are included.
[0021]
Computer 102 typically includes a variety of computer readable media. Computer readable media can be any available media that can be accessed by computer 102 and includes both volatile and nonvolatile media, removable and non-removable media. By way of example, and not limitation, computer-readable media can include computer storage media and communication media. Computer storage media includes volatile and non-volatile, removable and non-removable implemented in any method or technique for storage of information such as computer-readable instructions, data structures, program modules, or other data Both media are included. Computer storage media may include RAM, ROM, EEPROM, flash memory, or other memory technology, CDE-ROM, digital universal disc (DVD) or other optical disk storage device, magnetic cassette, magnetic tape, magnetic disk storage or other Examples include, but are not limited to, magnetic storage devices or other media that can be used to store desired information and that can be accessed by computer 102. Communication media typically embodies computer readable instructions, data structures, program modules, or other data in a modulated data signal such as a carrier wave or other transport mechanism and includes any information delivery media. including. The term “modulated data signal” means a signal that has one or more of its characteristics set or changed in such a manner as to encode information in the signal. By way of example, and not limitation, communication media includes wired media such as a wired network or direct line connection, and wireless media such as acoustic, RF, infrared, and other wireless media. Is included. Any combination of the above shall be within the scope of a computer readable medium.
[0022]
The system memory 106 includes computer storage media in the form of volatile and / or nonvolatile memory such as read only memory (ROM) 110 and random access memory (RAM) 112. A basic input / output system 114 (BIOS), including basic routines that help to transfer information between elements within the computer 102, such as at startup, is typically stored in the ROM 110, and the RAM 112 is typically Includes files and / or program modules that are immediately accessible and / or currently in operation by the processing unit 104. By way of example and not limitation, FIG. 1 illustrates an operating system 132, application programs 134, other program modules 136, and program data 138. The computer 102 further includes a file system that defines the file format of the system 132 and defines a version-specific property format, as described below.
[0023]
The computer 102 may also include other removable / non-removable, volatile / nonvolatile computer storage media. By way of example only for illustrative purposes, FIG. 1 shows a hard disk drive 116 that reads / writes to / from a non-removable, non-volatile magnetic medium, a read / write to / from a non-removable non-volatile magnetic disk 120. Illustrated are a magnetic disk drive 118 that performs writing and an optical disk drive 122 that reads / writes to and from a removable, non-volatile optical disk 124 such as a CD-ROM or other optical media. Other removable / non-removable, volatile / nonvolatile computer storage media that can be used in the exemplary operating environment include magnetic tape cassettes, flash memory cards, digital universal disks, digital video tapes, solid state RAM, solid state Although ROM etc. are included, it is not limited to these. The hard disk drive 116 is typically connected to the system bus 108 via a non-removable memory interface such as interface 126, and the magnetic disk drive 118 and optical disk drive 122 are typically memory such as interfaces 128 and 130, respectively. It is connected to the system bus 108 by an interface.
[0024]
The drive described above and illustrated in FIG. 1 and associated computer storage media provide storage of computer readable instructions, data structures, program modules, and other data for computer 102. For example, in FIG. 1, hard disk drive 116 is shown as storing operating system 132, application programs 134, other program modules 136, and program data 138.
[0025]
A user may enter commands and information into the computer 102 through input devices such as a keyboard 140 and pointing device 142, commonly referred to as a mouse, trackball or touch pad. Other input devices (not shown) may include a microphone, joystick, game pad, satellite dish, scanner, and the like. These and other input devices are often connected to the processing unit 104 via an input interface 148 coupled to the system bus 108. A monitor 150 or other type of display device can also be connected to the system bus 108 via a video adapter 152. In addition to the monitor, the computer can also include other peripheral output devices such as speakers and printers not shown.
[0026]
Computer 102 is operable in a network environment that uses logical connections to one or more remote computers, such as remote computer 154. Remote computer 154 may be a personal computer, server, router, network PC, peer device, or other common network node and typically includes many or all of the elements described above with respect to computer 102.
[0027]
When used in a LAN networking environment, the computer 102 is connected to the LAN through a network interface or adapter 162. When used in a WAN network environment, the computer 102 typically includes a modem 164 or other means for establishing communications over the WAN, such as the Internet. The modem 164 may be internal or external and may be connected to the system bus 108 via a user input interface 148 or other suitable mechanism. In a network environment, program modules depicted in connection with computer 102 or portions thereof may be stored on a remote memory storage device. It will be appreciated that the network connections shown are exemplary and other means of establishing a communications link between the computers can be used.
[0028]
FIG. 2 is a diagram illustrating an example of a preferred software operating environment 200 in which the present invention can be implemented. The software operating environment 200 is only one example of a suitable operating environment and is not intended to limit the scope of use or functionality of the invention. Software environment 200 has a file system 202 that defines the format and structure of

various files

204, 206, 208, and 210. Typically, the file system 202 also provides the entire structure where file naming, storage, and organization takes place. In addition, the file system provides a protocol for accessing files and any file related items. In one embodiment of the present invention, the file system is a Windows® NT file system (hereinafter “NTFS”) manufactured by Microsoft® Corporation. For more information on NTFS, see David Soloman, “Inside Windows® NT, Second Edition”, Chapter 9, Microsoft® Press 1998. In other embodiments, other file system protocols can be used.
[0029]
As shown in FIG. 2, files 204, 206, 208, and 210 have

headers

212, 214, 216, and 218, respectively. The

headers

212, 214, 216, and 218 contain information related to each file. The header information can include file attributes such as the last time the file was modified, the time the file was last saved, the length of the file, the name of the file, and so on. In addition to the header information, the two

files

208 and 210 shown in FIG. 2 also have version specific attributes 220 and 222, respectively. These version specific attributes 220 and 222 contain version specific information and can be overridden by other events that occur with respect to

files

208 and 210, respectively. Of course, the file system may include many other files with or without version specific attributes, as indicated by

ellipses

223 and 225.
[0030]
The software environment 200 shown in FIG. 2 also illustrates interaction between the file system 202 and application programs such as application programs 224 and 226. In one embodiment, application programs 224 and 226 are applications that interact with the file system as opposed to third party applications, ie, applications that are integral to the file system itself. Application programs 224 and 226 can interact with file system 202 via application program interfaces 228 and 230, respectively. Further, the application program interface communicates with the file system 202 via an operating system such as the operating system interface 232. In another embodiment (not shown), the application program interface 228 can communicate directly with the file system 202. The application program interface 230 communicates with the operating system interface 234 via a computer network system such as the Internet 233. In addition, the operating system interface 234 is related to the operating system interface of the server computer system, and the application program interface is associated with the client computer system. The operating system interface 234 communicates with the file system 202 via the network file system interface 235.
[0031]
Although not shown, the present invention includes other embodiments, such as embodiments in which application programs 224 and 226 communicate directly with file system 202 or communicate with file system 202 through other layers of the control module. Can be incorporated. Thus, the present invention includes applications or program modules, such as application programs 224 and 226, that communicate with the file system in some way to access files such as

files

204, 206, 208, and 210. Includes reading, executing, updating, or some other function performed on the file.
[0032]
The file system 202 provides various system functions. In addition to providing the basic structure for the

files

204, 206, 208, and 210, the file system 202 ensures that the file access request is for an existing file and that the module making the request creates the request and Various functions can be provided, such as whether or not permission is granted. Thus, file system 202 provides service layer 236 with interactions between applications, such as application programs 224 and 226 and

actual files

204, 206, 208, and 210. The interaction layer 236 can be the operating system interfaces 232 and 234 in addition to the application program interfaces 228 and 230.
[0033]
With respect to version specific attributes 220 and 222, in one embodiment of the present invention, application programs 224 and 226 can create and use version specific attributes 220 and 222 for

files

208 and 210, respectively. Alternatively, the service layer 236 can create and use version specific attributes. Once the version specific attribute is created, other applications can access this attribute and decide to perform an operation on the file based on the evaluation of the version specific attribute 220 or 222. In addition, the other application can perform file-related operations that can override version-specific attributes that would produce different results when the application tests for valid version-specific attributes.
[0034]
In a particular example, the service layer 236 performs a virus scanning function that performs a virus scanning function and a cleaning function each time any other application or module accesses a file, eg, the

file

204, 206, 208, or 210. I will provide a. To further expand this example, application program 224 may be a word processing application, and files 204, 206, 208, and 210 are word processing type files such as text files. In such a case, the operating system interface can use the virus scan program module as part of the service layer 236 to actually scan the file that the word processing application program 224 requires access to. In this example, the virus scanner can create version specific attributes, such as version specific attributes 220 and 222 for files scanned for viruses. Thus, if the application program 224 next makes a request for one of the

files

208 and 210, the virus scan application will determine whether a version specific attribute 220 is needed to determine if another scan operation is required. It only identifies the presence or absence of valid version-specific attributes such as. If a valid version specific attribute is identified, no scan is required in this particular example. On the other hand, if version-specific attributes are not identified, such as when accessing

files

204 or 206, the virus scanning application may have detected that these files have not been scanned or have been modified since they were scanned. recognize.
[0035]
Looking further at the virus scanning example, assuming that the virus scanning application scans one of the

files

204 or 206 as part of the service layer 236, a new version specific attribute (not shown) is created. , Associated with the scanned file. The newly created attribute (not shown) is then stored with the file so that it can be used for future access requests.
[0036]
In other embodiments, version-specific attributes can be encoded utilizing digital signatures that can be accessed and evaluated by other applications. This digital signature can then be examined to determine if the file is a valid copy. In such a case, the digital signature becomes invalid if the file has been changed by another application without permission, that is, if the file is damaged. Since the invalid digital signature is processed as if the signature did not exist, the file can be processed as invalid.
[0037]
Version-specific attributes can include further security information to prevent unauthorized access to the attributes or files. The service layer 236 uses this information as a means of locking the attribute so that an inappropriate application such as a virus application cannot be used. The service layer can be configured to evaluate version specific attributes on every access in order to ensure that only valid applications have access to the attributes or the file itself.
[0038]
An embodiment of a file 300 incorporating the present invention is shown in FIG. The file 300 includes file data 316, ie, file information itself, and in this particular example, some standard attributes 304, which includes general information that may be time, file length, etc. 302. In other embodiments, the header does not include standard attributes, but may instead be stored in other sections, such as section 306 shown in FIG.
[0039]
The file 300 also has a version specific attribute 308 as shown in FIG. The version specific attribute 308 includes three types of information. One is the meta information section 310, which is typically the name of the attribute, such as the name of the third-party application used to create the attribute, the length of the attribute, the address location on the disk, etc. Information.
[0040]
The version specific attribute 308 also includes a version information section 312. The version information section 312 includes information about the most recent specific application version used to create the version specific attribute 308, such as the version of the third party application used to create the attribute. That is, since such version information can be associated with the program module whose attribute is being evaluated, a section is allocated exclusively for this type of information.
[0041]
Version specific attribute 308 also includes a mask information section 314 that is used in providing information about the associated update to the file system. The mask information section 314 essentially directs other applications or file systems which protocol or policy events can or cannot disable the version specific attribute 308.
[0042]
In certain embodiments, when the version specific attribute 308 is created by a virus scanning application that is part of or not part of the file system, the meta information section 310 is used to create the virus scanning application that was used to create the version specific attribute 308. Can hold names. Further, the version information section 312 will contain information related to the specific virus definition file used when the version specific attribute was created. Because virus scanning applications are frequently updated to include recently detected viruses, version information is important in this particular case. Thus, a virus scanning application must not only determine whether a file has been previously scanned, but also determine whether it has been scanned using an updated virus definition file.
[0043]
With respect to the mask information section 314, when the virus scanning application creates a version specific attribute 308, the mask information section 314 may include a specific event that causes the invalidation of the version specific attribute 308. May be directly related to a virus scanning application. In this particular case, such events that may cause invalidation of the version specific attribute 308 may include modification of the file data section 306 by either adding new file data or erasing the file data. is there. In other embodiments, invalidation of the version specific attribute may occur due to other predetermined events.
[0044]
In this particular example, a read-only access event, a file name change, or a file 300 may be included in a given event that does not specifically invalidate the version specific attribute because it cannot be included in the mask information section 314. Can include backups. In fact, if the event does not invalidate the version-specific attribute, the attribute remains attached to the file even if the file name is changed.
[0045]
The version specific attribute 308 is created by a third party application, for example, an application different from the file system. When creating a version specific attribute, the third party application provides name, version, and mask information to the file system. The file system then creates an attribute and associates it with the specific file. In one embodiment of the present invention, one method for creating a version specific attribute 308 includes a third party application that requires Windows NTFS to create the attribute. The commands used to create version specific attributes in this embodiment are shown in Table 1. The code shown in Table 1 is the file a. It is assumed that txt has already been created and the name of the third-party application is “Inoculan”.
[0046]
[Table 1]

[0047]
As shown in Table 1, the third-party application requires creation of a version-specific attribute and then only writes data to the attribute before the created attribute is closed. In order for this feature to work, the file system must have a version-specific attribute type defined beforehand. In other embodiments, other methods can be used to create and place version specific attributes. Once the version specific attribute 308 is created, other applications can evaluate and / or invalidate it when the file is accessed.
[0048]
In other embodiments of the present invention, other commands related to setting the security of version specific attributes may be inserted before the NTWriteFile command. A separate security descriptor can be created or defined for each version-specific attribute. Alternatively, each application, such as Inoculan, can use a digital signature to verify the integrity of the version-specific property to which the application relates. Once the security type is defined, the information can be stored before the NTWriteFile command of the version specific attribute.
[0049]
After the NTWriteFile operation, the version specific attribute can be closed using the NTClose operation.
[0050]
Although the file 300 is shown and described as having only one version-specific attribute, the file 300 may have other attributes, including other version-specific attributes as indicated by the break symbol 318. In fact, some third-party applications can require that persistence information be stored as part of the file, thus creating a number of version-specific attributes such as version-specific attributes 308, It can be stored with the file 300.
[0051]
Having discussed an exemplary physical environment, the following sections describe operational modules that embody aspects of the invention. The logical operations of the various embodiments of the present invention are interconnected as (1) a series of steps or program modules performed by a computer running on the computing system and / or (2) within the computing system. Implemented as a hardware module or logic module. This implementation is a matter of choice dependent on the performance requirements of the computing system implementing the invention. Accordingly, the logical operations making up the embodiments of the invention described herein are sometimes referred to as operations, steps, or modules.
[0052]
FIG. 4 is a flow diagram illustrating operational characteristics associated with accessing a file according to an aspect of the present invention. Before the flow 400 begins, a file such as the

file

204, 206, 208, or 210 shown in FIG. 2 exists in a file system such as the file system 202 (FIG. 2). In one embodiment of the invention, once a file is created, the flow 400 illustrated and described with respect to FIG. 4 is initiated when an attempt is made to access the file. In practice, process 400 begins with an access attempt step S402, which relates to reading, executing, or updating any file in the file system. The access attempt can be performed by a third party application, such as application program 224 (FIG. 2), or by service layer 236 (FIG. 2).
[0053]
Following the access attempt step S402, a determination act step S404 determines whether the access is a revocation access. Determining whether the access is an invalidation access includes evaluation of mask information in each version-specific attribute assuming that a plurality of specific files are accessed. By evaluating the mask information, it can be seen which type of access to the file requires that a particular version specific attribute be invalidated. Therefore, by comparing the mask information with the actual access attempt, it can be determined whether the version specific attribute should be invalidated. If such an appropriate update access attempt is identified in decision act step S404, the flow proceeds to an invalidation operation step S406 of YES.
[0054]
In one embodiment of the invention, version specific attributes are created and used by a virus scanning application. In such a situation, in decision act step S404, it is determined based on the criteria set by the virus scan application whether the access attempt is an appropriate update access. That is, the virus scanning application determines in advance what the appropriate update access is, such as whether the access attempt modifies the actual file data by changing old data or adding new data. ing. For example, a particular virus scanning application may wish to invalidate its version-specific property whenever any change is made to the data in the file, including the creation of new data. Invalidation does not occur if the change is only related to version specific properties or other file metadata or other meta information.
[0055]
In another embodiment, the iterator application can create and use version specific attributes. In such a case, the iterator application may wish to invalidate its version-specific property whenever any change is made to either the file's data or metadata. These specific version-specific properties are invalidated whenever changes are made that do not affect only the version-specific properties of this class. In this case, defining a particular class prevents the file from being repeated over and over due to the presence of multiple iterators, and each iteration instance from one iterator application is the second It will occur as needed by the iterator application.
[0056]
In the invalidation operation step S406, attributes such as the version specific property or the version specific attribute 308 (FIG. 3) are invalidated. In one embodiment, the invalidation act step S406 deletes or truncates the version-specific attribute to “invalidate” the version-specific attribute. Alternatively, the version-specific attribute is marked in the invalidation operation step S406, or otherwise an indication that the attribute is invalid is given. Essentially, the act of invalidating an attribute must allow an application that relies on the version-specific attribute to recognize that the version-specific attribute has been invalidated. Other methods of invalidating version specific attributes may include invalidation access or adding information to version specific attributes or modifying information contained therein. In the invalidation act step S406, other items such as time change, last write time, or last access time are not changed.
[0057]
If the file has multiple associated version specific attributes, operation steps S404 and S406 are repeated for each version specific attribute.
[0058]
Subsequent to the invalidation act step S406, in the access execution operation step S408, the requested access to the file is executed. It is important that the act of performing access to the file begins after the version specific attribute is invalidated. Otherwise, version-specific attributes can become unreliable. Following the access execution operation step S408, the flow 400 ends at an end operation step S410.
[0059]
If it is determined in the decision act step S404 that the access attempt is not related to the invalidation access, the flow proceeds to a determination operation step S412 of NO. In a decision operation step S412, it is determined whether the access is dependent on the version specific attribute, for example, whether the access attempt is an access attempt by an application using the version specific attribute when performing the operation. For example, a virus scanning application that uses a version-specific attribute can generate an access attempt, in which case the access attempt was generated by such an application that uses the version-specific attribute in decision operation step S412. Determine if it is a thing.
[0060]
If the access attempt is not executed by an application relying on the version specific attribute, the flow proceeds to NO access execution operation step S408. In the access execution operation step S408, the access operation requested first is executed. When the access execution operation step S408 is performed following the determination operation step S412, the access operation is not related to the operation requesting invalidation as determined by the determination action step S404. For example, this access attempt may be related to a read operation where the user cannot modify the actual data. Following the access execution operation step S408, the process flow ends at step S410 as described above.
[0061]
If it is determined in the determination operation step S412 that the access depends on the version-specific attribute, the flow proceeds to a determination action step S414 in which YES. In decision act step S414, this is analyzed to determine if the version specific attribute is valid. Determining whether an attribute is valid includes whether the attribute exists, whether it is marked invalid, or whether all information has been truncated so that it is not available. If it is determined in the decision act step S414 that the attribute is not valid, the flow proceeds to the access execution act step S416 regarding the invalid attribute of NO.
[0062]
In the execution action step S416, a predetermined function is executed based on the determination that the access is invalid. In one embodiment, if the access attempt is generated by a virus scan application, then in an execution operation step S416, such a virus scan function is performed on the file.
[0063]
Subsequent to the operation execution step S416 related to the invalid attribute, in the version specific attribute creation act step S418, the version specific attribute is created or validated for the file. Enabling version specific attributes includes creating a version specific attribute for the file or adding information to an existing version specific attribute. In other embodiments, an attribute can be validated in other ways, as long as it is later found that the attribute is valid by giving an indication that the attribute is valid. Following the version specific attribute validation act step S418, the process 400 ends at an end operation step S410.
[0064]
If it is determined in decision act step S414 that the version-specific attribute is valid, the flow proceeds to YES execution operation step S420. The execution operation step S420 relates to executing any action relating to the determination that the version specific attribute is valid. Depending on the particular application that uses version specific attributes, the execution operation step S420 may include different types of operations. In one example, when it is determined that the attribute is valid, no operation is performed in a virus scan situation or the like. In such a case, if it is determined in decision act step S414 that the version-specific attribute is valid, the file has been previously scanned and no other scan is required. Accordingly, no operation is performed on the file, and operation step S420 simply passes control to end operation step S410. In other embodiments, if the version specific attribute is determined to be valid, the operation may begin to be executed in step S420.
[0065]
The above systems and methods are compared to the traditional method of providing version information to a program module or application because the version information is part of the file rather than residing in a separate log or database file. It is quite advantageous. Accessing applications do not need to access external types of files that can become unavailable, corrupted, or otherwise unmanageable. Furthermore, the file attributes are not lost even when the power is turned off, and the attributes do not consume a large amount of operation memory as in the case of the in-memory information log. In addition, the process is automatically updated, i.e., version specific information is invalidated when an associated event occurs. By automatically invalidating the version specific information, relevant relevant updates are not missed and there is a high probability that unnecessary actions will not be performed. For example, with regard to performing virus scans, the prior art method did not retain such version information after the backup and / or duplication functions, so additional processing steps were performed. Is no longer disabled by the backup and replication functions, so virus scanning is not required when accessed in the future.
[0066]
As described above, the invention described herein can be implemented as a product, such as a computer process, a computing system, or a computer program product. A computer program product may be a computer system and computer storage medium readable by encoding computer program instructions for executing computer processes. Further, a computer program product may be a propagated signal on a carrier wave that is readable by a computer system and the encoding of computer program instructions for executing a computer process.
[0067]
Further, while the invention has been described in language specific to structural features and / or methodological steps, the invention as defined in the appended claims is intended to cover the specific features or steps described. It should be understood that this is not a limitation. As an example, other applications can utilize version specific attributes in addition to virus scanning applications and iterators. In addition, other types of file systems can benefit from the principles of the present invention. Accordingly, the specific features and steps are disclosed as preferred forms of implementing the described invention.
[Brief description of the drawings]
FIG. 1 is a functional diagram of a computer system in which the present invention can be incorporated.
FIG. 2 is a block diagram showing software components of the present invention.
FIG. 3 is a functional diagram showing the components of a file according to the present invention.
FIG. 4 is a flow diagram illustrating functional features of one embodiment of the present invention.
[Explanation of symbols]
100 Computing system environment (operating environment)
102 computer
104 processing unit
106 System memory
108 System bus
114 Basic input / output system
116 Hard disk drive
118 Magnetic disk drive
120 Nonvolatile magnetic disk
122 Optical disk drive
124 Nonvolatile optical disk
126 Hard disk drive interface
128 Magnetic disk drive interface
132 Operating system
134, 224, 226 Application program
136 Program module
138 Program data
140 keyboard
142 pointing devices
148 User input interface
150 monitors
152 video adapter
154 Remote computer
162 Adapter
164 modem
200 Software operating environment
202 File system
204, 206, 208, 210, 316 File data
212, 214, 216, 218, 302 header
220, 222, 308 Version-specific attributes
223,225 ellipsis
224 application program
228,230 Application Program Interface (API)
232,234 Operating System Interface
233 Internet
235 Network File System Interface
236 Service layer (dialogue layer)
300 files
304 Standard attributes
306 File data section
310 Meta Information Section
312 Version information section
314 Mask information section
318 Break symbol
400 process (flow)

Claims

A method of providing version-specific information relating to a virus scanning application independent of the application used to create the file in a file stored in a computer system,
The method
In response to a request from the virus scanning application, creating a version specific attribute associated with the file and including version specific information related to the virus scanning application;
Receiving a predetermined file operation request from the application and invalidating the created version specific attribute to maintain the version specific attribute to reflect an appropriate update in the file;
Receiving a request to evaluate the version specific attribute from the virus scanning application;
Providing the version specific attribute to the virus scanning application in response to a request to evaluate the version specific attribute;
Re-creating a version-specific attribute and providing it to the file if the provided version-specific attribute is invalid;
The version-specific attribute includes mask information including information related to invalidating the version-specific attribute in a predetermined file operation request, and the invalidation is performed based on an evaluation of the mask information. how to.

The method according to claim 1, wherein the version-specific information is information related to a version of a virus definition file.

The method of claim 1, wherein the predetermined file operation request is an update of file data.

The method of claim 1, further comprising providing security information in the version specific attribute.

A computer-readable computer program for executing the method according to claim 1.

A method of accessing a file stored in a computer system, comprising:
The file is an associated version-specific attribute provided by a virus-scanning application independent of the application used to create the file, the meta-information relating to the virus-scanning application, and a predetermined file operation request Having version specific attributes including mask information providing information related to invalidating the version specific attributes;
The method
Receiving the predetermined file operation request;
Determining whether the predetermined file operation request is related to invalidating access to the file by evaluating the mask information;
If the predetermined file operation request relates to disabling access to the file, executing the predetermined file operation after disabling the version-specific attribute;
If the predetermined file operation request is not related to revoking access to the file, determine whether the predetermined file operation depends on the version specific attribute, and determine that it depends; Enabling the version specific attribute if it is determined that the version specific attribute is invalid.

A computer readable computer program for executing the method of claim 6.

A computer-readable computer program that executes a computer process that manages version-specific information about files in a computer file system,
On the computer,
Version-specific information includes version-specific attributes for the file, including meta-information relating to a virus scanning application independent of the application used to generate the file, and a predetermined file operation request indicating the version-specific attribute. Storing a version specific attribute as an attribute that includes mask information that provides information related to invalidation;
A computer program for executing a computer process comprising: in response to a predetermined file operation request, invalidating the version specific attribute by evaluating mask information.

9. The computer program according to claim 8 , wherein the version specific information is information related to a virus definition file used for the virus scanning application.

The computer program product according to claim 9 , wherein the predetermined file operation request relates to modification of the file.

The computer program product of claim 10 , wherein the version specific attribute is not compromised after a file operation of one of duplication, renaming, or backup is performed.