2017-08-22 52 views
5

the related standard documentation के सावधानीपूर्वक पढ़ने के बावजूद, मैं समझ नहीं पा रहा हूं कि POSIX अनुपालन प्रणाली में अपेक्षित व्यवहार क्या है जब open सिस्टम कॉल O_CREAT|O_DIRECTORY सहित झंडे के साथ बुलाया जाता है।खुले (नाम, O_CREAT | O_DIRECTORY, मोड) के अपेक्षित व्यवहार क्या हैं?

मानक निर्दिष्ट करता है कि

O_CREAT और O_DIRECTORY सेट हैं और अनुरोध किया पहुँच मोड न O_WRONLY है और न ही O_RDWR है, परिणाम अनिर्दिष्ट है।

हालांकि यह सिस्टम के व्यवहार को (O_CREAT|O_DIRECTORY|O_WRONLY) और न ही (O_CREAT|O_DIRECTORY|O_RDWR) के साथ निर्दिष्ट नहीं करता है। दरअसल (जहां तक ​​मैं समझ सकता हूं) EISDIR पर व्यवहार केवल मौजूदा निर्देशिकाओं पर लागू होता है।

O_CREATE से संबंधित अनुभाग में, मानक यह बताता है कि, जब नामक फ़ाइल मौजूद नहीं है,

O_DIRECTORY फ़ाइल एक नियमित रूप से फ़ाइल के रूप में बनाया किया जाएगा सेट नहीं है; [...]

लेकिन फिर यह निर्दिष्ट नहीं करता है कि O_DIRECTORY भी सेट होने पर क्या होगा।

मैं (एक POSIX एक के बावजूद वास्तव में नहीं है, जो एक व्यापक रूप से इस्तेमाल प्रणाली है) दोनों NetBSD और Linux (जो बेहद POSIX अनुपालन के बारे में बहुत परवाह करता है) के मैनुअल पृष्ठों देखा है, लेकिन मैं किसी भी स्पष्टीकरण नहीं मिल रहा।

क्या यह कहना सही है कि दोनों झंडे का उपयोग अनिर्दिष्ट है? और यदि हां, तो सबसे आम व्यवहार क्या है?

open(name, O_CREAT|O_DIRECTORY, mode)mkdir के बराबर किसी भी POSIX अनुपालन ओएस पर है?

if ((fmode & (O_CREAT | O_DIRECTORY)) == (O_CREAT | O_DIRECTORY)) 
     return EINVAL; 

इसलिए इन 2 के साथ किसी भी संयोजन सीधे ऊपर को अस्वीकार कर दिया गया है:

+0

ध्यान दें कि आपको खुले झंडे (या संभवतः 'O_EXEC' या' O_SEARCH') में 'O_RDONLY', 'O_WRONLY', और' O_RDWR' में से एक को शामिल करना चाहिए)। ऐतिहासिक रूप से, उनको छोड़कर 'O_RDONLY' निर्दिष्ट करने के बराबर है (यह आमतौर पर 0 है;' O_WRONLY' सामान्यतः 1 है, और 'O_RDWR' सामान्यतः 2 है), लेकिन ये बिट मान नहीं हैं। (POSIX द्वारा निर्दिष्ट 'O_EXEC' और' O_SEARCH' विकल्प जीवन जटिल करते हैं, लेकिन न तो लिनक्स (उबंटू 16.04 एलटीएस) और न ही मैकोज़ 10.12.6 उनमें से किसी एक का समर्थन करता है।) अब मैं देखता हूं कि मुझे अपना 'दोषपूर्ण' कोड मिला - मैंने कॉपी किया आपके 'ओपन()' कमांड को महसूस किए बिना मैं नियमों का सख्ती से पालन नहीं कर रहा था। –

+0

[ओपन() '] (http://pubs.opengroup.org/onlinepubs/9699919799/functions/open.html) के लिए POSIX विनिर्देश के तर्क अनुभाग में, यह कहता है: _ इसके अलावा, 'खुला() 'O_DIRECTORY ध्वज सेट होने पर फ़ंक्शन गैर-निर्देशिकाओं को खोलने से इंकार कर देता है। यह रेस स्थितियों से बचाता है जिससे उपयोगकर्ता एक संवेदनशील फ़ाइल (उदाहरण के लिए, एक डिवाइस या एक फीफो) के लिए हार्ड लिंक को प्रतिस्थापित करके सिस्टम समझौता कर सकता है, जबकि एक विशेषाधिकार प्राप्त एप्लिकेशन चल रहा है, जहां पढ़ने के लिए भी फ़ाइल खोलने के लिए अवांछनीय दुष्प्रभाव हो सकते हैं ._ –

उत्तर

2

NetBSD ही vn_open में निम्नलिखित शामिल हैं।

लिनक्स में यह थोड़ा और अधिक बालों है, लेकिन किसी भी तुच्छ परीक्षण तुम्हें दिखाता है कि निर्देशिका या तो नहीं बना है, लेकिन आप एक फ़ाइल

किक मैं भी FreeBSD जाँच की है, जो कभी भी समाप्त के लिए

के साथ समाप्त कर सकते हैं पहले स्थान पर O_DIRECTORY के साथ कुछ भी बनाना

यदि आप जो खोज रहे हैं वह एक mkdir है जो आपको वापस एफडी देता है, मुझे डर है कि इस तरह के कुछ भी नहीं है। दूसरी ओर आप O_DIRECTORY जो कुछ भी आपने mkdir'ed से सुरक्षित रूप से खोलने में सक्षम होना चाहिए।

3

मुझे लगता है कि आपने गलत समझा है कि O_DIRECTORY का अर्थ क्या है। यह एक निर्देशिका नहीं है, लेकिन यह सुनिश्चित करने के लिए कि open(2) द्वारा खोली गई "फ़ाइल" एक निर्देशिका है।

O_DIRECTORY
पथ एक गैर निर्देशिका फाइल करने के लिए हल हो जाती है, असफल और [ENOTDIR] को errno निर्धारित किया है।

यह ठीक है कि POSIX दस्तावेज (ऊपर उद्धृत) कैसे हैं।

हालांकि इसके साथ न प्रणाली के व्यवहार को निर्दिष्ट नहीं करता (O_CREAT | O_WRONLY | O_DIRECTORY) और न ही (O_CREAT | O_DIRECTORY | O_RDWR)

O_CREAT|O_DIRECTORY|O_WRONLY और O_CREAT|O_DIRECTORY|O_RDWR के व्यवहार O_CREAT|O_WRONLY और के बराबर है O_CREAT|O_RDWR क्रमशः पथनाम (खुला (2) के लिए पहला तर्क) एक निर्देशिका है। O_DIRECTORY की उपस्थिति यह सुनिश्चित करने के लिए है कि फ़ाइल खोला जा रहा है एक निर्देशिका है - यह किसी और चीज को प्रभावित नहीं करती है।

क्या यह कहना सही है कि दोनों झंडे का उपयोग अनिर्दिष्ट है? और यदि हां, तो सबसे आम व्यवहार क्या है?

यह विशिष्ट संयोजनO_CREAT | O_DIRECTORY निर्दिष्ट नहीं है के व्यवहार का मतलब है, इसका मतलब यह नहीं है कि व्यक्तिगत झंडे (अन्य झंडे के साथ या बिना) का उपयोग अनिश्चित है।

क्या किसी भी POSIX अनुपालन ओएस पर mkdir के बराबर खुला (नाम, O_CREAT | O_DIRECTORY, मोड) है?

बिलकुल नहीं। यही कारण है कि यह अनिर्दिष्ट के रूप में छोड़ा गया है। लिनक्स पर, it's definitely not - एक नियमित रूप से फ़ाइल बनाई गई है:

जब दोनों O_CREAT और O_DIRECTORY झंडे में निर्दिष्ट कर रहे हैं और फ़ाइल पथ नाम से मौजूद नहीं है, खुला() एक नियमित रूप से फ़ाइल बनाएगा (यानी, O_DIRECTORY अनदेखा किया जाता है)।

निर्देशिका बनाने के लिए, आप mkdir(2) का उपयोग करेंगे।

1

अभी तक उत्तर सही नहीं हैं। कार्यान्वयन O_CREAT|O_DIRECTORY|O_WRONLY या O_CREAT|O_DIRECTORY|O_RDWR के माध्यम से निर्देशिका निर्माण का समर्थन करने के लिए स्वतंत्र हैं, लेकिन इनकी आवश्यकता नहीं है। यह 2014 में स्पष्ट किया गया, जैसा कि आप bug tracker of the Austin group में देख सकते हैं:

open("/path/to/existing/directory", O_CREAT)EISDIR के साथ विफल करना चाहिए, लेकिन कार्यान्वयन बनाने और एक विस्तार

रूप open("/path/to/directory", O_CREAT|O_DIRECTORY) माध्यम से एक निर्देशिका को खोलने का समर्थन करने के लिए अनुमति दी जानी चाहिए निम्नलिखित तर्क के साथ:

मानक व्यवहार निर्दिष्ट नहीं करता है जब open()के साथ कहा जाता है मौजूदा निर्देशिका पर(या O_CREAT|O_SEARCH)।इसके अतिरिक्त, कुछ सिस्टम open() फ़ंक्शन का उपयोग करके निर्देशिकाओं के निर्माण की अनुमति देना चाहते हैं। यह एक अनुमति होनी चाहिए, लेकिन आवश्यक नहीं, विस्तार।

शब्दों आप मानक

की current version से उद्धृत O_CREAT और O_DIRECTORY स्थापित कर रहे हैं और अनुरोध किया पहुँच मोड न O_WRONLY है और न ही O_RDWR है, तो परिणाम अनिर्दिष्ट है।

यह अनुमति देने के लिए किए गए परिवर्तनों में से एक था।

Rich Felkner द्वारा वर्णित अनुसार इसे अनुमति देने के कारणों में से एक यह है कि यह एक निर्देशिका को बनाने और खोलने के लिए एक इंटरफ़ेस प्रदान करेगा।

हालांकि, मुझे नहीं पता, अगर कोई पॉज़िक्स कार्यान्वयन वास्तव में open के माध्यम से निर्देशिका निर्माण प्रदान करता है।

संबंधित मुद्दे