क्या किसी फ़ाइल को उसके इनकोड द्वारा पुनर्प्राप्त किया जा सकता है?

Question

मैंने निर्दिष्ट आदेश में निम्नलिखित आदेश दिए:

$ln a b
$ls -i a b
523669 a 523669 b
$rm -f a
$ls -i b
523669 b

मैंने इस परीक्षण से निष्कर्ष निकाला कि कमांड rmवास्तव में फ़ाइल के aबजाय केवल फ़ाइल नाम ( इस परीक्षण में) को हटाता है , क्योंकि इनोड अभी भी मौजूद है और इसे किसी अन्य फ़ाइलनाम ( b) के माध्यम से पुनर्प्राप्त किया जा सकता है ।

मेरा सवाल यह है कि अगर किसी फ़ाइल को केवल एक फ़ाइल नाम से जोड़ा जाता है, जब फ़ाइल rmको निष्पादित किया जाता है, तो क्या वास्तविक फ़ाइल (यानी, इनोड) पूरी तरह से हटा दी जाती है? और यदि नहीं, तो क्या फाइल इनोड को फाइल नाम के बिना और केवल इनोड के माध्यम से पुनः प्राप्त किया जा सकता है?

Comments

मेरे लिए ओएस-विशिष्ट लगता है।

— इग्नासियो वाज़क्वेज़-अब्राम्स

@ इग्नासियो वाज़केज़-अब्राम्स। आप इसका मतलब संस्करण पर निर्भर करता है?

— user43312

नहीं, मेरा मतलब है कि यह ऑपरेटिंग सिस्टम पर निर्भर करता है। VFS में टैप करने के प्रत्येक के अलग (यदि कोई हैं ) तरीके हैं।

— इग्नासियो वाज़केज़-अब्राम्स

@Ignacio Vazquez-Abrams क्या आपके पास RHL या RHEL के बारे में कोई विचार है?

— user43312

@BruceEdiger ओएस एक्स सॉर्ट करता है। आप एक फ़ाइल सिस्टम ऑब्जेक्ट का उपयोग "फ़ाइल संदर्भ URL" का उपयोग करके कर सकते हैं, जो मूल रूप से, फ़ाइल सिस्टम नंबर और नोड नंबर से बनाया गया है। हालांकि यह आधिकारिक तौर पर उन लोगों के निर्माण के लिए समर्थित नहीं है। इसके बजाय आप एक फ़ाइल के लिए "फ़ाइल संदर्भ URL" प्राप्त करते हैं और फिर उसी रनटाइम सत्र में बाद के एक्सेस के लिए पथनाम के बजाय इसका उपयोग करते हैं ताकि आपका एप्लिकेशन फ़ाइल पर उसी वॉल्यूम पर कहीं और ले जाया जा सके।

— एनालॉग फाइल

Answer 1

यदि आप किसी फ़ाइल को उसके इनोड के माध्यम से खोलने का प्रयास करते हैं, तो यह किसी भी निर्देशिका ट्रैवर्स को बायपास कर देता है। निर्देशिका ट्रैवर्सल फ़ाइल और निर्देशिका के लिए अग्रणी की अनुमति निर्धारित करने के लिए आवश्यक है। डायरेक्ट्री ट्रैवर्सल के बिना, कर्नेल के पास यह निर्धारित करने का कोई तरीका नहीं है कि कॉलिंग प्रक्रिया को फ़ाइल तक पहुंचने की अनुमति है या नहीं।

एक फ़ाइल डिस्क्रिप्टर से किसी फ़ाइल के लिए लिंक बनाने की अनुमति देने के लिए लिनक्स कर्नेल में एक प्रस्तावित पैच था । इसे अस्वीकार कर दिया गया क्योंकि इसे सुरक्षित रूप से लागू करना बेहद कठिन था ।

लिनक्स के तहत (और शायद इसी कारण से अन्य यूनिक्स वेरिएंट पर), आप एक डिलीट फाइल का लिंक नहीं बना सकते हैं, इसलिए यदि किसी फाइल का अब नाम नहीं है, तो आप एक को फिर से नहीं जोड़ सकते। आप एक डिलीट को खोल सकते हैं। के तहत जादू लिंक खोलने के द्वारा फ़ाइल /proc/$pid/fd/।

यदि किसी फ़ाइल में अब कोई लिंक नहीं है और वह अब खुली नहीं है, तो वह मौजूद नहीं है और पूर्व में उसके डेटा द्वारा उपयोग किए गए स्थान को किसी भी समय पुनर्प्राप्त किया जा सकता है।

¹ _{आप इसे फाइल सिस्टम में सीधे फाइल सिस्टम में बाइट्स को ट्वीडलिंग करके कर सकते हैं, उदाहरण के debugfsलिए ext2 / ext3 / ext4 के साथ। इसके लिए उस डिवाइस तक पहुंच की आवश्यकता होती है जिस पर फाइलसिस्टम आरोहित होता है (अर्थात आमतौर पर केवल रूट ही इसे आज़मा सकता है)। हालाँकि, जब डीबगफ़ किसी फ़ाइल को इनोड द्वारा एक्सेस कर सकता है, तो यह फ़ाइल डिलीट होने पर मदद नहीं करता है: यदि एप्लिकेशन इसे बंद कर देता है, तो फाइल सही मायने में डिलीट हो जाएगी, और माउंटेड फाइल सिस्टम पर रीड-राइट मोड में डिबगफिश चलाना एक नुस्खा है आपदा।}

Answer 2

लिनक्स पर, debugfsइंटरएक्टिव ext2 / ext3 / ext4 फाइल सिस्टम डिबगर एक lnकमांड प्रदान करता है जो एक इनोड संख्या को ले सकता है filespecऔर संबंधित फाइल के लिए एक नया हार्ड लिंक बना सकता है। व्यवहार में, इसके लिए यह आवश्यक है कि अनलिंक की गई फ़ाइल को एक प्रक्रिया द्वारा खुला रखा जाए , जिससे एक खुली फाइल का विवरण अंदर रहे /proc/[pid]/fd/[n]। हटाए गए फ़ाइल पर यह प्रयास करने से फ़ाइल सिस्टम में भ्रष्टाचार होने की संभावना होगी।

ऐसा इसलिए है क्योंकि यह सुनिश्चित करने के लिए कि ext3 (और विस्तार से ext4) किसी दुर्घटना के बाद सुरक्षित रूप से एक अनलिंक को फिर से शुरू कर सकता है, यह वास्तव में इनकोड में ब्लॉक पॉइंटर्स को शून्य करता है , जबकि ext2 सिर्फ इन ब्लॉकों को ब्लॉक बिटपैप में अप्रयुक्त के रूप में चिह्नित करता है और चिह्नित करता है "हटाए गए" के रूप में इनकोड और अकेले ब्लॉक पॉइंटर्स को छोड़ देता है। फिर भी, चूंकि हार्ड लिंक बनाने के लिए फाइल सिस्टम को रीड-राइट पर माउंट करना पड़ता है, इसलिए डिलीट की गई फाइल के लिए आरक्षित ब्लॉक पहले ही रीकॉल हो गए होंगे।

कर्नेल संस्करण 2.6.39 से पहले यह हुआ करता था कि GNU कोरुटिल्स v8.0 में पेश किए गए विकल्प का उपयोग किसी खुली फाइल डिस्क्रिप्टर के माध्यम से अनलिंक की गई फ़ाइल को पुनर्प्राप्त करने के लिए किया जा सकता है यदि अनलिंक की गई फ़ाइल और नए हार्डलिंक दोनों ही tmpfs फाइल सिस्टम पर रहते हैं । इस क्षमता को तब से अक्षम कर दिया गया है, क्योंकि गिल्स ने बताया है, एक फाइल डिस्क्रिप्टर से सीधे हार्ड लिंक निर्माण की अनुमति देने में शामिल सुरक्षा विचार।ln -L|--logical/proc/[pid]/fd/[n]

Comments

मैंने बस ln -Lएक डिलीट फाइल को रिकवरी / रिकवरी से रिकवर करने की कोशिश की और त्रुटि मिली: "ऐसी कोई फाइल या डायरेक्टरी नहीं", इसलिए मुझे नहीं लगता कि यह इसका समर्थन करता है। मेरे पास ut.२१ है।

— विंगडसुबमरिन

ln -Lतुम जो कहते हो वह नहीं करता है। यह बताता है lnकि यदि स्रोत एक प्रतीकात्मक लिंक है, तो उसे लक्ष्य को कड़ी करना चाहिए। प्रतीकात्मक लिंक /proc/$pid/fdविशेष हैं, और कड़ी से कड़ी जोड़ना (deleted)काम नहीं करता है।

— गिल्स एसओ- बुराई को रोकें '

debugfsयदि फ़ाइल को हटा दिया गया है तो भी मदद नहीं करेगा - जब तक कि आप इसे एक माउंटेड फाइल सिस्टम पर रीड-राइट मोड में चलाने का जोखिम नहीं उठाना चाहते, जो कि पूरी फाइल सिस्टम को पूरी तरह से मेन्यू करने की संभावना है।

— गिल्स एसओ- बुराई को रोकें '

के संबंध में उत्तर अपडेट किया ln -L। यह /proc/[pid]/fd/[n]कुछ विशेष परिस्थितियों में उपयोग करने से कठिन लिंक बनाने के लिए संभव हुआ करता था, लेकिन यह तब से तय किया गया है।

— थॉमस निमन सेप

debugfsकी lnबहुत कम स्तर है और केवल एक नाम बनाता है, गणना को अपडेट नहीं करता है और न ही अप्रयुक्त के रूप में ब्लॉक unmarks तो यह है अत्यधिक खतरनाक । पसंद करते हैं debugfsकी undelजो देस है, उन सभी। चेतावनी: debugfsहै चलाने के लिए नहीं एक फाइल सिस्टम घुड़सवार पर जब तक आप राख करने के लिए अपने एफएस जल प्राप्त करने के अवसर लेना चाहते हैं।

— ल्लोकेई

Answer 3

1970 के दशक के बाद से हर UNIX फाइल सिस्टम में 'ln' और 'rm' कमांड ने ठीक इसी तरह काम किया है। मैक OSX, BSD और Linux सभी को यह मूल डिज़ाइन विरासत में मिला है।

अपने आप में, एक UNIX फ़ाइल का कोई नाम नहीं है, केवल एक इनोड नंबर या इनम है। लेकिन आप इसे केवल एक विशेष "निर्देशिका" फ़ाइल में प्रविष्टि के माध्यम से एक्सेस कर सकते हैं, जो प्रश्न में एक नाम को संबद्ध करता है; आप सीधे इनम निर्दिष्ट नहीं कर सकते।

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

एक गैर-निर्देशिका फ़ाइल में किसी भी पथ के नाम हो सकते हैं, जिन्हें "हार्ड लिंक" के रूप में जाना जाता है, और यह तब तक मौजूद रहेगा जब तक कि इसके सभी पथ नामों को हटा दिया गया हो और अंतिम प्रक्रिया ने फ़ाइल को बंद कर दिया हो। तब फ़ाइल वास्तव में हटा दी जाती है और इसका स्थान पुन: उपयोग के लिए उपलब्ध है। यही है, आप एक एकल-लिंक की गई फ़ाइल (या खोल सकते हैं) को खोल सकते हैं और तब अनलिंक कर सकते हैं () इसलिए यह अब फ़ाइल सिस्टम नाम स्थान में दिखाई नहीं देता है, लेकिन फ़ाइल तब तक मौजूद रहेगी जब तक आप इसे बंद नहीं करते। यह अस्थायी खरोंच फ़ाइलों के लिए उपयोगी है जो किसी अन्य प्रोग्राम द्वारा नहीं पढ़ा जाएगा।

हालाँकि, निर्देशिका में इनोड नंबर होते हैं, अधिकांश फ़ाइल सिस्टम उनके लिए कड़ी लिंक को अस्वीकार कर देते हैं; वे केवल एक अन्य निर्देशिका में दिखाई दे सकते हैं। (एक असामान्य अपवाद मैक OSX HFS + फ़ाइल सिस्टम है; यह टाइम मशीन बैकअप को काम करने देता है।) आप अभी भी निर्देशिकाओं (या किसी अन्य फ़ाइल) के लिए "सॉफ्ट लिंक" बना सकते हैं। एक नरम लिंक एक निर्देशिका प्रविष्टि जैसा दिखता है सिवाय इसके कि इसमें एक पथ के बजाय एक और पथ का नाम है।

प्रत्येक UNIX फ़ाइल में एक स्वामी, समूह और पहुंच अनुमतियां हैं। यह आवश्यक है लेकिन पर्याप्त नहीं है कि वे आपको फ़ाइल खोलने दें; आपके पास इसे संदर्भित करने के लिए उपयोग किए जाने वाले पथनाम में प्रत्येक निर्देशिका के लिए कम से कम निष्पादन की अनुमति होनी चाहिए। यही कारण है कि इसकी इनकोड संख्या द्वारा UNIX फ़ाइल खोलने का कोई मानक तरीका नहीं है; यह एक महत्वपूर्ण, व्यापक रूप से इस्तेमाल सुरक्षा तंत्र को बायपास करेगा।

लेकिन इसकी व्याख्या यह नहीं है कि रूट (विशेषाधिकार प्राप्त) उपयोगकर्ता के लिए इनोड नंबर द्वारा फ़ाइल खोलने का कोई मानक तरीका क्यों नहीं हो सकता है , क्योंकि अनुमतियों की जाँच वैसे भी बाईपास है। यह कुछ सिस्टम प्रबंधन कार्यों जैसे कि बैकअप के लिए बहुत उपयोगी होगा। मेरे ज्ञान के लिए, इस तरह के तंत्र मौजूद हैं, लेकिन वे सभी फाइलसिस्टम-विशिष्ट हैं; किसी भी UNIX फाइल सिस्टम के लिए ऐसा करने का कोई सामान्य तरीका नहीं है।

Comments

फ़ॉरवर्ड /मौन है, इसलिए इसे "स्लैश" कहा जाता है।

— ctrl-alt-delor

Answer 4

प्रश्न को सैद्धांतिक रूप से लिया जा सकता है (जिसे प्राप्त किया जा सकता है debugfs) या व्यावहारिक रूप से (आपातकालीन स्थिति)। बाद के मामले में, मुझे लगता है कि इरादे दिन को बचा रहे हैं और फ़ाइल की सामग्री को पुनर्स्थापित कर रहे हैं, संभवतः तत्काल (जो कि मैं इस सवाल पर कैसे उतरा, इसलिए मुझे लगता है कि यह अभी भी प्रासंगिक और उपयोगी है)।

चूंकि कोई कर्नेल एपीआई debugfsनहीं है, इसलिए इसे लाइव फाइल सिस्टम पर नहीं चलाया जाना चाहिए क्योंकि यह सीधे एफएस संरचना में हेरफेर करता है। इसलिए इसे लाइव करने के लिए, आपको किसी अन्य फ़ाइलनाम को पकड़ना होगा। फ़ाइल को अभी भी कुछ प्रक्रिया (किसी भी प्रक्रिया) द्वारा खुला मान लिया गया है, एक कभी भी सुविधाजनक फ़ाइल विवरणकर्ताओं के लिए पहुँच सकता है /proc:

$ lsof -F pf "$PWD/a" | sed 's/^p//' # find pid and file descriptor number of any process having the file open
$ pid=1234
$ ls -l /proc/$pid/fd/* | grep "$PWD/a" # find file descriptor number
$ fd=42
$ cat /proc/$pid/fd/$fd > "$PWD/a.restored" # read contents to a new filename

सुझाव:

• यदि आप सही fd के बारे में संदेह है, तो आप इस तरह के रूप कमांड चलाने कर सकते हैं fileउस पर
• यदि फ़ाइल में कोई प्रक्रिया लिखना है, तो उस प्रक्रिया को ASAP बंद करना सुनिश्चित करें या आपको नवीनतम डेटा नहीं मिलेगा। एक (अनटाइटेड) ट्रिक केवल किसी अन्य प्रक्रिया के साथ fd के माध्यम से पढ़ी गई फाइल को खोलने की हो सकती है (कोशिश करें tail -f < /proc/$pid/fd/$fd > /dev/null, लेखन प्रक्रिया से बाहर निकलें ताकि यह साफ तरीके से बाहर निकल जाए, और नई प्रक्रिया का उपयोग करें।

Comments

वह tail -f < /proc/...दूसरे सिरे में होना चाहिए ।

— मरे जेनसेन

या इसे लिखने के बजाय पहली जगह पर कॉपी करने के tail -c +0 -f लिए उपयोग करें cat, यदि लेखन प्रक्रिया केवल आकर्षक है (वापस मांगना और पुनर्लेखन नहीं)। पहले अन्य प्रक्रिया से बाहर निकलें tail, फिर tailफ़ाइल के अंत तक पहुंचने के लिए प्रतीक्षा करें ।

— पीटर कॉर्ड्स