sqlite3 フォルダーとその内部のファイルについて
投稿者 るきお (社会人)
投稿日時
2020/4/11 14:07:36
SQLiteはインストール不要な軽量なデータベースでなので、ツールや何かの製品が使用している場合があります。
私はSQLiteは使ったことがないので各ファイルの意味はわかりません。
N88-Basicさんの状況はよくわからないのですが、Visual StudioでN88-Basicさんが追加した拡張機能か、プロジェクトで使用しているパッケージやツールが使っているかもしれません。
Cドライブ直下に勝手にフォルダーを作るのはあまり行儀の良い機能ではないですね。
フォルダー名は意味不明の文字列ということですが「abcdefgh」で間違いないでしょうか？
ファイルの中にどのようなデータが蓄えられているのか見てみればなにかヒントになるかもしれません。たとえば、メモ帳で開いてみて、ヒントになるような文字列はないでしょうか？
(多分、メモ帳で開くと文字化けしたような文字の羅列が表示されると思いますが、よく見るとその中に人間が読める単語がまぎれている場合があります。)
SQLiteのデータベースの中を見るツールもあります。パスワードなどが要求されて開けないかもしれません。
(私は使ったことがありませんが、検索してヒットしたものを貼り付けておきます。)
https://forest.watch.impress.co.jp/library/software/sqldbbrowser/
私はSQLiteは使ったことがないので各ファイルの意味はわかりません。
N88-Basicさんの状況はよくわからないのですが、Visual StudioでN88-Basicさんが追加した拡張機能か、プロジェクトで使用しているパッケージやツールが使っているかもしれません。
Cドライブ直下に勝手にフォルダーを作るのはあまり行儀の良い機能ではないですね。
フォルダー名は意味不明の文字列ということですが「abcdefgh」で間違いないでしょうか？
ファイルの中にどのようなデータが蓄えられているのか見てみればなにかヒントになるかもしれません。たとえば、メモ帳で開いてみて、ヒントになるような文字列はないでしょうか？
(多分、メモ帳で開くと文字化けしたような文字の羅列が表示されると思いますが、よく見るとその中に人間が読める単語がまぎれている場合があります。)
SQLiteのデータベースの中を見るツールもあります。パスワードなどが要求されて開けないかもしれません。
(私は使ったことがありませんが、検索してヒットしたものを貼り付けておきます。)
https://forest.watch.impress.co.jp/library/software/sqldbbrowser/
投稿者 N88-BASIC (社会人)
投稿日時
2020/4/12 11:39:10
るきお さん、ご連絡ありがとうございます。
ご提案いただいたアプリはまだ実行しておりませんが、現状を報告させていただきます。
（１）フォルダー名については、abcdefg ではありません。記載時にややこしかったので省略してしまいました。実際は、 6cly0yyOPNcv52xbHVttEsuVTI= で、削除した後でも作成される場合も同じ名前です。
（２）Visual Studio 2019 を起動しただけでは作成されません。
（３）作成されるソースと作成されないソースがあります。
想像ですが、プロジェクトのソールフォルダーの直下に *.sln 以外のファイルがあるものが作成されるようです。
その違いは、Visual Studio 2019 にて新規作成したプロジェクトのような気がします。
（４）システムドライブを、”sqlite”で検索すると、該当するかはわかりませんが、sqlite のキーワードを持つファイルがかなりありました。
例えば、
"C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All\2.1.17\Microsoft.Data.Sqlite.dll" です。
ファイル名からすると、Sqlite を、利用している気がします。
追加パッケージ等では、Nuget を利用していますが、インストールしていないアプリでも同様の症状になります。
（５）Visual Studio 2017 にて作成したプロジェクトで（Visual Studio 2019 でアクセスしていないと思われる（確実ではありませんが）も .vs 配下の深いところに sqlite3 に関するフォルダーが存在してました。
無害なようですので、付き合っていくしかないようですが、名前だけは何とかしたいです。ただ、隠しファイルに設定されていないのに意図があるのか疑問です。
もう少し、このまま続けてみたいと思います。
ご提案いただいたアプリの利用結果は追って報告させていただきます。
ご提案いただいたアプリはまだ実行しておりませんが、現状を報告させていただきます。
（１）フォルダー名については、abcdefg ではありません。記載時にややこしかったので省略してしまいました。実際は、 6cly0yyOPNcv52xbHVttEsuVTI= で、削除した後でも作成される場合も同じ名前です。
（２）Visual Studio 2019 を起動しただけでは作成されません。
（３）作成されるソースと作成されないソースがあります。
想像ですが、プロジェクトのソールフォルダーの直下に *.sln 以外のファイルがあるものが作成されるようです。
その違いは、Visual Studio 2019 にて新規作成したプロジェクトのような気がします。
（４）システムドライブを、”sqlite”で検索すると、該当するかはわかりませんが、sqlite のキーワードを持つファイルがかなりありました。
例えば、
"C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All\2.1.17\Microsoft.Data.Sqlite.dll" です。
ファイル名からすると、Sqlite を、利用している気がします。
追加パッケージ等では、Nuget を利用していますが、インストールしていないアプリでも同様の症状になります。
（５）Visual Studio 2017 にて作成したプロジェクトで（Visual Studio 2019 でアクセスしていないと思われる（確実ではありませんが）も .vs 配下の深いところに sqlite3 に関するフォルダーが存在してました。
無害なようですので、付き合っていくしかないようですが、名前だけは何とかしたいです。ただ、隠しファイルに設定されていないのに意図があるのか疑問です。
もう少し、このまま続けてみたいと思います。
ご提案いただいたアプリの利用結果は追って報告させていただきます。
投稿者 るきお (社会人)
投稿日時
2020/4/12 12:21:30
6cly0yyOPNcv52xbHVttEsuVTI= という名前はbase64でエンコードされた文字列のように見えますが、ためしにデコードしてみるとエラーでした。どうもbase64としては不完全なもののようです。
>（３）作成されるソースと作成されないソースがあります。
>想像ですが、プロジェクトのソールフォルダーの直下に *.sln 以外のファイルがあるものが作成されるようです。
>その違いは、Visual Studio 2019 にて新規作成したプロジェクトのような気がします。
いまいち状況がわからないです。
必ず再現する手順があるんでしょうか？
また、必ず再現しない手順もあるんでしょうか？
ご質問は、Cドライブ直下にあるなぞの 6cly0yyOPNcv52xbHVttEsuVTI= という名前のフォルダーは一体何かということですよね？
>（３）作成されるソースと作成されないソースがあります。
>想像ですが、プロジェクトのソールフォルダーの直下に *.sln 以外のファイルがあるものが作成されるようです。
>その違いは、Visual Studio 2019 にて新規作成したプロジェクトのような気がします。
いまいち状況がわからないです。
必ず再現する手順があるんでしょうか？
また、必ず再現しない手順もあるんでしょうか？
ご質問は、Cドライブ直下にあるなぞの 6cly0yyOPNcv52xbHVttEsuVTI= という名前のフォルダーは一体何かということですよね？
投稿者 魔界の仮面弁士 (社会人)
投稿日時
2020/4/13 09:53:02
> .vs 配下の深いところに sqlite3 に関するフォルダーが存在してました。
.vs 配下に置かれる物については、そういう仕様ですね。
ソース管理システム(ローカル Git リポジトリ、GitHub 、SubVersion など)に対して、
ピリオドで始まるフォルダー(.vs や .svn など)を含めないようご注意ください。
> db.lock * 常に存在
名前からして、排他処理制御用のファイルかな…?
> storage.ide * 常に存在
> storage.ide-shm x 場合によっては存在
> storage.ide-wal x 場合によっては存在
ルートにあるものはさておき、上記の sqlite3 フォルダーが生成されている事例は、他にもあるようで。
http://ninagreen.hatenablog.com/entry/2018/10/31/004756
https://stackoverflow.com/questions/45802083/visual-studio-2017-15-3-0-git-changes-include-storage-ide-even-though-vs-in
まず、新規プロジェクトでも再現するかどうかを確認してみてください。
既存の特定プロジェクトのみで発生する事象なら、.sln や .vbproj をメモ帳で開き、
"..\..\..\" などの祖先パスへのアクセスが多用されていないか確認してみてください。
祖先パスへの参照が残ったままで、フォルダー名の変更やファイルの移動を行うことで
フォルダー階層が崩れてしまい、C ドライブのルートに作業フォルダーが
生成されてしまったのかもしれません。
> 6cly0yyOPNcv52xbHVttEsuVTI= という名前はbase64でエンコードされた文字列のように見えますが、
> ためしにデコードしてみるとエラーでした。どうもbase64としては不完全なもののようです。
自分も Base64 を疑いましたが、27 文字という点が不自然ではありますね。
24文字か 28 文字ならまだわかるのですが。
変形 Base64 と仮定して駄目元で復元してみましたが、
何らかの文字列を Base64 変換したものでは無さそうです。
末尾の "=" のパディングが 1 つ漏れているとすれば、
デコード結果は 19 バイト（28 文字 ÷ 4 × 3 － 2) な
E9-C9-72-D3-2C-8E-3C-D7-2F-E7-6C-5B-1D-5B-6D-12-CB-95-4C
というバイナリだったことになります。
あるいは、先頭の 1 文字が欠けているとすれば、
デコード結果は 20 バイト (28 文字 ÷ 4 × 3 － 1) な
XY-A7-25-CB-4C-B2-38-F3-5C-BF-9D-B1-6C-75-6D-B4-4B-2E-55-32
になります。（X 部は 0～F のいずれか、Y 部は 37BF のいずれか）
もう一つの可能性として考えたのは、vswhere.exe などで調べることのできる
Visual Studio の instanceId だったのですが、それにしては長すぎますね…。
https://docs.microsoft.com/ja-jp/visualstudio/install/tools-for-managing-visual-studio-instances?view=vs-2019
詳しく知りたい場合には、Process Monitor でファイルアクセスを追跡してみれば、何かわかるかも。
https://docs.microsoft.com/ja-jp/sysinternals/downloads/procmon
.vs 配下に置かれる物については、そういう仕様ですね。
ソース管理システム(ローカル Git リポジトリ、GitHub 、SubVersion など)に対して、
ピリオドで始まるフォルダー(.vs や .svn など)を含めないようご注意ください。
> db.lock * 常に存在
名前からして、排他処理制御用のファイルかな…?
> storage.ide * 常に存在
> storage.ide-shm x 場合によっては存在
> storage.ide-wal x 場合によっては存在
ルートにあるものはさておき、上記の sqlite3 フォルダーが生成されている事例は、他にもあるようで。
http://ninagreen.hatenablog.com/entry/2018/10/31/004756
https://stackoverflow.com/questions/45802083/visual-studio-2017-15-3-0-git-changes-include-storage-ide-even-though-vs-in
まず、新規プロジェクトでも再現するかどうかを確認してみてください。
既存の特定プロジェクトのみで発生する事象なら、.sln や .vbproj をメモ帳で開き、
"..\..\..\" などの祖先パスへのアクセスが多用されていないか確認してみてください。
祖先パスへの参照が残ったままで、フォルダー名の変更やファイルの移動を行うことで
フォルダー階層が崩れてしまい、C ドライブのルートに作業フォルダーが
生成されてしまったのかもしれません。
> 6cly0yyOPNcv52xbHVttEsuVTI= という名前はbase64でエンコードされた文字列のように見えますが、
> ためしにデコードしてみるとエラーでした。どうもbase64としては不完全なもののようです。
自分も Base64 を疑いましたが、27 文字という点が不自然ではありますね。
24文字か 28 文字ならまだわかるのですが。
変形 Base64 と仮定して駄目元で復元してみましたが、
何らかの文字列を Base64 変換したものでは無さそうです。
末尾の "=" のパディングが 1 つ漏れているとすれば、
デコード結果は 19 バイト（28 文字 ÷ 4 × 3 － 2) な
E9-C9-72-D3-2C-8E-3C-D7-2F-E7-6C-5B-1D-5B-6D-12-CB-95-4C
というバイナリだったことになります。
あるいは、先頭の 1 文字が欠けているとすれば、
デコード結果は 20 バイト (28 文字 ÷ 4 × 3 － 1) な
XY-A7-25-CB-4C-B2-38-F3-5C-BF-9D-B1-6C-75-6D-B4-4B-2E-55-32
になります。（X 部は 0～F のいずれか、Y 部は 37BF のいずれか）
もう一つの可能性として考えたのは、vswhere.exe などで調べることのできる
Visual Studio の instanceId だったのですが、それにしては長すぎますね…。
https://docs.microsoft.com/ja-jp/visualstudio/install/tools-for-managing-visual-studio-instances?view=vs-2019
詳しく知りたい場合には、Process Monitor でファイルアクセスを追跡してみれば、何かわかるかも。
https://docs.microsoft.com/ja-jp/sysinternals/downloads/procmon
投稿者 N88-BASIC (社会人)
投稿日時
2020/4/14 16:48:59
るきお さん、魔界の仮面弁士さん、ご連絡ありがとうございます。
色々と試してみましたが残念ながら再現を確実に行う方法は見つかっていませんが、当該プロジェクトに問題があるようです。当該アプリを別ドライブにコピーしてプロジェクトを開いても問題が発生しませんでした。
また、当該プロジェクト（C:ドライブで OneDrive 上）を削除（ゴミ箱）して、同じ名前でプロジェクトを新規作成すると同様の現象が発生しました（削除時にシステムから削除できないとのメッセージが表示され、再起動後に削除できました）。
退避していた当該プロジェクトを元のフォルダーに戻して開くと同じ現象で、別フォルダーに移すと問題ありませんでした。
当該アプリを作成中に何らかの操作をしてしまいシステムがプロジェクト名を判断して同様の現象を引き起こしているかもしれません。
色々とお知恵を拝借しましたが、現象が収まったようですのでいったん解決とさせていただきます。
今後、他のプロジェクトで同様の現象があるかもしれませんので洗い出してみます。また、ご紹介いただいた情報については、本プロジェクトが完成後、検証してみます。
今後ともよろしくお願いします。
色々と試してみましたが残念ながら再現を確実に行う方法は見つかっていませんが、当該プロジェクトに問題があるようです。当該アプリを別ドライブにコピーしてプロジェクトを開いても問題が発生しませんでした。
また、当該プロジェクト（C:ドライブで OneDrive 上）を削除（ゴミ箱）して、同じ名前でプロジェクトを新規作成すると同様の現象が発生しました（削除時にシステムから削除できないとのメッセージが表示され、再起動後に削除できました）。
退避していた当該プロジェクトを元のフォルダーに戻して開くと同じ現象で、別フォルダーに移すと問題ありませんでした。
当該アプリを作成中に何らかの操作をしてしまいシステムがプロジェクト名を判断して同様の現象を引き起こしているかもしれません。
色々とお知恵を拝借しましたが、現象が収まったようですのでいったん解決とさせていただきます。
今後、他のプロジェクトで同様の現象があるかもしれませんので洗い出してみます。また、ご紹介いただいた情報については、本プロジェクトが完成後、検証してみます。
今後ともよろしくお願いします。
一度、マイクロソフトコミュニティに問い合わせをおこない、Visual Studio に関係があると判断しました。
sqlite をインストールはしておりませんし、コントロールパネルでも確認できません。
状況は、システムドライブ（ C ）のルートに意味の不明の文字の羅列名のフォルダーが存在しすることに気が付きました。そのフォルダーを見てみると、以下のような状態でした
c:\abcdefgh
| sqlite3
| db.lock * 常に存在
storage.ide * 常に存在
storage.ide-shm x 場合によっては存在
storage.ide-wal x 場合によっては存在
Visual Studio を起動して、ソースを読み込んだ状態で、X のファイルがある場合とない場合があります（Access 2002-2003 形式の mdb を使用するアプリもあります）。
上記フォルダーを削除しても、同じ名前で作成されます。
Windows Defender で、フルスキャンしたり、オフラインスキャンをしても特に問題はありません。
作業に支障はありませんし、リリース版を実行しても特に問題はありません。
支障がないので放置してもいいのですが、なぜか気になりますので情報をお持ちでしたらご提供ください。
よろしくお願いします。