हटाई गई फ़ाइल को अपाचे द्वारा खोला गया?


10

मान लीजिए कि एक अपाचे लॉग फ़ाइल नष्ट हो जाती है, लेकिन इसे अपाचे द्वारा खुला रखा जाता है; तब मैं यही कर रहा हूं:

pid=$(lsof | grep text.txt | awk '/deleted/ {print $2}')
fd=$(lsof | grep text.txt | awk '/deleted/ {print $4}' | grep -oE "[[:digit:]]{1,}")

cp /proc/$pid/fd/$fd directorytobecopied/testfile.txt

यह वही है जो मैं फ़ाइल को पुनर्प्राप्त करने के लिए कर रहा हूं और इसे वापस डाल दिया जहां यह था। क्या ऐसा करने का कोई सरल तरीका है क्योंकि उपरोक्त कोड अच्छा नहीं लगता है। इसके अलावा मुझे कैसे पता चलेगा कि फ़ाइल कहाँ से डिलीट की गई थी ( डाइरेक्टोबिकॉपिड ) ताकि मुझे मैन्युअल रूप से किसी से यह पूछने की ज़रूरत न पड़े कि फाइल कहाँ स्थित थी और उसे वापस वहाँ रख दिया गया था।


lsof / | awk '(/deleted/||/abc.txt/) {print "FD :-",$4,"| File Name:-",$9}'
राहुल पाटिल

जवाबों:


14

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

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

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

वह नाम जिसके तहत फ़ाइल खोली गई थी, अभी भी प्रतीकात्मक लिंक के लक्ष्य में दिखाई दे रही है: यदि फ़ाइल थी /var/log/apache/foo.log, तो लिंक का लक्ष्य है /var/log/apache/foo.log (deleted)। (यदि फ़ाइल को खोलने के बाद नाम बदल दिया गया था, तो सिमलिंक का लक्ष्य नाम बदलने को प्रतिबिंबित कर सकता है।)

इस प्रकार आप एक खुली हटाए गए फ़ाइल की सामग्री को पुनर्प्राप्त कर सकते हैं जिसे एक प्रक्रिया की PID दी गई है जो कि खुली है और यह इस तरह से खोली गई डिस्क्रिप्टर है:

recover_open_deleted_file () {
  old_name=$(readlink "$1")
  case "$old_name" in
    *' (deleted)')
      old_name=${old_name%' (deleted)'}
      if [ -e "$old_name" ]; then
        new_name=$(TMPDIR=${old_name%/*} mktemp)
        echo "$oldname has been replaced, recovering content to $new_name"
      else
        new_name="$old_name"
      fi
      cat <"$1" >"$new_name";;
    *) echo "File is not deleted, doing nothing";;
  esac
}
recover_open_deleted_file "/proc/$pid/fd/$fd"

यदि आपको केवल प्रक्रिया आईडी पता है, लेकिन विवरणक नहीं है, तो आप सभी फ़ाइलों को पुनर्प्राप्त कर सकते हैं

for x in /proc/$pid/fd/*; do
  recover_open_deleted_file "$x"
done

यदि आपको प्रक्रिया आईडी नहीं पता है, तो आप सभी प्रक्रियाओं के बीच खोज कर सकते हैं:

for x in /proc/[1-9]*/fd/*; do
  case $(readlink "$x") in
    /var/log/apache/*) recover_open_deleted_file "$x";;
  esac
done

आप इस सूची को आउटपुट के पार्स करके भी प्राप्त कर सकते हैं lsof, लेकिन यह अधिक सरल या अधिक विश्वसनीय नहीं है और न ही अधिक पोर्टेबल (यह लिनक्स-विशिष्ट किसी भी तरह है)।


आप पढ़ने या लिखने के लिए / x / fd / y खोल सकते हैं या नहीं, चाहे यह पढ़ने या लिखने के लिए खुला हो।
स्टीफन चेज़लस

यूनिक्स OS अपने खुले होने पर फ़ाइल को हटाने की अनुमति क्यों देता है ... जबकि हम इसे windows.is में नहीं कर सकते हैं। कोई
स्पष्टीकरण

@munish विंडोज एक सहकारी मल्टीटास्किंग मॉडल से शुरू हुआ: यदि कोई एप्लिकेशन गलत व्यवहार करता है, तो यह सिस्टम को नीचे ला सकता है। अधिकांश मुद्दे अब तक ठीक हो चुके हैं, लेकिन विंडोज अभी भी किसी एप्लिकेशन को किसी फ़ाइल को हाईजैक करने की अनुमति देता है: जब तक फ़ाइल खुली रहती है, तब तक उसका नाम बदला या हटाया नहीं जा सकता। यूनिक्स इसकी अनुमति नहीं देता है: किसी फ़ाइल को हटाना या उसका नाम बदलकर उसे खोलना रूढ़िवादी है।
गिल्स एसओ- बुराई को रोकना '

1
आपने मेरे लिए सिर्फ समरूपता के संग्रहालय की उत्पत्ति को बचाया! एक हजार बार धन्यवाद!
डॉटनचेन
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.