इसे और इस विस्तृत रिपोर्ट के लिए धन्यवाद!

इसलिए एक बेहतर त्रुटि संदेश और अद्यतन प्रलेखन हम सभी की आवश्यकता हो सकती है।

हां, मैं पूरी तरह से सहमत हूं।

शायद हम भी एक serializable infos / स्थिति # 666 में होना चाहिए और स्पष्ट रूप से विफल अगर फ़ाइल / देव / stdout है? ( @mpranj या यह पता लगाने का एक तरीका है कि क्या कोई फ़ाइल mmapable नहीं है? क्या यह वास्तव में किसी अनुमति से वंचित है?)

कोड (और त्रुटि संदेश) को देखकर मुझे लगता है कि वर्तमान समस्या यह है कि हम रूट एक्सेस के बिना unlink stdout पर कॉल नहीं कर सकते। इसके अलावा open शायद अस्वस्थ भी होंगे, क्योंकि stdout पहले ही खुल चुके हैं। और stdout mmapable है क्या stdout मेरे विचार से जुड़ा है पर निर्भर करता है।
यह जाँचने के लिए fstat(fileno(stdout), &stat) का उपयोग करना कि क्या यह एक नियमित फ़ाइल काम कर सकती है। शायद isatty(3) भी काम करता है।

किसी भी मामले में हम केवल यह जांच सकते हैं कि आउटपुट फ़ाइल /dev/stdout (या CON _WIN32 ) है और mmap के साथ उपयोग के लिए एक अस्थायी फ़ाइल बनाएं और बाद में बस उस stdout को कॉपी करें kdb export के आउटपुट को पाइप करने की संभावना को बनाए रखेंगे।

शायद हम भी एक serializable infos / स्थिति # 666 में होना चाहिए और स्पष्ट रूप से विफल अगर फ़ाइल / देव / stdout है?

यदि कुछ भी हो, तो मेरे पास एक दर्जा humanreadable और यदि कोई प्रारूप पढ़ने योग्य नहीं है, तो उसे tty stdout में निर्यात करने से मना कर दें।

काम करता है जब kdb export जड़ के रूप में कहा जाता है।

मुझे लगता है कि वापस ले लो ... यह कोशिश मत करो! रूट उपयोगकर्ता के रूप में kdb export <something> mmapstorage कॉल करना (भले ही स्टडआउट को पुनर्निर्देशित किया गया हो) /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 के समान ही अधिक होगा। यह अनलिंकिंग समस्या को हल करेगा (जो कि मिमीपेड फ़ाइलों के लिए आवश्यक है।) नकारात्मक पक्ष केवल प्रदर्शन की हानि है (आवश्यक संपूर्ण सामग्री की प्रतिलिपि) लेकिन फिर आयात / निर्यात सभी भंडारण प्लगइन्स के साथ काम करेगा, जो कि अधिक महत्वपूर्ण है।

मुझे लगता है कि सबसे अच्छा समाधान यह है कि kdb export और kdb import हमेशा अस्थायी फ़ाइलों पर काम करें।

मुझे लगता है कि प्लगइन्स को यदि आवश्यक हो, तो अस्थायी फ़ाइल को स्वयं बनाना चाहिए। इस तरह हम प्लगइन्स के लिए प्रदर्शन दंड से बचते हैं जो सीधे TTYs को आउटपुट कर सकते हैं। AFAIK mmapstorage वर्तमान में केवल प्लगइन है जो TTYs के साथ काम नहीं करता है। हम एक सरल शेल परीक्षण भी जोड़ सकते हैं जो यह सुनिश्चित करता है कि सभी संग्रहण प्लगइन्स को kdb export /some/key plugin > export.file माध्यम से बुलाया जा सकता है। तर्क भी अधिक आत्म-निहित है, क्योंकि यह वास्तव में प्लगइन्स जिम्मेदारी है कि यह जानने के लिए कि अपेक्षित उत्पादन कैसे किया जाए।

kdb import अस्थायी फ़ाइलें अनावश्यक हैं क्योंकि फ़ाइल पढ़ना हमेशा काम करना चाहिए, यहां तक ​​कि TTYs के लिए (यदि आपके पास सही अनुमतियाँ हैं)।

मुझे लगता है कि प्लगइन्स को यदि आवश्यक हो, तो अस्थायी फ़ाइल को स्वयं बनाना चाहिए।

तब प्लगइन्स (या अधिक विशेष रूप से एमएमएपी) को यह जानना होगा कि क्या यह केडीबी या kdb export भीतर उपयोग किया जाता है।

@mpranj आपकी क्या राय है? क्या यह एमएमएपी प्लगइन के भीतर तय किया जा सकता है?

इस तरह हम प्लगइन्स के लिए प्रदर्शन दंड से बचते हैं जो सीधे TTYs को आउटपुट कर सकते हैं।

किन मामलों में यह प्रदर्शन दंड एक समस्या है? शायद बैकअप में / प्रत्येक परीक्षण के मामले में बहाल करें?

AFAIK mmapstorage वर्तमान में एकमात्र प्लगइन है जो TTYs के साथ काम नहीं करता है।

निर्यात के लिए हाँ। लेकिन आयात के लिए हमारे पास कई प्लगइन्स थे जो काम नहीं करते हैं। यदि कोई प्लगइन fseek का उपयोग करता है या इसके समान यह स्पष्ट रूप से काम नहीं कर सकता है, उदाहरण के लिए csvstorage या mozprefs। (डंप अब तय किया जाना चाहिए)

हम एक सरल शेल टेस्ट भी जोड़ सकते हैं जो सुनिश्चित करता है कि सभी स्टोरेज प्लग इन को kdb एक्सपोर्ट / कुछ / की-प्लगइन> एक्सपोर्ट.फाइल के माध्यम से बुलाया जा सकता है।

आप परीक्षण / खोल / 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 लिए एक अस्थायी फ़ाइल बनाएँ यदि स्टडिन का उपयोग किया जाता है। सभी स्टीन को अस्थायी फ़ाइल में कॉपी करें और kdbGet कॉल करने के लिए इस फ़ाइल का उपयोग करें।
4. तीसरा तर्क मौजूद है, यह बताने के लिए kdb import और kdb export के प्रलेखन का अद्यतन करें। यह भी कहा कि यदि दो तर्क संस्करण का उपयोग किया जाता है तो हम एक अस्थायी फ़ाइल बनाते हैं।

पुनश्च। यह good first issue हो सकता है

रिपोर्टिंग के लिए धन्यवाद कि is_not_rw_storage टूट गया है, मैंने # 2423 खोला

क्षमा करें , मैं एक सप्ताह के लिए दूर था इसलिए मैं इस पर गौर नहीं कर सका।

Mmap त्रुटि संदेश भ्रामक हो सकते हैं। mmap() गैर-नियमित फ़ाइलों को मैप करने का प्रयास करते समय EACCES साथ विफल हो जाता है। मेरे ज्ञान के लिए यह stdout पर काम नहीं करेगा। यह पाइप के साथ भी काम नहीं करता है, जैसा कि # 2209 में चर्चा की गई है।

POSIX से:

Mmap () फ़ंक्शन को निम्नलिखित मेमोरी ऑब्जेक्ट्स के लिए समर्थित किया जाएगा:

• नियमित फाइलें
• [SHM] मेमोरी ऑब्जेक्ट्स को साझा किया
• [TYM] टाइप की गई मेमोरी ऑब्जेक्ट

Mmapstorage के भीतर समाधान के लिए, हम जाँच कर सकते हैं कि यह stat साथ एक नियमित फ़ाइल है या नहीं:

• जैसा कि ऊपर बताया गया है, एक नियमित रूप से नियमित फाइल पर लिखें
• एक अस्थायी मेमोरी लोकेशन (केवल मेम्मप की जगह मैलाप) लिखें और फिर नॉन रेगुलर फाइल (पाइप, स्टडआउट, ..) पर कॉपी करें।

मैं अन्य समाधानों के लिए भी खुला हूँ। ऊपर दिए गए समाधान बहुत अधिक mmapstorage तर्क नहीं बदलते हैं। पाइप या स्टडआउट के साथ काम करने के लिए mmapstorage को सीधे करना मेरे लिए बहुत ज्यादा मायने नहीं रखता है।

आपके जवाब के लिए धन्यवाद!

Mmap त्रुटि संदेश भ्रामक हो सकते हैं।

कृपया त्रुटि संदेशों में सुधार करें।

मेरे ज्ञान के लिए यह stdout पर काम नहीं करेगा। यह पाइप के साथ भी काम नहीं करता है

कृपया उस जानकारी को त्रुटि संदेशों में जोड़ें।

ऊपर दिए गए समाधान बहुत अधिक mmapstorage तर्क नहीं बदलते हैं।

जैसा कि आपका प्लगइन वर्तमान में केवल एक ही प्रभावित है, यह समझ में आता है कि आप स्टेट करते हैं और यदि आवश्यक हो तो सब कुछ कॉपी करते हैं। तब हम फ्रेमवर्क में बड़े बदलाव के बिना इस मुद्दे को बंद कर सकते थे।

तब हम फ्रेमवर्क में बड़े बदलाव के बिना इस मुद्दे को बंद कर सकते थे।

हमें kdb import और kdb export लिए मैन पेज भी अपडेट करने चाहिए। वर्तमान में वे 3 तर्क संस्करणों का उल्लेख नहीं करते हैं जो स्टड / स्टडआउट पर भरोसा नहीं करते हैं।

समस्या की रिपोर्ट करने और इनपुट के लिए दोनों का धन्यवाद!

दुर्भाग्य से, strerror इन भ्रामक त्रुटि संदेशों को प्रिंट करता है। मैं उस मामले में संकेत जोड़ सकता हूं।

मैं इस सप्ताह एक पीआर में अनुरोधित परिवर्तन करूंगा।

हमें kdb आयात और kdb निर्यात के लिए मैन पेज भी अपडेट करने चाहिए। वर्तमान में वे 3 तर्क संस्करणों का उल्लेख नहीं करते हैं जो स्टड / स्टडआउट पर भरोसा नहीं करते हैं।

शायद हमें फ़ाइल निर्दिष्ट करने के लिए तर्क की आवश्यकता नहीं है? एक बार kdb import/export का तर्क कई प्लगइन्स का समर्थन करता है।

मैं इस सप्ताह एक पीआर में अनुरोधित परिवर्तन करूंगा।

धन्यवाद!

शायद हमें फ़ाइल निर्दिष्ट करने के लिए तर्क की आवश्यकता नहीं है?

फिर हमें सभी प्लगइन्स में stdin और stdout (एक नियमित फ़ाइल पर पुनर्निर्देशित) का समर्थन करना होगा। अन्यथा वे kdb import/export साथ कभी भी उपयोग नहीं किए जा सकते थे। यह mmapstorage लिए समझ में आता है क्योंकि यह पोर्टेबल नहीं है, लेकिन अन्य प्लगइन्स जो पोर्टेबल हैं (शायद यहां तक ​​कि मानव-पठनीय हैं) को एक नियमित फ़ाइल की भी आवश्यकता हो सकती है (जैसे अगर वे fseek )।

तर्क kdb import/export एक बार प्लग इन का समर्थन करता है।

जब हम elektraGetOpts का उपयोग करने के लिए स्विच करते हैं, तो हम आसानी से -i FILE, --input=FILE , -o FILE, --ouput=FILE का उपयोग करने के लिए आगे बढ़ सकते हैं।

हां, हम -i विकल्प जोड़ सकते हैं। लेकिन प्लगइन्स (या आयात / निर्यात ढांचे) को ठीक करना ताकि स्टड / स्टडआउट काम किसी भी मामले में अच्छा हो।

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 यहाँ सभी समस्याओं को बंद करता है। यह लिनक्स पर ठीक काम करता है, मुझे बस एक बग को ठीक करने की आवश्यकता है ताकि यह बीएसडी पर भी काम करे।

मेरे पास वास्तव में एक अच्छा समाधान था ( realpath और stat ) जो दुर्भाग्य से बीएसडी पर काम नहीं करेगा। इसमें ज्यादा समय लगाने का कोई मतलब नहीं है।

मैंने इसे दूर फेंकने का फैसला किया है, इस प्रकार गैर-नियमित फ़ाइलों के साथ पूरी तरह से संगत mmapstorage नहीं बना। यह केवल kdb आयात / निर्यात के साथ काम करेगा। नया समाधान बस जाँच करेगा कि क्या kdb आयात / निर्यात का उपयोग किया जाता है, जाँच करके कि क्या फ़ाइल " /dev/stdin " या " /dev/stdout " है। यह quickdump में समान रूप से किया जाता है।

मेरे पास वास्तव में अच्छा समाधान था (realpath और stat का उपयोग करके) जो दुर्भाग्य से BSD पर काम नहीं करेगा।

यह टिप्पणी समाधान है?

इसमें ज्यादा समय लगाने का कोई मतलब नहीं है।

आप सही हैं, रूपरेखा को इसे संभालना चाहिए। मैंने # 2640 बनाया।

केवल kdb आयात / निर्यात के साथ काम करेगा

cat | kdb import वेरिएंट के साथ भी?

यह quickdump में समान रूप से किया जाता है।

मतभेद कहां हैं?

क्या इस कोड को आयात / निर्यात ढांचे में स्थानांतरित किया जा सकता है?

यह टिप्पणी समाधान है?

मैंने इसे इतिहास में छोड़ दिया लेकिन बाद में लाइनें हटा दीं। Imho बेहतर समाधान https://github.com/ElektraInitiative/libelektra/pull/2639/commits/a523f9b38b56687d532f5101c7f5cc787822308d तक था

एक समस्या यह है कि स्टड / स्टडआउट बीएसडी पर खुला () एड नहीं हो सकता है। दूसरा यह है कि आपको वास्तव में फ़ाइल को स्टेट करने के लिए रियलपैथ का उपयोग करना होगा और यह निर्धारित करना होगा कि क्या यह एक नियमित फ़ाइल है। अन्यथा स्टेट ने केवल मेरे लिए सहानुभूति के एक स्तर को हल किया। यह दृष्टिकोण मेरे लिए बीएसडी पर विफल रहा, क्योंकि realpath ने किसी भी तरह से एक फ़ाइल को हल नहीं किया।

बिल्ली के साथ भी | kdb आयात संस्करण?

हाँ!

मतभेद कहां हैं?

प्रासंगिक हिस्सा समान है, भ्रम के लिए खेद है। मेरा आशय यह है कि हम यह निर्धारित करने के लिए स्टेट का उपयोग करने के बजाय / dev / stdin के लिए स्ट्रैम्प करते हैं कि क्या यह एक नियमित फ़ाइल है। इसका मतलब है कि अगर हम / dev / fd /। मेरे अन्य समाधान ने strcmp के बजाय स्टेट का उपयोग किया इसलिए यह किसी भी पथ के साथ काम करता था।

संपादित करें :

क्या इस कोड को आयात / निर्यात ढांचे में स्थानांतरित किया जा सकता है?

हां मुझे लगता है कि कोड लगभग पूरी तरह से था, लेकिन मेरे पास बीएसडी समस्याओं को ठीक करने के लिए समय नहीं था।