شكرا لمحاولة هذا وعلى هذا التقرير المفصل!

لذلك قد يكون كل ما نحتاجه هو رسالة خطأ أفضل ووثائق محدثة.

نعم ، أوافق تمامًا.

ربما يجب أن يكون لدينا serializable في المعلومات / الحالة # 666 ونفشل صراحة إذا كان الملف / dev / stdout؟ ( mpranj أم أن هناك طريقة لاكتشاف ما إذا كان الملف غير قابل للتنظيف؟ هل هو بالفعل مطابق للإذن؟)

بالنظر إلى الرمز (ورسالة الخطأ) أعتقد أن المشكلة الحالية هي أنه لا يمكننا استدعاء unlink على stdout بدون الوصول إلى الجذر. أيضًا قد يفشل open أيضًا ، لأن stdout مفتوح بالفعل. وما إذا كان stdout قابلاً للتشغيل أم لا يعتمد على ما هو متصل بـ stdout على ما أعتقد.
استخدام fstat(fileno(stdout), &stat) للتحقق مما إذا كان ملفًا عاديًا قد يعمل. ربما يعمل أيضًا isatty(3) .

على أي حال ، يمكننا ببساطة التحقق مما إذا كان ملف الإخراج هو /dev/stdout (أو CON لـ _WIN32 ) وإنشاء ملف مؤقت للاستخدام مع mmap وبعد ذلك قم بنسخه ببساطة إلى stdout . سيكون الأمر أبطأ بالطبع ، لكننا سنحتفظ بإمكانية توجيه الإنتاج بمقدار kdb export .

ربما يجب أن يكون لدينا serializable في المعلومات / الحالة # 666 ونفشل صراحة إذا كان الملف / dev / stdout؟

إذا كان هناك أي شيء ، فسيكون لدي حالة humanreadable وأرفض التصدير إلى tty stdout ، إذا لم يكن التنسيق قابلاً للقراءة.

يعمل عندما يتم استدعاء kdb export كجذر.

استرجع ذلك ... لا تحاول ذلك! يؤدي استدعاء 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. هذا من شأنه أن يحل مشكلة إلغاء الربط (وهو أمر ضروري لملفات mmaped). الجانب السلبي هو فقدان الأداء فقط (نسخة من المحتوى الكامل المطلوب) ولكن بعد ذلك سيعمل الاستيراد / التصدير مع جميع مكونات التخزين الإضافية ، وهو أمر أكثر أهمية من ذلك بكثير.

أعتقد أن أفضل حل هو أن kdb export و kdb import يعمل دائمًا على الملفات المؤقتة.

أعتقد أن المكونات الإضافية يجب أن تنشئ الملف المؤقت بنفسها ، إذا لزم الأمر. وبهذه الطريقة نتجنب عقوبات الأداء الخاصة بالمكونات الإضافية التي يمكن إخراجها مباشرة إلى أجهزة TTY. AFAIK mmapstorage حاليًا هو المكون الإضافي الوحيد الذي لا يعمل مع أجهزة TTY. يمكننا أيضًا إضافة اختبار shell بسيط يضمن إمكانية استدعاء جميع مكونات التخزين الإضافية عبر kdb export /some/key plugin > export.file . المنطق أيضًا أكثر احتواءًا ذاتيًا ، لأنه حقًا تقع على عاتق المكونات الإضافية مسؤولية معرفة كيفية إنتاج المخرجات المتوقعة.

أيضًا بالنسبة للملفات المؤقتة kdb import فهي غير ضرورية لأن قراءة الملف يجب أن تعمل دائمًا ، حتى بالنسبة لـ TTY (إذا كان لديك الأذونات الصحيحة).

أعتقد أن المكونات الإضافية يجب أن تنشئ الملف المؤقت بنفسها ، إذا لزم الأمر.

ثم ستحتاج المكونات الإضافية (أو بشكل أكثر تحديدًا mmap) إلى معرفة ما إذا كان يتم استخدامها داخل KDB أو kdb export .

mpranj ما هو رأيك؟ هل يمكن إصلاح ذلك داخل البرنامج المساعد mmap؟

وبهذه الطريقة نتجنب عقوبات الأداء الخاصة بالمكونات الإضافية التي يمكن إخراجها مباشرة إلى أجهزة TTY.

في أي الحالات يكون هذا الأداء عقوبة مشكلة؟ ربما في النسخ الاحتياطي / الاستعادة لكل حالة اختبار؟

AFAIK mmapstorage هو المكون الإضافي الوحيد حاليًا الذي لا يعمل مع أجهزة TTY.

للتصدير نعم. ولكن بالنسبة للاستيراد ، كان لدينا العديد من المكونات الإضافية التي لا تعمل. إذا كان البرنامج المساعد يستخدم fseek أو ما شابه ، فمن الواضح أنه لا يمكن أن يعمل ، مثل csvstorage أو mozprefs. (يجب الآن إصلاح التفريغ)

يمكننا أيضًا إضافة اختبار shell بسيط يضمن إمكانية استدعاء جميع ملحقات التخزين عبر kdb export / some / key plugin> export.file.

تقصد الاختبارات / شل / check_export.sh سطر 46؟

في أي الحالات يكون هذا الأداء عقوبة مشكلة؟

في الواقع ، ربما أبدًا. طالما أنك تستخدم 3 وسائط تصدير / استيراد بدلاً من الأنابيب. انظر الاقتراح أدناه.

تقصد الاختبارات / شل / check_export.sh سطر 46؟

نعم ، لكن هذا معطل ، لأن is_not_rw_storage لا يعمل. لم يتم التعرف حتى على dump كمكوِّن إضافي للتخزين.

أعتقد أنه لحل هذا بسرعة وسهولة ، يجب أن نقوم بما يلي:

1. إصلاح is_not_rw_storage في include_common.sh.in tests/shell/check_export.sh حتى نكتشف مشاكل مثل هذه في المستقبل.
2. في kdb export أنشئ ملفًا مؤقتًا ، فقط في حالة عدم تقديم وسيطة ثالثة. استخدم هذا الملف في مكالمات kdbSet ثم انسخ محتوياته بعد ذلك إلى stdout (لا ينبغي أن يكون أكثر من سطر أو سطرين في C ++).
3. وبالمثل بالنسبة لـ kdb import بإنشاء ملف مؤقت إذا تم استخدام stdin. انسخ كل ملفات stdin إلى الملف المؤقت واستخدم هذا الملف لاستدعاء kdbGet .
4. قم بتحديث وثائق kdb import و kdb export لتوضيح وجود الوسيطة الثالثة. اذكر أيضًا أنه إذا تم استخدام الإصدارين من الوسيطتين ، فسننشئ ملفًا مؤقتًا.

ملاحظة. قد يكون هذا good first issue

شكرًا لك على الإبلاغ عن كسر is_not_rw_storage ، لقد فتحت # 2423

آسف ، لقد كنت بعيدًا لمدة أسبوع لذلك لم أستطع النظر في الأمر.

قد تكون رسائل خطأ mmap مضللة. فشل mmap() مع EACCES عند محاولة تعيين الملفات غير العادية. على حد علمي أنها لن تعمل على stdout. كما أنه لا يعمل مع الأنابيب كما تمت مناقشته في # 2209.

من بوسيكس:

يجب دعم وظيفة mmap () لكائنات الذاكرة التالية:

• الملفات العادية
• [SHM] كائنات الذاكرة المشتركة
• [TYM] كائنات الذاكرة المكتوبة

بالنسبة للحلول داخل mmapstorage ، يمكننا التحقق مما إذا كان ملفًا عاديًا بـ stat ثم:

• الكتابة إلى ملف عادي مؤقت ، كما هو مقترح أعلاه
• الكتابة إلى موقع ذاكرة مؤقتة (ببساطة malloc بدلاً من mmap) ثم نسخها إلى الملف غير العادي (توجيه ، stdout ، ..)

أنا منفتح على الحلول الأخرى أيضًا. الحلول المذكورة أعلاه لا تغير الكثير من منطق mmapstorage. إن إعادة عمل مساحة التخزين للعمل مع الأنابيب أو stdout مباشرة لا تعني الكثير بالنسبة لي.

شكرا لك على الرد!

قد تكون رسائل خطأ mmap مضللة.

الرجاء تحسين رسائل الخطأ.

على حد علمي أنها لن تعمل على stdout. كما أنها لا تعمل مع الأنابيب

الرجاء إضافة تلك المعلومات إلى رسائل الخطأ.

الحلول المذكورة أعلاه لا تغير الكثير من منطق mmapstorage.

نظرًا لأن المكون الإضافي الخاص بك هو المكون الوحيد المتأثر حاليًا ، فمن المنطقي أن تقوم بإجراء الإحصائيات ونسخ كل شيء إذا لزم الأمر. ثم يمكننا إغلاق هذه المشكلة دون إجراء تغييرات أكبر في الإطار.

ثم يمكننا إغلاق هذه المشكلة دون إجراء تغييرات أكبر في الإطار.

يجب علينا أيضًا تحديث صفحات الرجل مقابل kdb import و kdb export . حاليًا لا يذكرون نسخ الوسائط الثلاثة التي لا تعتمد على stdin / stdout.

شكرًا لك على الإبلاغ عن المشكلة وللمدخلات!

لسوء الحظ ، يقوم strerror بطباعة رسائل الخطأ المضللة هذه. يمكنني إضافة تلميح في هذه الحالة.

سأقوم بإجراء التغييرات المطلوبة في العلاقات العامة هذا الأسبوع.

يجب علينا أيضًا تحديث صفحات الدليل لاستيراد kdb وتصدير kdb. حاليًا لا يذكرون نسخ الوسائط الثلاثة التي لا تعتمد على stdin / stdout.

ربما لا نحتاج الحجة لتحديد الملف؟ ستتعارض الوسيطة بمجرد أن يدعم kdb import/export مكونات إضافية متعددة.

سأقوم بإجراء التغييرات المطلوبة في العلاقات العامة هذا الأسبوع.

شكرا لك!

ربما لا نحتاج الحجة لتحديد الملف؟

ثم يتعين علينا دعم stdin و stdout (تمت إعادة توجيهه إلى ملف عادي) في جميع المكونات الإضافية. وإلا فلن يتم استخدامها مع kdb import/export . هذا يجعل mmapstorage مناسبًا لـ fseek ).

قد تتعارض الوسيطة بمجرد أن يدعم kdb import/export مكونات إضافية متعددة.

يمكننا الانتقال بسهولة إلى استخدام الخيارات -i FILE, --input=FILE ، -o FILE, --ouput=FILE عندما ننتقل إلى استخدام elektraGetOpts .

نعم ، يمكننا إضافة خيارات -i ، -o. لكن إصلاح المكونات الإضافية (أو إطار عمل الاستيراد / التصدير) بحيث يعمل stdin / stdout أيضًا سيكون أمرًا رائعًا في أي حال.

لإصلاح هذه المشكلة مع kdb export يكفي تنفيذ الحل البديل في الوظيفة الإضافية-> kdbSet (). لقد قمت بالفعل بتنفيذ هذا ، العلاقات العامة قريبا.

يعمل هذا الآن: kdb import user/tests/ mmapstorage < test.mmap ،
لكن هذا لا: cat test.mmap | kdb import user/tests/ mmapstorage ، لأن mmap مرة أخرى لا تستطيع التعامل معه.

لجعل الحل متسقًا (وبالتالي متوافقًا تمامًا مع الملفات غير العادية) ، ستكون هناك حاجة لحلها لوظيفة kdbGet () أيضًا. هناك ثلاثة حلول تقريبًا لهذا:

1. الكتابة إلى ملف مؤقت وإلغاء ربطه (حل قبيح إلى حد ما ، لكنه بسيط)
2. إعادة صياغة نصف عملي mmap (قبيح والكثير من العمل)
3. قم بعمل الكثير من النسخ وأعد تطبيق ksDeepDup لعمل نسخ من مجموعات المفاتيح الفوقية أيضًا (رمز قبيح حقًا وشبه بسيط)

هل أي من هذا مرغوب فيه أم أننا نتجاهله؟

أعتقد أنه يمكننا تجاهلها في الوقت الحالي ، حيث لدينا بالفعل تفريغ سريع. ما عليك سوى توثيقه على أنه غير مناسب للتسلسل. سنقوم الآن بإعادة صياغة إطار عمل الاستيراد / التصدير على أي حال ، ثم سنجد الحل المناسب. mpranj لقد

في الواقع، بل هو ربما أفضل إذا # 2639 إغلاق هذه القضية وmpranj جعل لكم واحدة جديدة ل cat ... مشكلة.

2639 يغلق جميع المشاكل هنا. إنه يعمل بشكل جيد على Linux ، أحتاج فقط إلى إصلاح الخلل حتى يعمل على BSDs أيضًا.

كان لدي حل رائع حقًا (باستخدام realpath و stat ) والذي للأسف لن يعمل على BSDs. ليس من المنطقي استثمار المزيد من الوقت فيه.

لقد قررت التخلص منه ، وبالتالي لا أجعل mmapstorage متوافقًا تمامًا مع الملفات غير العادية. ستعمل فقط مع استيراد / تصدير kdb. سيتحقق الحل الجديد ببساطة من استخدام استيراد / تصدير kdb ، عن طريق التحقق مما إذا كان الملف " /dev/stdin " أو " /dev/stdout ". يتم ذلك بالمثل في quickdump .

كان لدي حل رائع حقًا (باستخدام realpath و stat) والذي للأسف لن يعمل على BSDs.

هذا هو الحل المعلق بها؟

ليس من المنطقي استثمار المزيد من الوقت فيه.

أنت على حق ، يجب أن يتعامل الإطار مع هذا. لقد خلقت # 2640.

ستعمل فقط مع استيراد / تصدير kdb

أيضًا مع المتغير cat | kdb import ؟

يتم ذلك بالمثل في Quickdump.

أين الخلافات؟

هل يمكن نقل هذا الرمز إلى إطار عمل الاستيراد / التصدير؟

هذا هو الحل المعلق بها؟

تركته في السجل لكني أزلت السطور لاحقًا. كان الحل الأفضل لـ imho حتى https://github.com/ElektraInitiative/libelektra/pull/2639/commits/a523f9b38b56687d532f5101c7ef44c078e2308d. لاحظ أنه يعمل بشكل جيد على Linux ولكن ليس BSD.

إحدى المشكلات التي واجهتها هي أن stdin / stdout لا يمكن فتحه () على BSDs. والآخر هو أنه يتعين عليك استخدام المسار الحقيقي لإحصاء () الملف وتحديد ما إذا كان ملفًا عاديًا. بخلاف ذلك ، حل الإحصاء مستوى واحدًا فقط من الروابط الرمزية بالنسبة لي. فشل هذا النهج في BSDs بالنسبة لي ، لأن realpath حل إلى ملف غير موجود بطريقة ما.

أيضا مع القط | متغير استيراد kdb؟

نعم!

أين الخلافات؟

الجزء ذو الصلة هو نفسه ، آسف للارتباك. ما قصدته هو أننا strcmp لـ / dev / stdin بدلاً من استخدام stat لتحديد ما إذا كان ملفًا عاديًا. هذا يعني أنها ستظل تفشل إذا استخدمنا / dev / fd /. استخدم الحل الآخر الخاص بي stat بدلاً من strcmp لذا فقد عمل مع أي مسار.

تحرير :

هل يمكن نقل هذا الرمز إلى إطار عمل الاستيراد / التصدير؟

نعم ، أعتقد أن الكود كان موجودًا بالكامل تقريبًا ، لكن لم يكن لدي الوقت لإصلاح مشكلات BSD بشكل صحيح.