プログラムでのWindows「ドキュメント」フォルダーの正当な使用

Documentsフォルダーに配置するものだけを含めるのが好きな人は、標準のDocumentsフォルダーがこのタスクに完全に不適切であることを知っています。すべてのプログラムは、にその設定、データ、または均等に無関係な何かを入れたいようだドキュメントフォルダは、特にこの仕事のために存在するという事実にもかかわらず、フォルダ¹。

これが空に聞こえないように、個人用の「ドキュメント」フォルダを例に取ります。私がいない今まで私は決して、いかなる状況の下で、このフォルダには何も保存自分という点で、それを使用します。それでも、最上位には46個のフォルダーと3つのファイルがあり、500個のフォルダーに合計800個のファイルがあります。これは私が作成しなかった190 MBの「ドキュメント」です。明らかに、実際の文書はこの混乱ですぐに失われてしまいます。

私の質問は、次の5年間で「ドキュメント」が再び役立つように、状況を十分に改善するために何かできることはありますか？プログラマーは、それをゴミ捨て場として使用しないように、何とか教育を受けられますか？OSは、既存のAPIを介してAppDataの下に隠された「偽の」場所の報告を開始できますか または、試みは完全に無駄であるか、さらには不要ですか？

¹記録のために、「ドキュメント」の代わりに使用する必要があるさまざまな標準ディレクトリの簡単な概要を以下に示します。

• RoamingAppData以下のためのユーザー固有のデータと設定。これは、ユーザー固有の非一時データに使用するディレクトリです。ここに配置されたものはすべて、特定のユーザーがこれが構成されているネットワークにログオンするマシンで使用できます。ただし、このような環境ではログイン/ログアウトが遅くなるため、大きなファイルをここに置かないでください。
• LocalAppData以下のためのユーザーとマシン固有のデータと設定。このデータは、ユーザーごとおよびマシンごとに異なります。これは、非常に大きなユーザー固有のデータを配置する場所でもあります。
• ProgramData以下のためのマシン固有のデータと設定。これらは、ログオンしているユーザーに関係なく同じであり、ネットワーク内の他のマシンにローミングしません。
• GetTempPath使用されていないときにデータを失うことなく消去される可能性があるすべてのファイル。これは、一時データのようにキャッシュをバックアップする必要がないため、cachesなどの場所でもあります。ここに巨大なキャッシュを配置すると、ユーザーのバックアップのトラブルを軽減できます。

「ドキュメント」自体は必要があり、これまでユーザーがパスを入力するか、[保存]ダイアログで、それを選択することによって、それを手動で指定した場合に使用します。それはされる唯一の時間で、これまで「ドキュメント」にものを保存することが適当。

目に見えるインセンティブが必要です。たとえば、ユーザーが（インストール時に）Documentsフォルダーに保存するアクセス許可を提供する必要がある場合、プログラマーはその恐ろしいダイアログのトリガーを避けたいと思うでしょう。

インセンティブを取得すると、人々はそれを解決しようとしている間に「ProgramDataにマシン固有のプログラムデータを保存する」などのドキュメントを自然に見つけます。

実際、多くの問題は素晴らしい許可フレームワークによって解決できます...

私の質問は、次の5年間で「ドキュメント」が再び役立つように、状況を十分に改善するために何かできることはありますか？

理論的には、何かをすることができます。理論的には、Microsoftは次のことができます。

• ユーザー設定ファイルを配置するためのより良い場所を考え出す（その過程で、多くのアプリケーションがファイルに設定を配置する正当な理由があることを認識している）。
• これを標準のWindowsアプリケーション開発者ガイドラインに追加してください。（私はそのようなガイドラインが存在すると仮定します。）
• 作るの大きなもの、例えば経て認定のいくつかの種類のガイドラインに適合またはスコアカードを作成し、公開することにより、アプリケーションの適合性についてを。「命名と恥ずかしさ」は驚くほどうまくいくかもしれない...

Appleは伝統的にこの種のことをはるかに積極的に行ってきたと言わざるを得ません。そして、それは彼らのプラットフォームで実行されるものの品質に現れています。

あなたは質問をプログラマー教育に要約するという点で答えると思います。私はWindows APIについて十分に知りません、そして、ものを保存することDocumentsが特に簡単なら、しかしそうでなければ、アプリケーションはそれを汚染するべきではありません。データが常駐できるユーザーごとの既知の場所を持つことに帰着すると思います。あなたが話している種類のデータについては、Mac OS Xはこの~/Libraryフォルダを使用しますが、一部のアプリはまだ物事を固定していDocumentsます。Windowsにも似たようなものが存在するはずです（存在しますか？）。

個人的には、Dropboxのルートの下にある同じタイトルのフォルダーにドキュメントを保管します。これにより、作業がさらに増えますが、発生した問題からは救われます。

開発者にこれをやめさせることについて議論することを望んでいるとは思いますが、タスクバー通知アイコンのようなものになり、止められないので、Microsoftはそれらをただ敷き詰めました。

以前にDocumentsフォルダーについてブログに書いて、悪い近所から抜け出すことに例えました。ユーザーとして、私は自分でそれをきれいにしようとするためにたくさんのハックを思いつきました。招待されていないすべてのフォルダーを「非表示」としてマークすると、エクスプローラーからそれらが非表示になります。Visual Studio 2005、2008、2010フォルダーのシンボリックリンクを共通の「Visual Studio」フォルダーなどに作成します。

しかし、それを自動化するPowerShellスクリプトを使用しても、使用するすべての新しいマシンでそれを行うのにうんざりしていました。幸いなことに、Windows 7には、私にとって非常にうまく機能する別のオプションがあります。

Windows 7は、Documentsフォルダーではなく「Documents」ライブラリをデフォルトにする傾向があるためです。このライブラリから％userprofile％\ documentsフォルダーを削除し、代わりにDropboxフォルダーを追加しました。したがって、ダイアログはデフォルトでこの場所に開かれ、保存されます。[スタート]-> [ドキュメント]をクリックすると、Dropboxに移動します。

最終的には、iOS App Storeのガイドラインに似た、アプリの基本的な認定のようなものが欲しいです。しかし、彼らはドライバーメーカーにドライバーに署名させることさえできません...

長期的な戦略は、ファイル以外のドキュメントの保存を停止することだと思います。システムデータ、特に設定は、ファイルシステムよりもデータベースに似たストレージシステムに保存する必要があります。そのデータベースをWeb上のサービスと簡単かつ自動的に同期できる場合のボーナスポイントは、使用するコンピューターの数と場所に関係なく、1つの設定セットを効果的に持っていることです。

ファイルシステムの歴史についてはあまり知りませんが、そのシステムのかなり早い段階で認識されたようで、実行可能ファイルはドキュメントとは根本的に異なる「もの」です。そのため、それらは特別なフォルダー（ディレクトリと呼ばれる）に格納されC:\DOS、ユーザーは基本的にドライブの残りの部分を制御していました。

誰も、長年にわたってさらに複雑で管理不能なシステムがどのようになるか、これが何を台無しにするかを本当に予測していませんでした。テクノロジーを根本から再考し、クラウドの相乗効果を活用する時が来たと思います。会社が行う前に実行可能なオープンソースソリューションが離陸した場合のボーナスポイント:)

たとえ一部のプログラムがまだDocumentsにデータを保存しているとしても、ほとんどのデータはAppDataに保存されているため、すでに正しい方向に進んでいると思いますが、ユーザーができることはあまりありません：各プログラムはそれを担当しますします。

解決策：
1.「ドキュメント」フォルダーを右クリックし、「場所」タブを選択します。
2.「ドキュメント」の場所を「C：\ Admin \ Configs」を選択する他の場所に変更します（これが完了したら、すべてのアプリケーション、「ドキュメント」への書き込みは代わりにC：\ Admin \ Configsに送信されます。

しかし、これは問題の半分しか解決しません。次のステップはかなり明白です。

1. 「C：\ User \\ Documentation」に新しいフォルダーを作成します

そのディレクトリをライブラリに追加して古いディレクトリを削除できるはずです。「C：\ User \ ** Documentation **」に別のフォルダ名を意図的に設定します。フォルダ。

上記の事実のためにフォルダー「ドキュメント」がC：\ User \に再び表示される場合は、フォルダーを右クリックして非表示フォルダーにします。

テキストファイルに設定を保存することは、あらゆるプラットフォームに対応できる包括的なソリューションです。

開発者がクロスプラットフォーム設定データベース標準を作成しない限り、私たちのほとんどはユーザーディレクトリにダンプされたテキストファイルを使用し続けると思います。

賢い私たちは、特殊な設定ストレージエンジン（Windowsレジストリなど）を許可するシステムのさまざまな設定インターフェイスを作成します。