2008-10-21 9 views
12

विंडोज 6 (Vista और Server 2008) उचित प्रतीकात्मक लिंक का समर्थन करता है, जिसे CreateSymbolicLink फ़ंक्शन के माध्यम से बनाया जा सकता है। लेकिन लिंक के लक्ष्य के मार्ग को प्राप्त करने के लिए एक प्रतीकात्मक लिंक पूछताछ के लिए एक समान कार्य प्रतीत नहीं होता है।मैं विंडोज़ प्रतीकात्मक लिंक के लक्ष्य पथ को प्रोग्रामेटिक रूप से कैसे एक्सेस करूं?

मुझे पता चला है कि प्रतीकात्मक लिंक पुनर्भुगतान बिंदुओं का कार्यान्वयन हैं, और इसलिए पुनर्स्थापना बिंदु कार्यों का उपयोग लक्ष्य पथ प्राप्त करने के लिए किया जा सकता है। लेकिन हेडर फाइल जिन्हें मुझे रिपर्स पॉइंट्स का उपयोग करने की आवश्यकता है, Windows Driver Kit के साथ आते हैं। वीएस -2008 के साथ इस किट को स्थापित करना एक मामूली कार्य प्रतीत होता है।

क्या कोई अच्छा काम है जिसे मैंने लिंक के लक्ष्य प्राप्त करने के लिए याद किया है, या क्या मुझे वास्तव में इस जानकारी तक पहुंचने के लिए कोड लिखने के लिए विंडोज ड्राइवर विकास वातावरण स्थापित करना है?

संपादित करें: एडम मिट्ज GetFinalPathNameByHandle के सुझाव के साथ आया था। यह फ़ंक्शन स्थानीय सिम्लिंक के लिए बहुत अच्छा काम करता है, लेकिन रिमोट लिंक (यूएनसी पथ के माध्यम से) को हल करने के लिए काम नहीं करता है।

संपादित करें 2: एडम के अनुरोध पर, यहाँ हैं मैं क्या कोशिश की है की अधिक जानकारी के:

मैं शुरू में FSCTL_GET_REPARSE_POINT/DeviceIoControl मार्ग नीचे चला गया, लेकिन यह एक REPARSE_DATA_BUFFER संरचना अर्जित करता है। इस संरचना को परिभाषित करने वाले शीर्षलेख पूरी तरह से विंडोज चालक किट के भीतर मौजूद हैं।

GetFinalPathNameByHandle() स्थानीय डिस्क पर लिंक मौजूद होने पर ठीक काम करता है (C:\...\link आदि)। उत्सुकता से, मैंने पाया कि मैं लिंक पर हैंडल प्राप्त कर सकता हूं - और इस प्रकार लक्ष्य प्राप्त करें - CreateFileW() का उपयोग करके FILE_FLAG_OPEN_REPARSE_POINT ध्वज निर्दिष्ट किया गया था या नहीं, भले ही लक्ष्य फ़ाइल मौजूद है या नहीं।

CreateFileW() और GetFinalPathNameByHandle() का उपयोग रिमोट लिंक से पूछताछ करने के लिए किया जाता है हालांकि (\\?\UNC\....), चीजें सुलझाने लगती हैं। यदि FILE_FLAG_OPEN_REPARSE_POINT निर्दिष्ट है, GetFinalPathNameByHandle() हमेशा पथ पथ को लौटाता है, लक्ष्य पथ नहीं। यदि FILE_FLAG_OPEN_REPARSE_POINT निर्दिष्ट नहीं है, तो लक्ष्य पथ वापस कर दिया गया है, लेकिन केवल तभी लक्ष्य मौजूद है और लिंक के समान मशीन पर है। यदि लिंक किसी अन्य मशीन पर इंगित करता है, तो मुझे नेटवर्क अनुमतियां त्रुटि मिलती हैं। यदि लिंक स्थानीय - गैर-मौजूद - फ़ाइल को इंगित करता है, तो मुझे एक फ़ाइल त्रुटि नहीं मिली है।

+0

कृपया स्पष्ट करें कि सिमलिंक स्वयं रिमोट सर्वर (यूएनसी के माध्यम से) पर है या यदि यह सिंकलिंक लक्ष्य है जो यूएनसी पथ है। –

+0

इसके अलावा, मुझे नहीं लगता कि आपको रिपर्स पॉइंट पढ़ने के लिए डीडीके की आवश्यकता है ("पर्स पॉइंट" जैसी कोई चीज़ नहीं)। DeviceIoControl के लिए CreateFile या FSCTL_GET_REPARSE_POINT ध्वज पर FILE_FLAG_OPEN_REPARSE_POINT ध्वज देखें। चाहे यह मदद करेगा या नहीं, मेरी पिछली टिप्पणी के आपके उत्तर पर निर्भर करता है। –

+0

एक्सप्लोरर इसे किसी भी तरह से करता है, मुझे संदेह है कि यह सीधे IO_CTL भेजकर है। इसे आज़माएं: एक निर्देशिका प्रतीकात्मक लिंक बनाएं, इसे गुण दें और आपको भूरे रंग के गंतव्य के साथ "शॉर्टकट" टैब मिलेगा। – Fowl

उत्तर

13

GetFinalPathNameByHandle

एक अंतिम पथ पथ है कि लौटे जब एक रास्ता पूरी तरह से हल हो गई है। उदाहरण के लिए, "सी: \ tmp \ mydir" नामक एक प्रतीकात्मक लिंक के लिए जो को "डी: \ yourdir" पर इंगित करता है, अंतिम फाइल सिस्टम पथ "डी: \ yourdir" होगा।

+0

@Adam, दुर्भाग्यवश, जबकि GetFinalPathNameByHandle() स्थानीय सिम्लिंक के लिए काम करता है, यह लिंक देता है, न कि दूरस्थ यूएनसी-आधारित सिम्लिंक के लिए लक्ष्य। तो मैंने सवाल फिर से खोला है। –

+0

मुझे लगता है कि मैंने पूछे गए प्रश्न का उत्तर दिया (जैसा कि आपके जेएनआई/मॉक प्रश्न बीटीडब्ल्यू ... अहम के साथ)। शायद यह एक नया सवाल है। –

+0

GetFinalPathNameByHandle मूल रूप से उत्तर है, यदि कोई केवल स्थानीय लिंक का उपयोग करना चाहता है। ऐसा लगता है कि फ़ंक्शन में एक बग है, जहां तक ​​रिमोट लिंक का संबंध है। तो मैंने इसे एक बार फिर सही जवाब के रूप में चिह्नित किया है, और चेतावनी दस्तावेज की है। –

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