আরএম কমান্ড জারি হলে ফাইলগুলি কোথায় যাবে?


98

সম্প্রতি আমি দুর্ঘটনাক্রমে rmফাইলগুলির একটি সেট করেছিলাম এবং এটি আমার মনে হয়েছিল যে এই ফাইলগুলি ঠিক কোথায়?

এর অর্থ হ'ল কোনও জিইউআইয়ের সাথে কাজ করার সময় মুছে ফেলা ফাইলগুলি ট্র্যাশে যায়। এর সমতুল্য কি rmএবং কোনও rmআদেশ কমানোর উপায় আছে ?


3
এখানে একটি সম্ভাব্য সদৃশ। লিনাক্সে পূর্বাবস্থায় ফিরুন । তবে আমি সত্যিই নিশ্চিত নই যে ফাইলগুলি যেখানে যায় সেখান থেকে পূর্বে ফিরে যাওয়ার কোনও উপায় রয়েছে quite
xenoterracide

উত্তর:


120

কোথাও নেই, চলে গেছে, নিখোঁজ হয়েছে। ভাল, আরও নির্দিষ্টভাবে, ফাইলটি লিঙ্কমুক্ত হয় lin ডেটা এখনও সেখানে ডিস্কে বসে আছে, তবে এর লিঙ্কটি সরানো হয়েছে। এটি ডেটা পুনরুদ্ধার করা সম্ভব ছিল, কিন্তু আজকাল মেটাডেটা সাফ হয়ে গেছে এবং কিছুই উদ্ধারযোগ্য নয়।

এখানে কোনও ট্র্যাশ ক্যান নেই rm, থাকাও উচিত। আপনার যদি ট্র্যাশ ক্যানের প্রয়োজন হয় তবে আপনার একটি উচ্চ-স্তরের ইন্টারফেস ব্যবহার করা উচিত। trash-cliউবুন্টুতে একটি কমান্ড-লাইন ইউটিলিটি রয়েছে তবে বেশিরভাগ সময় জিইউআই ফাইল ম্যানেজার যেমন নটিলাস বা ডলফিন ব্যবহার করা হয় স্ট্যান্ডার্ড ট্র্যাশ ক্যান সরবরাহ করতে। ট্র্যাশ নিজেই স্ট্যান্ডার্ড। ডলফিনে ট্র্যাশ করা ফাইলগুলি নটিলাস থেকে ট্র্যাশে প্রদর্শিত হবে।

ফাইলগুলি ~/.local/share/Trash/files/ট্র্যাশ করার সময় সাধারণত অন্য কোথাও স্থানান্তরিত হয় । rmইউনিক্স / লিনাক্স কমান্ড সাথে তুলনা করা যায় delডস / উইন্ডোস যা মুছে ফেলে এবং নেই উপর না রিসাইকেল বিন ফাইল সরানো। অন্য একটি জিনিস বুঝতে হবে যে আপনার হার্ড ডিস্ক ড্রাইভ থেকে আপনার ইউএসবি ডিস্কের মতো ফাইল সিস্টেমের মধ্যে একটি ফাইল সরিয়ে নেওয়া সত্যিই 1) ফাইল ডেটার একটি অনুলিপি যার পরে 2) মূল ফাইলটিকে সংযুক্ত করে। আপনি চাইবেন না যে আপনার ট্র্যাশগুলি এই অতিরিক্ত অনুলিপি দ্বারা পূর্ণ করা হোক।


4
সুস্পষ্ট ব্যাখ্যার জন্য অনেক ধন্যবাদ। আমি সিএলআই ব্যবহার করতে কিছু মনে করি না, ওয়াইল্ডকার্ডগুলি ব্যবহার করার সময় আমার আরও কিছুটা যত্নবান হওয়া দরকার। :)
Boehj

16
আমি libtrashআরএম এর আচরণ পরিবর্তন করার মতো কিছু ব্যবহার করে সতর্ক থাকব । প্রচুর স্ক্রিপ্ট rmফাইল পরিষ্কার করতে ব্যবহার করে এবং আপনি চান না যেগুলি ট্র্যাশে প্রদর্শিত হচ্ছে showing আমি প্যাকেজ trashথেকে একটি উত্সর্গীকৃত কমান্ড ব্যবহার করার পরামর্শ দিচ্ছি trash-cli। @pedro আমার যুক্ত করা উচিত যে আমি একবার আমার হোম ডিরেক্টরিতে একটি ফাইল তৈরি করেছিলাম। আমি দুর্ঘটনাক্রমে * উদ্ধৃত করেছিলাম যখন আমার এটি তৈরি করা উচিত নয় তাই আমি আরএম * দিয়ে এটিকে অপসারণের সিদ্ধান্ত নিয়েছি n আমি যখন বুঝতে পারি আমি কী করেছি তাড়াতাড়ি কমান্ডটি মেরে ফেলেছি তবে এটি ইতিমধ্যে আমার হোম ডিরেক্টরিতে থাকা বেশ কয়েকটি ফাইল মুছে ফেলেছে।
পেঙ্গুইন 359

4
শেলের মধ্যে আবর্জনার মতো কিছু পাওয়া খুব বিরল, তাই যদি আপনি এটি স্থানীয় মেশিনে যোগ করেন এবং এটিতে অভ্যস্ত হয়ে যান বা এমনকি আপনার প্রতিদিনের কাজে এটির উপর নির্ভর করেন। ইউনিক্সের অন্যান্য 99% এর কিছু ব্যবহার না করেই আপনি সমস্যায় পড়তে পারেন: s এক ছাড়া ...
জোহান

3
আমি মনে করি যে এখানে টোক-হোম বার্তাটি হ'ল আমাকে হুড়োহুড়ি করে ক্লিভিং বন্ধ করা এবং আরও ভাল মনোযোগ দেওয়া উচিত।
Boehj

2
যেমন কি @Johan বলেন একই যুক্তি ব্যবহার করে, তাহলে RedHat করতে ব্যবহৃত (এখনও আছে?) মত কমান্ড জন্য alias লেখা সেট cp, এবং mvযাও, cp -iএবং mv -iযখন রুট হিসাবে চলছে। এটি ডিফল্ট আচরণ পরিবর্তন করে যাতে বিদ্যমান ফাইলগুলি ওভাররাইট করার আগে সেই আদেশগুলি সর্বদা জিজ্ঞাসা করবে। কিছু সিসাডমিনস বিশেষভাবে এই এলিয়াসগুলি মুছে ফেলার জন্য সুপারিশ করেছিল যাতে আপনি সেই আচরণের প্রত্যাশা না করেন যা ডিফল্ট আচরণ অনুসরণ করে এমন কোনও সিস্টেমে মারাত্মক হতে পারে।
পেঙ্গুইন 359

11

, Ext3 / ext4 এই জন্য, আপনি মত সরঞ্জাম ব্যবহার করে ফাইলগুলি পুনরুদ্ধার করার চেষ্টা করতে পারেন extundelete বা ext3grep , অথবা এমনকি যেতে তালগোল পাকানো নিম্নস্তরের কাঠামোর সঙ্গে ম্যানুয়ালি (না হৃদয়ের ভীরু জন্য); অনেক ফাইল সিস্টেমের জন্য, আপনি নির্দিষ্ট নিদর্শন দ্বারা অ-এখনও-ওভার- রাইটেড ব্লকগুলি অনুসন্ধান করার চেষ্টা করতে পারেন (যেমন ম্যাজিক্রেস জেপিইজি শিরোনামগুলি সন্ধান করতে পারে অন্যান্য জিনিসগুলির মধ্যে)। নোট করুন যে এগুলি পেছনের বাম মেটাডেটা থেকে ফাইলগুলি পুনরুদ্ধার করার জন্য হিউরিস্টিক্স ব্যবহার করছে, তাই সম্পূর্ণ পুনরুদ্ধারের গ্যারান্টি দেওয়া হয় না - এটি শেষ-সুযোগের বেট বেশি (যেমন ফাইলগুলির কিছু চিহ্ন জার্নালে থাকা দরকার এবং ব্লকগুলি এখনও ওভাররাইট করা হয়নি)।

সুতরাং, সমস্ত অভিপ্রায় এবং উদ্দেশ্যে, মুছে ফেলা ফাইলগুলি rmচলে গেছে - আপনি এই সরঞ্জামগুলির প্রস্তাব হিসাবে যেমন নেক্রোমেন্সির চেষ্টা করতে পারেন তবে এটির উপর নির্ভর করবেন না: অন্য সমস্ত কিছু ব্যর্থ হলে চেষ্টা করার জন্য এই সরঞ্জামগুলি। আপনার সর্বশেষতম ব্যাকআপগুলি খনন করা ভাল (আপনি ব্যাকআপ তৈরি করছেন, ঠিক আছে? ওহ ভাল, লাইভ এবং শিখুন ...)।


2
উচ্চ-মূল্যবান পাঠ্যের ডেটার জন্য, আপনি সর্বদা মুছে ফেলা ফাইল থাকা ডিস্কের জন্য "কাঁচা ডিভাইস" দেখতে, এবং পরিচিত স্ট্রিংগুলি অনুসন্ধান করার জন্য যে কোনও শক্তিশালী সাধারণ-উদ্দেশ্য সরঞ্জাম (এমনকি ইমাকস বা পার্ল) ব্যবহার করতে পারেন; আমি মানুষের জন্য এইভাবে ওয়ার্ড ডকুমেন্টগুলি উদ্ধার করেছি; তারা চিহ্ন-আপটি হারাতে পারে তবে বেশিরভাগ পাঠ্য পুনরুদ্ধার করতে পারে। স্পষ্টতই এটি দুর্যোগ পুনরুদ্ধার, "পূর্বাবস্থায় ফেরা" নয়।
অ্যালেক্সিস

একটি যথাযথ 'ম্যানুয়ালি' লিঙ্ক: web.archive.org/web/20131221183925/http://…
sjas

8

এর প্রভাবগুলি পূর্বাবস্থায় ফেলার বিষয়ে rm:

প্রদত্ত যে বেশিরভাগ ফাইল সিস্টেমগুলি কেবল ডেটার রেফারেন্সটিকে সরিয়ে দেয় এবং ব্লককে নিখরচায় চিহ্নিত করে, আপনি সরাসরি ডিভাইস থেকে আপনার ডেটা পঠন সনাক্ত করতে চেষ্টা করতে পারেন। কিছুটা ভাগ্যের সাথে আপনার ফাইল (গুলি) যুক্ত ব্লকগুলিকে অন্য কোনও কিছুর জন্য দাবি করা হয়নি been

এটি ধরে নিয়েছে যে rootসিস্টেমে আপনার কাছে কিছু অনন্য আছে, এবং আমি অনুমান করছি যে একাধিক ফাইল সিস্টেম ব্লক (সম্ভবত 4 কে) বিস্তৃত হতে পারে এমন একসাথে পাইকিং করার চেষ্টা করা যেতে পারে যদি ফাইল সিস্টেমটি পরিচালনা না করে quite ফাইলগুলিকে সংযুক্ত ব্লকের মধ্যে রাখার জন্য।

ফাইল সিস্টেমটি চালু রয়েছে এমন ডিভাইসে স্ট্রিং চালিয়ে এবং grepএকটি বৃহত প্রসঙ্গে ( -C) প্রবন্ধের সাহায্যে এই ফাইলগুলি থেকে কিছু সন্ধান করে আমি বেশ কয়েকটি সাফল্য-পাঠ্য ফাইলের সামগ্রী সফলভাবে উদ্ধার করেছি । (এবং এই ঘটনার শীঘ্রই, সংস্থাটি ব্যাকআপগুলি বাস্তবায়নে কিছু সংস্থান ব্যয় করার সিদ্ধান্ত নিয়েছে)


এটি কিছুটা জটিল জটিল যেমন ইনডোরের ব্লক পয়েন্টারগুলিকে শূন্যের বাইরে বের করে3, তবে হ্যাঁ, ফাইলগুলি অনুসন্ধান করা সরাসরি কাজ করতে পারে - যদি তারা যথেষ্ট ছোট হয় বা একটি স্বতন্ত্র ব্লকে বরাদ্দ থাকে। এটিকে কখনও কখনও ফাইল খোদাই বলা হয় এবং এর মতো সরঞ্জাম রয়েছে magicrescueযা তাদের স্বতন্ত্র নিদর্শনগুলির দ্বারা চিত্র বা শোনার চেষ্টা করে।
পিসকভোর

6

আপনি যখনই rmকমান্ড ব্যবহার করে কোনও ফাইল মুছবেন তখন ফাইলের ডেটা কখনই মুছবে না। অন্য কথায় ডেটাযুক্ত ফাইল সিস্টেমে ব্লকগুলি এখনও রয়েছে।

যখন আপনি rmকমান্ডটি চালাবেন তখন যা ঘটে তা হ'ল সিস্টেমটি সেই ফাইলের অন্তর্গত ইনোডটিকে অব্যবহৃত হিসাবে চিহ্নিত করে এবং সেই ফাইলটির ডেটা ব্লকগুলি অব্যবহৃত হিসাবে চিহ্নিত করা হয় (তবে মুছে ফেলা হয় না)। তবে ext3কোনও ফাইল মুছে ফেলা হলে ইনোডের বেশিরভাগ ক্ষেত্রটি শূন্য করে।

অব্যবহৃত এই সাধারণ চিহ্নিতকরণটি গতির জন্য করা হয় ... অন্যথায় মুছে ফেলার জন্য আরও কিছুটা সময় লাগবে। এ কারণেই আপনি উল্লেখ করেছেন যে এমনকি বড় ফাইলগুলি মুছে ফেলাও দ্রুত হয় (যদি ডেটা ব্লকগুলি ওভাররাইট না করা হয় তবে আপনি ডেটা পুনরুদ্ধার করতে পারেন)।

আরও তথ্য: ইনোড স্ট্রাকচার , কীভাবে ফাইল মোছা কাজ করে


... যদি না ফাইলটি স্পষ্টভাবে চিহ্নিত করা হয় chattr +s("শ্যাড") বৈশিষ্ট্যের সাথে। এটি ফাইল সিস্টেমটিকে মুছে ফেলার শূন্যের সাথে এই ফাইলটিকে বিশেষ করে ওভাররাইট করতে বলে। কেবলমাত্র কিছু ফাইল সিস্টেমগুলি সেই বৈশিষ্ট্যটিকে সমর্থন করবে।
telcoM

3

ইউনিক্স-স্টাইলের ফাইল সিস্টেমগুলিতে (লিনাক্স সহ) ফাইলগুলি কোনও নির্দিষ্ট জায়গায় সত্যই "এ" থাকে না। পরিবর্তে, সিস্টেমটি হার্ডলিঙ্কগুলি ব্যবহার করে ডেটার একটি বৃহত পরিমাণে কী পরিমাণ তা টুকরো টুকরো করে। সুতরাং আপনি যখন কোনও ফাইল তৈরি করেন, আপনি এটির প্রথম হার্ডলিংকটিও তৈরি করেন: প্রকৃতপক্ষে এমন একটি যেখানে আপনি ফাইলটি "সংরক্ষণ" করেছেন at আপনি যদি আরও হার্ডলিঙ্কগুলি করেন তবে সিস্টেমটি যতদূর জানে, ফাইলটি একসাথে বেশ কয়েকটি স্থানে উপস্থিত থাকে।

আপনি যখন কোনও ফাইল "মুছুন" করেন, সাধারণত আপনি কেবলমাত্র আপনার নির্দিষ্ট স্থানে থাকা হার্ডলিঙ্কটি মুছবেন। এই কারণেই ফাইলগুলি মুছতে সিস্টেম কলকে ডাকা হয় unlink()। সিস্টেমটি ফাইলটি মুছবে না যতক্ষণ না এতে কোনও হার্ডলিঙ্ক থাকে না। কিন্তু একবার যখন শেষ হার্ডলিঙ্কটি ধ্বংস হয়ে যায়, তেমনি ডেটাও হয়।

সুতরাং, আপনি মুছে ফেলা ফাইলগুলি কোথায় যান? যদি এখনও হার্ডলিঙ্কগুলি থাকে তবে সেগুলি ফাইলগুলি যেখানে আপনি মুছে না এমন হার্ডলিঙ্কগুলি যেখানেই রয়েছে are যদি কোনও হার্ডলিঙ্কগুলি না থাকে তবে ফাইলগুলি চলে যায়।


0

ফাইলটি সম্প্রতি সরিয়ে ফেলা হলে ~ / .snapshot এও দেখুন।


4
এটি কেবল তখনই কাজ করবে যদি আপনার কাছে এমন কোনও যাদু ফাইল সিস্টেম থাকে যা সেই বৈশিষ্ট্যটি সরবরাহ করে (নেট অ্যাপের মতো) বা আপনি যদি আরএম এর একটি বিশেষ সংস্করণ ব্যবহার করেন।
ম্যাটডেম
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.