Terima kasih telah mencoba ini dan untuk laporan terperinci ini!

Jadi pesan kesalahan yang lebih baik dan dokumentasi yang diperbarui mungkin yang kita butuhkan.

Ya, saya setuju sepenuhnya.

Mungkin kita bahkan harus memiliki serializable di infos / status # 666 dan gagal secara eksplisit jika file tersebut adalah / dev / stdout? ( @mpranj Atau apakah ada cara untuk mendeteksi jika file tidak mmapable? Apakah itu benar-benar identik dengan izin yang ditolak?)

Melihat kode (dan pesan kesalahan) Saya pikir masalah saat ini adalah kita tidak dapat memanggil unlink pada stdout tanpa akses root. Juga open mungkin juga akan gagal, karena stdout sudah dibuka. Dan apakah stdout bisa atau tidak tergantung pada apa yang terhubung dengan stdout .
Menggunakan fstat(fileno(stdout), &stat) untuk memeriksa apakah itu file biasa mungkin berfungsi. Mungkin isatty(3) juga berfungsi.

Bagaimanapun kita dapat dengan mudah memeriksa apakah file output adalah /dev/stdout (atau CON untuk _WIN32 ) dan membuat file sementara untuk digunakan dengan mmap dan setelah itu cukup salin ke stdout . Ini tentu saja akan lebih lambat tetapi kami akan mempertahankan kemungkinan menyalurkan output kdb export .

Mungkin kita bahkan harus memiliki serializable di infos / status # 666 dan gagal secara eksplisit jika file tersebut adalah / dev / stdout?

Jika ada, saya akan memiliki status humanreadable dan menolak untuk mengekspor ke tty stdout, jika formatnya tidak dapat dibaca manusia.

Bekerja jika kdb export dipanggil sebagai root.

Aku mengambilnya kembali ... JANGAN COBA ITU! Memanggil kdb export <something> mmapstorage sebagai pengguna root (meskipun stdout dialihkan) akan menghancurkan /dev/stdout . Menggunakan /dev/stdout (misalnya melalui fopen ) tidak akan berfungsi pada sistem Anda sampai Anda membuat ulang symlink default dengan sudo rm /dev/stdout && sudo ln -s /dev/stdout /proc/self/fd/1 .

Saya pikir solusi terbaik adalah kdb export dan kdb import selalu berfungsi pada file sementara. Kemudian kdb export akan lebih mirip dengan apa yang dilakukan KDB. Ini akan menyelesaikan masalah pemutusan tautan (yang diperlukan untuk file berukuran mm.) Kelemahannya hanya hilangnya kinerja (salinan seluruh konten yang diperlukan) tetapi kemudian impor / ekspor akan bekerja dengan semua plugin penyimpanan, yang mana jauh lebih penting.

Saya pikir solusi terbaik adalah kdb export dan kdb import selalu berfungsi pada file sementara.

Saya pikir plugin harus membuat file sementara itu sendiri, jika perlu. Dengan begitu, kami menghindari penalti kinerja untuk plugin yang dapat langsung dikeluarkan ke TTY. AFAIK mmapstorage saat ini adalah satu-satunya plugin yang tidak bekerja dengan TTY. Kami juga dapat menambahkan pengujian shell sederhana yang memastikan semua plugin penyimpanan dapat dipanggil melalui kdb export /some/key plugin > export.file . Logikanya juga lebih mandiri, karena itu adalah tanggung jawab plugin untuk mengetahui bagaimana menghasilkan output yang diharapkan.

Juga untuk kdb import file sementara tidak diperlukan karena membaca file harus selalu berfungsi, bahkan untuk TTY (jika Anda memiliki izin yang benar).

Saya pikir plugin harus membuat file sementara itu sendiri, jika perlu.

Kemudian plugin (atau lebih spesifiknya mmap) perlu mengetahui apakah itu digunakan dalam KDB atau kdb export .

@mpranj Apa pendapat Anda? Bisakah ini diperbaiki di dalam plugin mmap?

Dengan begitu, kami menghindari penalti kinerja untuk plugin yang dapat langsung dikeluarkan ke TTY.

Dalam kasus apa penalti kinerja ini menjadi masalah? Mungkin di backup / restore untuk setiap test case?

Penyimpanan mm AFAIK saat ini adalah satu-satunya plugin yang tidak bekerja dengan TTY.

Untuk ekspor ya. Tetapi untuk impor kami memiliki beberapa plugin yang tidak berfungsi. Jika sebuah plugin menggunakan fseek atau yang serupa, plugin tersebut jelas tidak dapat berfungsi, misalnya csvstorage atau mozprefs. (dump sekarang harus diperbaiki)

Kami juga dapat menambahkan pengujian shell sederhana yang memastikan semua plugin penyimpanan dapat dipanggil melalui kdb export / some / key plugin> export.file.

Maksud Anda tes / shell / check_export.sh baris 46?

Dalam kasus apa penalti kinerja ini menjadi masalah?

Sebenarnya, mungkin tidak pernah. Selama Anda menggunakan versi 3 argumen ekspor / impor, bukan pemipaan. Lihat proposal di bawah.

Maksud Anda tes / shell / check_export.sh baris 46?

Ya, tapi itu rusak, karena is_not_rw_storage tidak berfungsi. Bahkan dump tidak dikenali sebagai plugin penyimpanan.

Saya pikir untuk menyelesaikan ini dengan cepat dan mudah kita harus melakukan hal berikut:

1. Perbaiki is_not_rw_storage di include_common.sh.in tests/shell/check_export.sh jadi kami mendeteksi masalah seperti ini di masa mendatang.
2. Dalam kdb export buat file sementara, hanya jika tidak ada argumen ketiga yang diberikan. Gunakan file ini di panggilan kdbSet dan kemudian salin cetak isinya ke stdout (tidak boleh lebih dari satu atau dua baris di C ++).
3. Demikian pula untuk kdb import buat file sementara jika stdin digunakan. Salin semua stdin ke file sementara dan gunakan file ini untuk memanggil kdbGet .
4. Perbarui dokumentasi kdb import dan kdb export untuk menyatakan bahwa argumen ketiga ada. Juga nyatakan bahwa jika versi dua argumen digunakan, kami membuat file sementara.

PS. Ini mungkin good first issue

Terima kasih telah melaporkan bahwa is_not_rw_storage rusak, saya membuka # 2423

Maaf , saya pergi selama seminggu jadi saya tidak bisa memeriksanya.

Pesan kesalahan mmap mungkin menyesatkan. mmap() gagal dengan EACCES saat mencoba memetakan file tidak biasa. Sepengetahuan saya itu tidak akan berhasil di stdout. Ini juga tidak bekerja dengan pipa, seperti yang dibahas dalam # 2209.

Dari POSIX:

Fungsi mmap () harus didukung untuk objek memori berikut:

• File biasa
• [SHM] Objek memori bersama
• [TYM] Objek memori yang diketik

Adapun solusi dalam mmapstorage, kita dapat memeriksa apakah itu file biasa dengan stat dan kemudian:

• tulis ke file biasa sementara, seperti yang disarankan di atas
• tulis ke lokasi memori sementara (cukup malloc bukan mmap) dan kemudian salin ke file tidak biasa (pipa, stdout, ..)

Saya juga terbuka untuk solusi lain. Solusi di atas tidak banyak mengubah logika penyimpanan mm. Mengerjakan ulang penyimpanan untuk bekerja dengan pipa atau stdout secara langsung tidak terlalu masuk akal bagi saya.

Terimakasih atas balasan anda!

Pesan kesalahan mmap mungkin menyesatkan.

Harap perbaiki pesan kesalahan.

Sepengetahuan saya itu tidak akan berhasil di stdout. Itu juga tidak bekerja dengan pipa

Harap tambahkan info itu ke pesan kesalahan.

Solusi di atas tidak banyak mengubah logika penyimpanan mm.

Karena plugin Anda saat ini satu-satunya yang terpengaruh, masuk akal jika Anda melakukan stat dan menyalin semuanya jika diperlukan. Kemudian kami dapat menutup masalah ini tanpa perubahan besar dalam kerangka kerja.

Kemudian kami dapat menutup masalah ini tanpa perubahan besar dalam kerangka kerja.

Kita juga harus memperbarui halaman manual untuk kdb import dan kdb export . Saat ini mereka tidak menyebutkan 3 versi argumen yang tidak bergantung pada stdin / stdout.

Terima kasih telah melaporkan masalah ini dan atas masukannya!

Sayangnya, strerror mencetak pesan kesalahan yang menyesatkan ini. Saya bisa menambahkan petunjuk dalam kasus itu.

Saya akan membuat perubahan yang diminta dalam PR minggu ini.

Kita juga harus memperbarui halaman manual untuk kdb import dan kdb export. Saat ini mereka tidak menyebutkan 3 versi argumen yang tidak bergantung pada stdin / stdout.

Mungkin kita tidak membutuhkan argumen untuk menentukan file? Argumen akan bentrok begitu kdb import/export mendukung banyak plugin.

Saya akan membuat perubahan yang diminta dalam PR minggu ini.

Terima kasih!

Mungkin kita tidak membutuhkan argumen untuk menentukan file?

Kemudian kita harus mendukung stdin dan stdout (dialihkan ke file biasa) di semua plugin. Jika tidak, mereka tidak akan pernah bisa digunakan dengan kdb import/export . Itu masuk akal untuk mmapstorage karena tidak portabel, tetapi plugin lain yang portabel (bahkan mungkin dapat dibaca manusia) mungkin memerlukan file biasa juga (misalnya jika mereka menggunakan fseek ).

Argumen akan bentrok begitu kdb import/export mendukung banyak plugin.

Kita dapat dengan mudah beralih menggunakan opsi -i FILE, --input=FILE , -o FILE, --ouput=FILE ketika kita beralih menggunakan elektraGetOpts .

Ya, kami dapat menambahkan opsi -i, -o. Tetapi memperbaiki plugin (atau kerangka impor / ekspor) sehingga stdin / stdout juga berfungsi akan menyenangkan dalam hal apa pun.

Untuk memperbaiki masalah ini dengan kdb export itu sudah cukup untuk menerapkan solusi di fungsi plugin-> kdbSet (). Saya sudah menerapkan ini, PR segera datang.

Ini berfungsi sekarang: kdb import user/tests/ mmapstorage < test.mmap ,
tapi ini tidak: cat test.mmap | kdb import user/tests/ mmapstorage , karena lagi-lagi mmap tidak bisa mengatasinya.

Untuk membuat solusi yang konsisten (sehingga benar-benar kompatibel dengan file non-reguler) akan diperlukan juga untuk menyelesaikannya untuk fungsi kdbGet (). Ada sekitar tiga solusi untuk ini:

1. tulis ke tempfile dan batalkan tautannya (solusi yang agak jelek, tapi sederhana)
2. mengerjakan ulang setengah dari pekerjaan mmap saya (jelek & banyak pekerjaan)
3. buat banyak salinan dan implementasikan kembali ksDeepDup untuk membuat salinan meta-keysets juga (benar-benar jelek, kode semi-sederhana)

Apakah semua ini diinginkan atau kita mengabaikannya?

Saya pikir kita bisa mengabaikannya untuk saat ini, karena kita sudah memiliki quickdump. Cukup dokumentasikan sebagai tidak cocok untuk serialisasi. Kami sekarang akan mengerjakan ulang kerangka impor / ekspor, kemudian kami akan menemukan solusi yang tepat. @mpranj Saya membatalkan

Sebenarnya, mungkin lebih baik jika # 2639 menutup masalah ini dan @mpranj Anda membuat yang baru untuk masalah cat ... .

2639 menutup semua masalah di sini. Ini berfungsi dengan baik di Linux, saya hanya perlu memperbaiki bug agar berfungsi di BSD juga.

Saya memiliki solusi yang sangat bagus (menggunakan realpath dan stat ) yang sayangnya tidak akan berfungsi di BSD. Tidak masuk akal untuk menginvestasikan lebih banyak waktu ke dalamnya.

Saya telah memutuskan untuk membuangnya, sehingga tidak membuat mmapstorage sepenuhnya kompatibel dengan file non-reguler. Ini hanya akan bekerja dengan impor / ekspor kdb. Solusi baru hanya akan memeriksa apakah kdb impor / ekspor digunakan, dengan memeriksa apakah file adalah " /dev/stdin " atau " /dev/stdout ". Ini dilakukan dengan cara yang sama di quickdump .

Saya memiliki solusi yang sangat bagus (menggunakan realpath dan stat) yang sayangnya tidak akan berfungsi di BSD.

Ini adalah solusi yang dikomentari?

Tidak masuk akal untuk menginvestasikan lebih banyak waktu ke dalamnya.

Anda benar, kerangka kerja harus menangani ini. Saya membuat # 2640.

hanya akan bekerja dengan impor / ekspor kdb

Juga dengan varian cat | kdb import ?

Ini dilakukan dengan cara yang sama di quickdump.

Dimana perbedaannya?

Bisakah kode ini dipindahkan ke kerangka impor / ekspor?

Ini adalah solusi yang dikomentari?

Saya meninggalkannya dalam sejarah tetapi menghapus garis itu nanti. Solusi imho yang lebih baik tersedia hingga https://github.com/ElektraInitiative/libelektra/pull/2639/commits/a523f9b38b56687d532f5101c7ef44c078e2308d. Perhatikan bahwa ini bekerja dengan baik di Linux tetapi tidak di BSD.

Satu masalah yang saya temui adalah stdin / stdout tidak bisa dibuka () di BSD. Yang lainnya adalah Anda benar-benar harus menggunakan realpath untuk stat () file dan menentukan apakah itu file biasa. Jika tidak, stat hanya menyelesaikan satu level symlink untuk saya. Bagi saya, pendekatan ini gagal di BSD, karena entah bagaimana realpath diselesaikan ke file yang tidak ada.

Juga dengan kucing | varian impor kdb?

Iya!

Dimana perbedaannya?

Bagian yang relevan sama, maaf atas kebingungannya. Apa yang saya maksud adalah bahwa kita strcmp untuk / dev / stdin daripada menggunakan stat untuk menentukan apakah itu file biasa. Artinya masih akan gagal jika kita menggunakan / dev / fd /. Solusi saya yang lain menggunakan stat alih-alih strcmp sehingga berfungsi dengan jalur apa pun.

Edit :

Bisakah kode ini dipindahkan ke kerangka impor / ekspor?

Ya, saya pikir kodenya hampir sepenuhnya ada, tetapi saya tidak punya waktu untuk memperbaiki masalah BSD dengan benar.