जब एक पीसी एक फ़ाइल को संपादित करता है, तो क्या यह मूल फ़ाइल को हटाता है?


55

यदि code.txt(या जो भी फ़ाइल) संपादित की जाती है और बचाई जाती है, तो मेरे पास दो विचार हैं कि एक पीसी कैसे प्रक्रिया को संभालेगा:

  1. पीसी code.txtपूरी तरह से हटा देता है और code.txtखरोंच से एक नया (संपादित संस्करण) बनाता है ।

  2. पीसी हेक्स के हिस्से का संपादन करता है code.txt। तो कोई डिलीट नहीं होता है।

कौन सा विचार दर्शाता है कि कंप्यूटर कैसे काम करते हैं?


अभिनंदन! उपयोगकर्ता Grawity द्वारा प्रदान किए गए उत्कृष्ट उत्तर से कार्य करते हुए, यहां कुछ स्पष्ट प्रश्न दिए गए हैं:

18
@HaonDahl क्या सवालों को स्पष्ट कर रहा है? आपने कुछ भी पोस्ट नहीं किया।
द ग्रेट डक

धत तेरे की। मेरे पीसी पर वापस आने तक इंतजार करना होगा। लेकिन जिस्ट क्या स्तर है - हार्डवेयर, फाइलसिस्टम, ओएस या ऐप? और क्या ऐप?

यह आपके लिए क्यों मायने रखता है? यहां तक ​​कि "नई" फ़ाइल बनाने वाले प्रोग्राम संभवतः सृजन समय को बदल देंगे ताकि यह मूल से मेल खाए। केवल दिखाई देने वाला अंतर इनोड संख्या (या समतुल्य अवधारणा) होगा जो कुछ भी हो सकता है (जैसे कि यदि आपके आस-पास हार्डलिंक है तो उन्हें "सिंक से बाहर" मिल जाएगा)।
बाकुरू

1
इस प्रश्न को बहुत व्यापक के रूप में बंद करना। यह सब ओएस, सॉफ्टवेयर और अंतर्निहित फाइल सिस्टम की क्षमताओं पर निर्भर करता है।
जेकगोल्ड

जवाबों:


121

या तो हो सकता है - यह उस पाठ संपादक पर निर्भर करता है जिसका उपयोग किया गया था।

'टेक्स्ट फ़ाइल' की अवधारणा कंप्यूटर में निर्मित नहीं है - प्रत्येक ऑपरेटिंग सिस्टम अलग-अलग फ़ाइलों का प्रबंधन कर सकता है, और प्रत्येक पाठ संपादक उन फ़ाइलों का अलग-अलग उपयोग कर सकता है।

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

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

यहां तक ​​कि ऑपरेशन का एक तीसरा मोड भी है - संपादक पहले पुरानी फ़ाइल की बैकअप प्रतिलिपि बना सकता है, फिर सीधे फ़ाइल में नया डेटा लिख ​​सकता है।


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

हालांकि, कुछ फ़ाइल सिस्टम है "कॉपी-ऑन-राइट" मोड है, जहां कोई नया डेटा हमेशा एक अलग स्थान पर लिखा है में काम करते हैं, चाहे कार्यक्रम यह या चाहता है नहीं। फिर से, यह बढ़ी हुई विश्वसनीयता का संभावित लाभ है क्योंकि एक बाधित परिवर्तन पूरी तरह से वापस किया जा सकता है।

कुछ फाइल सिस्टम में (जैसे कि Btrfs या ext4) यह एक वैकल्पिक विशेषता है; दूसरों में (जैसे लॉग-संरचित फाइल सिस्टम) यह मूल डिजाइन का हिस्सा है।


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

7
@trlkly: सभी आधुनिक फ्लैश मेमोरी डिवाइस को उन क्षेत्रों में विभाजित किया गया है, जो डिस्क क्षेत्र की तुलना में बड़े परिमाण के आदेश हैं, और इस तरह के क्षेत्र के किसी भी हिस्से को यह सब मिटाए बिना रीसायकल नहीं कर सकते हैं। नतीजतन, यदि किसी क्षेत्र में डेटा के लायक 32 अप्रचलित क्षेत्र और उपयोगी डेटा के 224 क्षेत्र हैं, तो उसे किसी अन्य अप्रचलित क्षेत्र से स्थान खाली करने से पहले उपयोगी डेटा के 224 क्षेत्रों को कहीं और कॉपी करना होगा। आधुनिक ऑपरेटिंग सिस्टम डिस्क क्षेत्रों को इंगित करने के लिए "ट्रिम" कमांड का उपयोग करते हैं जिनकी सामग्री को छोड़ दिया जा सकता है यदि वे जिस ब्लॉक पर हैं, वह पुनर्नवीनीकरण हो जाता है।
सुपरकैट

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

2
कई संपादक बस फ़ाइल को मेमोरी में पढ़ेंगे और वहां सभी परिवर्तन करेंगे। (शायद चल रहे कार्य की प्रतिलिपि को अलग-अलग करने के लिए peiodically autosaving।) मूल फ़ाइल को तब तक नहीं बदला जाता है जब तक कि आप परिवर्तन नहीं करते हैं, जैसे vi: w कमांड के साथ।

4
@jamesqf: खैर, सवाल यह था कि क्या होता है जब एक फ़ाइल "संपादित और सहेजा जाता है " ...
विशाल

6

चूंकि आप "फ़ाइल को सहेजने" के बारे में बात कर रहे हैं, तो फ़ाइल को डिस्क पर इन-प्लेस नहीं किया जाएगा।

एक सामान्य फाइल सिस्टम में एक फ़ाइल के साथ, विचार करने के लिए दो चीजें हैं। निर्देशिका प्रविष्टि है, और फिर डिस्क पर कहीं वास्तविक फ़ाइल डेटा है।

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

विकल्प 1: मूल फ़ाइल का नाम बदल दिया गया है , इसलिए मूल निर्देशिका प्रविष्टि और मूल डेटा दोनों डिस्क पर रहेंगे। उदाहरण के लिए नाम बदलने के लिए फ़ाइल प्रत्यय .bak(किसी भी पिछले .bakफ़ाइल को हटाने , आमतौर पर) हो सकता है। फिर एक नई फ़ाइल बनाई जाती है और मेमोरी से डेटा वहां लिखा जाता है।

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

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

तो आपका सिद्धांत 1 सबसे अधिक संपादकों के करीब है।


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

तो आपका सिद्धांत 2 कुछ मामलों में संभव है, लेकिन सामान्य पाठ संपादक और ऐसा नहीं करते हैं।


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

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

4

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

हालांकि, सदी की बारी के बाद, हम एलबीए में चले गए, इसलिए अब ओएस बस "तार्किक" ब्लॉक को संदर्भित करेगा जिसे वह पढ़ना या लिखना चाहता था। हार्ड ड्राइव में अब बिना सूचना के OS के पीछे डेटा के आसपास फेरबदल करने की बुद्धिमत्ता थी। इसका मतलब बेहतर विश्वसनीयता था, क्योंकि वे क्षेत्र जो सत्यापित करने में विफल रहे, उन्हें ओएस के ज्ञान को प्रभावित किए बिना एक नए भौतिक स्थान पर ले जाया जा सकता है जहां वह डेटा स्थित था।

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

दोनों मामलों में, यह संभव है क्योंकि रिपोर्ट किए गए मूल्य से परे अप्रयुक्त क्षमता हमेशा होती है। यह ओवरप्रोविजनिंग ड्राइव को पिछली सदी की तकनीक के बजाय अविश्वसनीय तकनीक की तुलना में अधिक उपयोगी जीवन जीने की अनुमति देता है। LBA मोड, भौतिक माध्यम को OS से अलग करने में सक्षम बनाता है, ताकि डेटा हानि को रोकने के लिए ड्राइव जो भी उपाय सोचता है, वह ड्राइव स्वयं ले सके।

एप्लिकेशन स्तर पर, आप आमतौर पर "WRITE" मोड में एक फ़ाइल खोलते हैं, जो ओएस को फ़ाइल को साफ़ करने के लिए कहता है (सामग्री को हटाएं ", लेकिन फ़ाइल को खुद नहीं), फिर नया डेटा लिखें। यह सब ओएस स्तर पर बफ़र किया जाता है, फिर ड्राइव पर "फ्लश" किया जाता है, जो अनुरोधित परिवर्तन करता है।

उस जानकारी को देखते हुए, थ्योरी 1 वह है जो तकनीकी रूप से अनुप्रयोग प्रोग्रामिंग स्तर पर होती है, कम से कम डिफ़ॉल्ट रूप से, क्योंकि फ़ाइल सामग्री को साफ़ करने से बचने के लिए "अपेंड के साथ लिखना" मोड भी है। ओएस स्वयं थ्योरी 2 की तरह बदलाव करने के लिए प्रस्तुत करेगा, लेकिन एलबीए के माध्यम से अमूर्त। ड्राइव खुद ही शायद कुछ ऐसा करेगा जो थ्योरी 1 और थ्योरी 2 का मिश्रण है।

हां। यह जटिल है, और बहुत भाग-निर्माता / ओएस-डेवलपर / एप्लिकेशन-डेवलपर निर्भर है। हालाँकि, इस सभी का उद्देश्य बिजली के उपयोग / बैटरी जीवन में सुधार करते हुए डेटा भंडारण को अधिक विश्वसनीय बनाना है।


3

निर्भर करता है। AFAIK Microsoft Word, जब फास्ट सेव ऑप्शन के साथ फाइल को सेव.doc (नहीं .docx) कर रहा है , तो डॉक्यूमेंट में किए गए बदलावों को अंतिम सेव डू मौजूदा फाइल के साथ जोड़ देता है।


1

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

जैसे कि क्या नई फ़ाइल को एक ही स्थान पर लिखा गया है, कई कारकों के नीचे है, मुख्य रूप से वह सॉफ़्टवेयर जिसका आप उपयोग कर रहे हैं और यह कैसे मेमोरी का उपयोग करने के लिए डिज़ाइन किया गया है।


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

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

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

1

उम्मीद है कि यह अतिरेक नहीं है, थोड़ा अतिरिक्त जानकारी / पृष्ठभूमि।

पीसी का आमतौर पर इतना नियंत्रण नहीं होता है कि किसी फ़ाइल को कैसे संपादित किया जाता है, यह ऐसा करने वाला एप्लिकेशन है।

कुछ ऐप्स संपादन को कैसे संभाल सकते हैं, इसके कुछ उदाहरण:

नोटपैड पूरे दस्तावेज़ को मेमोरी में लोड करता है और फिर आपके मूल दस्तावेज़ (या आपके द्वारा निर्दिष्ट एक नया) पर पूरी चीज़ को बचाता है।

आपके द्वारा संपादित किए जाने पर लगभग सभी अन्य छोटे संपादक एक "नई" फ़ाइल सहेज लेंगे और फिर इसे सहेजते समय अपने मूल दस्तावेज़ को इसे हटा दें।

बड़े दस्तावेज़ संपादक जिन्हें आप किसी दस्तावेज़ के एक खंड को पढ़ने / संशोधित करने के लिए एक पुस्तक को संपादित करने के लिए उपयोग कर सकते हैं क्योंकि वे दस्तावेजों को स्मृति से बड़ा संपादित कर सकते हैं। ये वास्तव में "इन प्लेस" दस्तावेज़ को संपादित कर सकते हैं। वे एक पृष्ठ को फिर से लिख सकते हैं और बाकी को अकेले छोड़ सकते हैं। इनमें अक्सर एक साधारण .txt फ़ाइल की तुलना में अधिक जटिल अनुक्रमित ऑन-डिस्क प्रतिनिधित्व होता है जो इस व्यवहार की अनुमति देगा।

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

अधिकांश संपादकों को मौजूदा संस्करण को अछूता छोड़ने और अपने परिवर्तनों के साथ एक नया बनाने (पुराने संस्करणों को बनाए रखने) के लिए कॉन्फ़िगर किया जा सकता है।

"पीसी" क्या करता है के बारे में आपके प्रश्न के भाग के रूप में, कुछ ऑपरेटिंग सिस्टम एक फ़ाइल के हर संस्करण को याद रखेंगे और हमेशा एक नया निर्माण करेंगे। इन दिनों यह बहुत दुर्लभ है, लेकिन मुझे याद है कि पुराने "मिनी कम्प्यूटर्स" (जिसे अब हम मेनफ्रेम कहेंगे) जहां हर फाइल के अंत में "File.text.1" जैसा संस्करण होता था और यह हर बार संस्करण में जुड़ जाता था। इसे संपादित किया। इस तरह का व्यवहार टेप ड्राइव या सीडी रोम की तरह कुछ पर लागू होगा जहां पुराने संस्करण को ओवरराइट करना पूरी तरह से अव्यावहारिक था।


1

2 असंभव नहीं है, लेकिन यह विभिन्न कारणों से बेवकूफ है।

एक अच्छी तरह से लिखा पाठ फ़ाइल संपादक होगा:

  1. एक अलग नाम और नई सामग्री के साथ एक फ़ाइल लिखें। यदि मूल था myfile.txt, तो नया हो सकता हैmyfile.txt.new
  2. बशर्ते 1. सफल, मूल को एक बैकअप फ़ाइल में बदल दें, कहते हैं myfile.txt~
  3. मूल नाम से नई फ़ाइल का नाम बदलें myfile.txt
  4. यदि सब कुछ सफल हो गया है, तो बैकअप फ़ाइल को हटा दें। कई संपादक इसे वैसे भी छोड़ देते हैं, इसलिए उपयोगकर्ता ठीक हो सकता है यदि वह जल्द ही काम करता है कि उसने संपादक के साथ क्या किया / वह वह नहीं था जो वह करना चाहता था।

यदि कंप्यूटर उपरोक्त के दौरान डिस्क पर अंतरिक्ष से बाहर निकलता है या बाहर चला जाता है, तो ऐसी स्थिति नहीं है जहां पुरानी और नई दोनों फाइलें खो जाती हैं या केवल आंशिक रूप से सहेजी जाती हैं।


पिछली आधी सदी के गैर-आईबीएम / गैर-माइक्रोसॉफ्ट ऑपरेटिंग सिस्टम के लिए बहुत सारे टेक्स्ट एडिटर्स का ट्रंकट-इन-इन-एंड-एंड-रीराइट व्यवहार "बेवकूफ" नहीं है।
JdeBP

1

संक्षिप्त जवाब

अत्यधिक आपके संपादक, अंतर्निहित सॉफ़्टवेयर / ड्राइवरों, भंडारण पर निर्भर करता है।


व्यामोह का उत्तर

जब तक आप इसे स्थायी रूप से नहीं हटाते तब तक यह पुनर्प्राप्त करने योग्य हो सकता है।


लंबा जवाब

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

यह कुछ कारकों पर निर्भर करता है:

  1. संपादक : यदि संपादक सॉफ़्टवेयर उसी फ़ाइल के ब्लॉक को बदल देता है, तो उसे फिर से लिखा जा सकता है । और यह भी संपादक सेटिंग्स और फ़ाइल प्रकारों पर निर्भर हो सकता है। ध्यान दें कि शब्द हो सकता है इटैलिक बनाया गया था। जब संपादक फ़ाइल को फिर से लिखता है, तब भी यह अछूता रह सकता है (अगले अंक पढ़ें)।

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

  3. भंडारण :

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

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

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


कैसे सुनिश्चित करें कि डिलीट की गई फाइल वास्तव में स्टोरेज से डिलीट हो गई है?

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


1

एक व्यवहार जिसे अभी तक किसी ने भी उल्लेख नहीं किया है, वह एमएस विंडोज ऑपरेटिंग सिस्टम के कुछ संस्करणों का एक प्रासंगिक व्यवहार है, यह भी उपयोग में फाइल सिस्टम से संबंधित है।

व्यवहार इस तरह से काम करता है: जब आप किसी फ़ाइल का नाम बदलते हैं या हटाते हैं, यदि आप मूल फ़ाइल हटाए जाने (या नाम बदलने) के 15 सेकंड के भीतर एक ही नाम के साथ (नया) फ़ाइल बनाते हैं (पुन: बनाते हैं), तो निर्माण तिथि / टाइमस्टैम्प को मूल फ़ाइल से कॉपी किया जाता है। अनिवार्य रूप से, नई फ़ाइल पुरानी / मूल फ़ाइल बन जाती है।

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

जैसा कि मैंने कहा, यह एमएस विंडोज / फाइलसिस्टम के कुछ संस्करणों का व्यवहार है। मुझे नहीं पता कि विंडोज का कौन सा संस्करण है और यह किस फाइलसिस्टम पर शुरू हुआ है, और यदि यह अभी भी अधिक हाल के संस्करणों का व्यवहार है। अगर मुझे लगता है कि मुझे लगता है कि यह विंडोज एनटी और विंडोज एक्सपी पर पेश किया गया था और अभी भी विंडोज 10 का व्यवहार है, और (अभी भी एक अनुमान है) व्यवहार के लिए एक फैट 32 या एनटीएफएस (और शायद नया) फाइल सिस्टम की आवश्यकता है।


वास्तव में, यह मायने रखता है, क्योंकि NTFS हार्ड लिंक का समर्थन करता है और इन विधियों के बीच प्रसिद्ध मतभेदों में से एक बहु-लिंक्ड फ़ाइलों पर प्रभाव है। फाइलसिस्टम टनलिंग कम से कम विंडोज एनटी 5.0 के बाद से है।
JdeBP

@ जेडेबीपी - हां, हम सहमत हैं। इसलिए मैंने # 1) "लगभग" को "अंतिम फ़ाइल में, मूल फ़ाइल की तरह" (लगभग) हर तरह से दिखता है, और # 2) एक अलग स्थान पर निर्देशिका प्रविष्टि।
केविन फेगन

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