これを試していただき、この詳細なレポートをありがとうございます！

したがって、より良いエラーメッセージと更新されたドキュメントだけで十分かもしれません。

はい、私は完全に同意します。

たぶん、infos / status＃666にserializableがあり、ファイルが/ dev / stdoutの場合、明示的に失敗する必要がありますか？ （ @mpranjまたは、ファイルがmmapできないかどうかを検出する方法はありますか？それは、拒否されたアクセス許可と本当に同じですか？）

コード（およびエラーメッセージ）を見ると、現在の問題は、ルートアクセスなしでstdout unlinkを呼び出すことができないことだと思います。 また、 stdoutはすでに開かれているため、 openも失敗する可能性があります。 そして、 stdoutがmmapableであるかどうかは、 stdoutが接続されているものに依存すると思います。
fstat(fileno(stdout), &stat)を使用して、それが通常のファイルであるかどうかを確認すると、機能する可能性があります。 たぶんisatty(3)も機能します。

いずれにせよ、我々は、単に出力ファイルがあるかどうかをチェックすることができ/dev/stdout （またはCONについて_WIN32 ）とmmapで使用するために一時ファイルを作成し、その後、単純にそのコピーstdout 。 もちろん遅くなりますが、 kdb export出力をパイピングする可能性は保持されます。

たぶん、infos / status＃666にserializableがあり、ファイルが/ dev / stdoutの場合、明示的に失敗する必要がありますか？

どちらかといえば、私はステータスhumanreadable持ち、フォーマットが人間が読める形式でない場合、ttystdoutへのエクスポートを拒否します。

kdb exportがrootとして呼び出されたときに機能します。

私はそれを取り戻します...それを試さないでください！ rootユーザーとしてkdb export <something> mmapstorageを呼び出すと（stdoutがリダイレクトされている場合でも）、 /dev/stdout破棄されます。 使用して/dev/stdout （例えば経由fopenあなたがデフォルトのシンボリックリンクを再作成するまで、あなたのシステム上の作業はしません） sudo rm /dev/stdout && sudo ln -s /dev/stdout /proc/self/fd/1 。

最善の解決策は、 kdb exportとkdb import常に一時ファイルで機能することだと思います。 そうすると、 kdb exportはKDBが行うこととより似たものになります。 これにより、リンク解除の問題（mmapされたファイルに必要）が解決されます。欠点は、パフォーマンスの低下（必要なコンテンツ全体のコピー）のみですが、インポート/エクスポートはすべてのストレージプラグインで機能します。これは非常に重要です。

最善の解決策は、 kdb exportとkdb import常に一時ファイルで機能することだと思います。

プラグインは、必要に応じて、自分で一時ファイルを作成する必要があると思います。 そうすることで、TTYに直接出力できるプラグインのパフォーマンスの低下を回避できます。 AFAIK mmapstorageは現在、TTYで動作しない唯一のプラグインです。 kdb export /some/key plugin > export.file介してすべてのストレージプラグインを呼び出すことができることを確認する簡単なシェルテストを追加することもできます。 期待される出力を生成する方法を知るのはプラグインの責任であるため、ロジックもより自己完結型です。

また、 kdb import場合、TTYの場合でも、ファイルの読み取りは常に機能するはずなので、一時ファイルは不要です（適切なアクセス許可がある場合）。

プラグインは、必要に応じて、自分で一時ファイルを作成する必要があると思います。

次に、プラグイン（またはより具体的にはmmap）は、KDB内で使用されているのかkdb export内で使用されているのかを知る必要があります。

@mpranjあなたの意見は何ですか？ これはmmapプラグイン内で修正できますか？

そうすることで、TTYに直接出力できるプラグインのパフォーマンスの低下を回避できます。

このパフォーマンスペナルティが問題になるのはどの場合ですか？ たぶん、すべてのテストケースのバックアップ/復元にありますか？

AFAIK mmapstorageは現在、TTYで機能しない唯一のプラグインです。

輸出用はい。 しかし、インポートには、機能しないプラグインがいくつかありました。 プラグインがfseekまたは同様のものを使用している場合、csvstorageやmozprefsなどは明らかに機能しません。 （ダンプは修正されているはずです）

kdb export / some / key plugin> export.fileを介してすべてのストレージプラグインを呼び出すことができることを確認する簡単なシェルテストを追加することもできます。

あなたはtests / shell / check_export.sh 46行目を意味しますか？

このパフォーマンスペナルティが問題になるのはどの場合ですか？

実際、おそらく決してないでしょう。 パイピングの代わりにエクスポート/インポートの3つの引数バージョンを使用する限り。 以下の提案を参照してください。

あなたはtests / shell / check_export.sh 46行目を意味しますか？

はい、しかしis_not_rw_storageが機能しないため、それは壊れています。 dumpでさえストレージプラグインとして認識されません。

これをすばやく簡単に解決するには、次のようにする必要があります。

1. include_common.sh.in tests/shell/check_export.sh is_not_rw_storageを修正して、将来このような問題を検出できるようにします。
2. kdb export 、3番目の引数が指定されていない場合にのみ、一時ファイルを作成します。 このファイルをkdbSet呼び出しで使用し、その後、その内容をstdoutにコピー印刷します（C ++では1行または2行を超えてはなりません）。
3. 同様に、 kdb import場合、stdinを使用する場合は一時ファイルを作成します。 すべてのstdinを一時ファイルにコピーし、このファイルを使用してkdbGetを呼び出します。
4. kdb importとkdb exportのドキュメントを更新して、3番目の引数が存在することを示します。 また、2つの引数のバージョンを使用する場合は、一時ファイルを作成することも述べてください。

PS。 これはgood first issueかもしれません

is_not_rw_storageが壊れていると報告していただき、ありがとうございます。＃2423を開きました

申し訳ありませんが、私は1週間不在だったため、調査できませんでした。

mmapエラーメッセージは誤解を招く可能性があります。 非正規ファイルをマップしようとすると、 mmap()がEACCES mmap()失敗します。 私の知る限り、stdoutでは機能しません。 また、＃2209で説明されているように、パイプでは機能しません。

POSIXから：

mmap（）関数は、次のメモリオブジェクトでサポートされます。

• 通常のファイル
• [SHM]共有メモリオブジェクト
• [TYM]型付きメモリオブジェクト

mmapstorage内のソリューションについては、それがstat通常のファイルであるかどうかを確認してから、次のようにします。

• 上記のように、一時的な通常のファイルに書き込みます
• 一時メモリの場所（mmapではなく単にmalloc）に書き込んでから、非通常のファイル（pipe、stdout、..）にコピーします。

私は他の解決策にもオープンです。 上記のソリューションは、mmapstorageロジックの多くを変更しません。 パイプまたはstdoutを直接操作するようにmmapstorageを作り直すことは、私にはあまり意味がありません。

お返事ありがとうございます！

mmapエラーメッセージは誤解を招く可能性があります。

エラーメッセージを改善してください。

私の知る限り、stdoutでは機能しません。 また、パイプでは機能しません

その情報をエラーメッセージに追加してください。

上記のソリューションは、mmapstorageロジックの多くを変更しません。

現在、影響を受けるプラグインはプラグインだけなので、統計を実行し、必要に応じてすべてをコピーすることは理にかなっています。 その後、フレームワークを大幅に変更することなく、この問題を解決できます。

その後、フレームワークを大幅に変更することなく、この問題を解決できます。

kdb importとkdb exportのマニュアルページも更新する必要があります。 現在、stdin / stdoutに依存しない3つの引数バージョンについては言及されていません。

問題の報告と入力の両方に感謝します！

残念ながら、 strerrorはこれらの誤解を招くエラーメッセージを出力します。 その場合、ヒントを追加できます。

今週はPRでリクエストされた変更を行います。

kdbインポートとkdbエクスポートのマニュアルページも更新する必要があります。 現在、stdin / stdoutに依存しない3つの引数バージョンについては言及されていません。

たぶん、ファイルを指定するために引数は必要ありませんか？ kdb import/exportが複数のプラグインをサポートすると、引数が競合します。

今週はPRでリクエストされた変更を行います。

ありがとうございました！

たぶん、ファイルを指定するために引数は必要ありませんか？

次に、すべてのプラグインでstdinとstdout （通常のファイルにリダイレクトされる）をサポートする必要があります。 そうしないと、 kdb import/exportと一緒に使用できません。 移植性がないため、 mmapstorageは意味がありますが、移植性のある他のプラグイン（おそらく人間が読める形式でも）には通常のファイルも必要になる場合があります（たとえば、 fseekを使用する場合）。

kdb import/exportが複数のプラグインをサポートすると、引数が競合します。

elektraGetOpts使用に切り替えると、オプション-i FILE, --input=FILE 、 -o FILE, --ouput=FILE使用に簡単に移行できます。

はい、-i、-oオプションを追加できます。 ただし、プラグイン（またはインポート/エクスポートフレームワーク）を修正して、stdin / stdoutも機能するようにするとどのような場合でも便利です。

kdb exportでこの問題を修正するには、plugin-> kdbSet（）関数で回避策を実装するだけで十分です。 私はすでにこれを実装しています、PRはもうすぐです。

これは現在機能します： kdb import user/tests/ mmapstorage < test.mmap 、
しかし、これはしません： cat test.mmap | kdb import user/tests/ mmapstorage 、これもmmapはそれを処理できないからです。

ソリューションの一貫性を保つには（したがって、非正規ファイルと完全に互換性があります）、kdbGet（）関数でもソリューションを解決する必要があります。 これには、おおよそ3つの解決策があります。

1. 一時ファイルに書き込み、リンクを解除します（やや醜いですが、単純な解決策）
2. 私のmmap作業の半分をやり直します（醜くてたくさんの作業）
3. 大量のコピーを作成し、ksDeepDupを再実装して、メタキーセットのコピーも作成します（本当に醜い、半単純なコード）

これは望ましいものですか、それとも無視しますか？

すでにクイックダンプがあるので、今のところ無視できると思います。 シリアル化に適していないことを文書化するだけです。 とにかくインポート/エクスポートフレームワークを作り直して、適切な解決策を見つけます。 @mpranj今のところ割り当てを

実際、＃2639でこの問題を解決し、 cat ...問題の新しい問題を作成した方が

2639はここですべての問題を閉じます。 Linuxでも問題なく動作します。バグを修正するだけで、BSDでも動作します。

私は本当に素晴らしい解決策を持っていました（ realpathとstat ）が、残念ながらBSDでは機能しません。 それにもっと多くの時間を投資することは意味がありません。

私はそれを捨てることに決めたので、mmapstorageを非正規ファイルと完全に互換性のあるものにしません。 kdbのインポート/エクスポートでのみ機能します。 新しいソリューションは、ファイルが「 /dev/stdin 」または「 /dev/stdout 」であるかどうかを確認することにより、kdbインポート/エクスポートが使用されているかどうかを確認するだけです。 quickdumpでも同様に行われます。

私は（realpathとstatを使用して）本当に素晴らしい解決策を持っていましたが、残念ながらBSDでは機能しません。

これはコメントアウトされた解決策ですか？

それにもっと多くの時間を投資することは意味がありません。

そうです、フレームワークがこれを処理する必要があります。 ＃2640を作成しました。

kdbのインポート/エクスポートでのみ機能します

cat | kdb importバリアントもありますか？

クイックダンプでも同様に行われます。

違いはどこにありますか？

このコードをインポート/エクスポートフレームワークに移動できますか？

これはコメントアウトされた解決策ですか？

私はそれを歴史に残しましたが、後で行を削除しました。 私見より良い解決策はhttps://github.com/ElektraInitiative/libelektra/pull/2639/commits/a523f9b38b56687d532f5101c7ef44c078e2308dまででした

私が遭遇した問題の1つは、BSDでstdin / stdoutをopen（）できないことです。 もう1つは、実際にrealpathを使用してファイルをstat（）し、それが通常のファイルであるかどうかを判断する必要があることです。 それ以外の場合、statは1レベルのシンボリックリンクのみを解決しました。 このアプローチは、私にとってBSDでは失敗しました。これは、realpathが何らかの形で存在しないファイルに解決されたためです。

猫とも| kdbインポートバリアント？

はい！

違いはどこにありますか？

関連する部分は同じです、混乱してすみません。 私が意味したのは、それが通常のファイルであるかどうかを判断するためにstatを使用する代わりに、/ dev / stdinに対してstrcmpを実行することです。 これは、/ dev / fd /を使用しても失敗することを意味します。 私の他のソリューションでは、strcmpの代わりにstatを使用したため、どのパスでも機能しました。

編集：

このコードをインポート/エクスポートフレームワークに移動できますか？

はい、コードはほぼ完全にそこにあったと思いますが、BSDの問題を適切に修正する時間がありませんでした。