কেন উবুন্টুতে একটি চলমান প্রোগ্রাম সরানো সম্ভব?

24

আমি কেবল উপলব্ধি করেছি যে আমি একটি চলমান সক্রিয় প্রোগ্রামকে একটি অন্য ডিরেক্টরিতে স্থানান্তর করতে সক্ষম। আমার অভিজ্ঞতায় যা ম্যাকও বা উইন্ডোজে সম্ভব ছিল না। উবুন্টুতে এটি কীভাবে কাজ করে?

সম্পাদনা: আমি ভেবেছিলাম এটি ম্যাকের পক্ষে সম্ভব নয় তবে মন্তব্যগুলি যাচাই করার ফলে সম্ভবত এটি সম্ভব। এটি কেবল উইন্ডোজেই সম্ভব নয় all সমস্ত উত্তরের জন্য ধন্যবাদ।

kernel files directory

— n0.ob
সূত্র

2

বেশ অনেকটা ক্রস-সাইট ডুপ: স্ট্যাকওভারফ্লো . com/ a/ 196910 / 1394393 ।

— jpmc26

1

আপনি rename(2)ওএস এক্স-তে চালানো এক্সিকিউটেবল পারবেন না ? কি হয়, EBUSYকিছু পাও নাকি? কেন এটি কাজ করে না? পুনর্নামকরণ (2) ম্যান পৃষ্ঠাটি ETXTBUSYসেই সিস্টেম কলের জন্য নথি দেয় না এবং কেবল EBUSYডিরেক্টরি নামগুলির পক্ষে সম্ভব হওয়ার বিষয়ে কথা বলে, তাই আমি জানতাম না একটি পসিক্স সিস্টেম এমনকি এক্সিকিউটেবলের নাম পরিবর্তন করতে পারে allow

— পিটার কর্ডেস

3

ম্যাকোস অ্যাপ্লিকেশনগুলি চালিত হওয়া অবস্থায়ও সরানো যেতে পারে, কেবল জঞ্জাল নয়। আমি অনুমান করি যে এর পরে কিছু অ্যাপ্লিকেশন ভ্রান্ত হতে পারে, যেমন, যদি তারা এনএসবান্ডেল এট আল এর মাধ্যমে এই জাতীয় URL তৈরির পরিবর্তে ভেরিয়েবল হিসাবে কোথাও কোনও বাইনারি বা বান্ডিলযুক্ত উত্সগুলিতে ফাইল URL গুলি সঞ্চয় করে। আমি সন্দেহ করি এটি ম্যাকোসের পসিক্স সম্মতি।

— কনস্টান্টিনো জারোহাস

1

এটি লিনাক্সের উদ্দেশ্য হিসাবে কাজ করে, আপনি কী করছেন তা আপনার জানা উচিত। : পি

— ইউজারডেপথ

2

আমি এটি সম্পর্কে চিন্তা করার অন্য উপায় অনুমান করি, এটি কেন সম্ভব হবে না ? উইন্ডোজ আপনাকে অনুমতি দেয় না কেবল, কারণ এটি প্রক্রিয়াগুলি কীভাবে কাজ করে বা কোনও কিছুর কারণে এটি মৌলিকভাবে সম্ভব নয়।

— টমাস

32

আমার ভেঙ্গে যাক।

আপনি যখন একটি এক্সিকিউটেবল চালনা করেন, সিস্টেম কলগুলির একটি ক্রম কার্যকর করা হয়, উল্লেখযোগ্যভাবে fork()এবং execve():

fork()কলিং প্রক্রিয়াটির একটি শিশু প্রক্রিয়া তৈরি করে, যা (বেশিরভাগ ক্ষেত্রে) পিতামাতার একটি সঠিক অনুলিপি, উভয় এখনও একই নির্বাহযোগ্য (কপি অন-লিখিত মেমরি পৃষ্ঠা ব্যবহার করে, তাই এটি দক্ষ) running এটি দু'বার ফিরে আসে: পিতামাতায়, এটি শিশু পিআইডি প্রদান করে। সন্তানের মধ্যে, এটি 0 ফিরে আসে ly সাধারণত, শিশু প্রক্রিয়া কলগুলি এখনই সম্পাদন করা হয়:
execve()আর্গুমেন্ট হিসাবে এক্সিকিউটেবলের জন্য একটি পুরো পথ নেয় এবং এক্সিকিউটেবলের সাথে কলিং প্রক্রিয়াটি প্রতিস্থাপন করে। এই সময়ে সদ্য নির্মিত প্রক্রিয়াটি তার নিজস্ব ভার্চুয়াল ঠিকানার স্থান অর্থাৎ ভার্চুয়াল মেমরি পায় এবং তার প্রবেশ বিন্দুতে (এক্সপ্লোরেশন প্ল্যাটফর্মটি এবিআইয়ের নতুন প্রক্রিয়াগুলির জন্য বিধি দ্বারা নির্দিষ্ট একটি রাজ্যে) কার্যকর হয় execution

এই মুহুর্তে, কার্নেলের ইএলএফ লোডার এক্সিকিউটেবলের টেক্সট এবং ডেটা বিভাগগুলিকে মেমরির মধ্যে ম্যাপ করেছে , যেমন এটি mmap()সিস্টেম কলটি ব্যবহার করেছে (যথাক্রমে ভাগ করে পঠনযোগ্য এবং ব্যক্তিগত পঠন-রাইটিং ম্যাপিংগুলি সহ)। বিএসএসকে এমএপ_অ্যানওয়াইমোয়াসের মতো ম্যাপ করা হয়েছে। (বিটিডাব্লু, সরলতার জন্য আমি এখানে গতিশীল সংযোগ উপেক্ষা করছি: ডায়ামিক লিঙ্কার open()এবং mmap()গুলি সমস্ত ডায়নামিক লাইব্রেরি মূল এক্সিকিউটেবলের এন্ট্রি পয়েন্টে ঝাঁপ দেওয়ার আগে।)

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

এক্সিকিউটেবল ফাইলটি নিম্ন স্তরের ইনোড দ্বারা চিহ্নিত করা হয়। ফাইলটি নির্বাহ করা শুরু হওয়ার পরে, কার্নেল ফাইলের নাম দ্বারা নয়, ফাইলের নাম দ্বারা নয়, ওপেন ফাইল বর্ণনাকারী বা ফাইল-ব্যাকযুক্ত মেমরি ম্যাপিংয়ের মতো ফাইল সামগ্রীটি অক্ষত রাখে। সুতরাং আপনি এক্সিকিউটেবলকে সহজেই ফাইল সিস্টেমের অন্য কোনও জায়গায় বা একটি ভিন্ন ফাইল সিস্টেমে সরিয়ে নিতে পারেন। পার্শ্ব নোট হিসাবে, প্রক্রিয়াটির বিভিন্ন স্ট্যাটাস পরীক্ষা করতে আপনি /proc/PID(প্রদত্ত প্রক্রিয়াটির প্রসেস আইডি) ডিরেক্টরিতে উঁকি দিতে পারেন । আপনি এমনকি এক্সিকিউটেবল ফাইলটি খুলতে পারেন এমনকি /proc/PID/exeএটি ডিস্ক থেকে লিঙ্কযুক্ত করা হয়েছে।

এখন চলন্ত খনন করা যাক:

আপনি যখন কোনও ফাইল ফাইলকে একই ফাইল সিস্টেমের মধ্যে সরিয়ে rename()আনেন তখন এক্সিকিউট হওয়া সিস্টেম কলটি হ'ল ফাইলটি অন্য নামে পুনরায় নামকরণ করে, ফাইলের ইনোড একই থাকে।

যেখানে দুটি ভিন্ন ফাইল সিস্টেমের মধ্যে দুটি জিনিস ঘটে:

নতুন অবস্থানে, প্রথম কপি ফাইল বিষয়বস্তু read()এবংwrite()
এর পরে, ফাইলটি উত্স ডিরেক্টরি থেকে আনলিংক করা হয়েছে unlink()এবং সম্ভবত ফাইলটি নতুন ফাইল সিস্টেমে একটি নতুন ইনোড পাবে।

rmপ্রকৃতপক্ষে unlink()ডিরেক্টরি ট্রি থেকে প্রদত্ত ফাইলটি সবেমাত্র করা হচ্ছে, সুতরাং ডিরেক্টরিতে লেখার অনুমতি থাকা আপনাকে সেই ডিরেক্টরি থেকে কোনও ফাইল সরিয়ে নেওয়ার পর্যাপ্ত অধিকার পাবে।

এখন মজা করার জন্য, কল করুন যখন আপনি দুটি ফাইলসাইটের মধ্যে ফাইলগুলি সরিয়ে রাখছেন এবং unlink()উত্স থেকে আপনার কাছে ফাইলের অনুমতি নেই ?

ঠিক আছে, ফাইলটি প্রথমে ( read(), write()) গন্তব্যে অনুলিপি করা unlink()হবে এবং তারপরে অপর্যাপ্ত অনুমতির কারণে ব্যর্থ হবে। সুতরাং, ফাইল উভয় ফাইল সিস্টেমে থাকবে !!

— heemayl
সূত্র

5

আপনার কিছুটা বিভ্রান্ত ভার্চুয়াল এবং শারীরিক স্মৃতি। প্রোগ্রামটি কীভাবে শারীরিক স্মৃতিতে লোড করা হয়েছে তার বিবরণটি সঠিক নয়। এক্সিকিউটিভ সিস্টেম কল মোটেও এক্সিকিউটেবলের বিভিন্ন বিভাগকে শারীরিক স্মৃতিতে অনুলিপি করে না তবে প্রক্রিয়াটি শুরু করার জন্য প্রয়োজনীয় একটিটি লোড করে। এরপরে, প্রয়োজনীয় পৃষ্ঠাগুলি চাহিদা অনুযায়ী লোড হয়, সম্ভবত দীর্ঘ সময় পরে। এক্সিকিউটেবল ফাইল বাইটগুলি প্রক্রিয়াটির ভার্চুয়াল মেমরির অংশ এবং এটি পড়তে পারে এবং সম্ভবত প্রক্রিয়াটির পুরো জীবনকালে আবারও পড়তে পারে।

— jlliagre

@ জেলিয়াগ্র্রে সম্পাদিত, আমি আশা করি এটি এখন পরিষ্কার হয়ে গেছে। ধন্যবাদ।

— হিমাইল

6

"প্রক্রিয়াটি আর ফাইল সিস্টেম ব্যবহার করছে না" বিবৃতিটি এখনও প্রশ্নবিদ্ধ।

— jlliagre

2

ফাইল সিস্টেমে প্রদত্ত ফাইলটি ফাইলের নাম দ্বারা সরাসরি সনাক্ত করা যায় না এমন প্রাথমিক ধারণাটি আরও পরিষ্কার হওয়া উচিত।

— থরবজর্ন রাভন অ্যান্ডারসন

2

এটি আপনার আপডেটে এখনও অপ্রত্যাশিত। mmapএবং unmapসিস্টেম কল লোড জন্য ব্যবহৃত হয় এবং চাহিদা পৃষ্ঠাগুলি আন, পৃষ্ঠা কার্নেল দ্বারা লোড করা হয় যখন অ্যাক্সেস তাদের পেজ ফল্ট উৎপন্ন, পৃষ্ঠা মেমরি থেকে unloaded যখন অপারেটিং সিস্টেম মতানুযায়ী র্যাম ভাল অন্য কিছু ব্যবহার করা হবে না। এই লোড / আনলোড অপারেশনে কোনও সিস্টেম কল জড়িত নেই।

— jlliagre

14

ঠিক আছে, এটা বেশ সোজা। আসুন / usr / স্থানীয় / বিন / whoopdeedoo নামে একটি নির্বাহী গ্রহণ করা যাক। এটি কেবল তথাকথিত ইনোড (ইউনিক্স ফাইল সিস্টেমে ফাইলগুলির মূল কাঠামো) এর একটি উল্লেখ reference এটি এমন ইনোড যা "ব্যবহারে" চিহ্নিত হয়েছে।

এখন আপনি যখন ফাইল / usr / স্থানীয় / whoopdeedoo মুছে ফেলেন বা সরান, কেবলমাত্র সরানো জিনিস (বা মুছা) হ'ল ইনোডের উল্লেখ। ইনোড নিজেই অপরিবর্তিত থাকে। মূলত এটি।

আমার এটি যাচাই করা উচিত, তবে আমি বিশ্বাস করি আপনি ম্যাক ওএস এক্স ফাইল সিস্টেমগুলিতেও এটি করতে পারেন।

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

আমি স্বীকার করি, আমি অত্যধিক সরল করেছি, তবে উইকিপিডিয়ায় "ইমপ্লিকেশনস" বিভাগটি পড়ি, যা আমার চেয়ে আরও ভাল কাজ করে।

— jawtheshark
সূত্র

1

ঠিক আছে যদি আপনি উইন্ডোজটিতে এক্সিকিউটেবল শুরু করার জন্য একটি শর্টকাট ব্যবহার করেন, আপনি শর্টকাটটিও মুছতে পারেন, আপনি যদি এটির মতো তুলনা করতে চান তবে? = 3

— রায়

2

না, এটি প্রতীকী লিঙ্ক মুছার মতো হবে। অন্য কোথাও কোথাও এটি বর্ণিত হয়েছে যে FAT ফাইল সিস্টেমগুলির সাথে লিগ্যাসি সমর্থনের কারণে আচরণটি হয়েছিল। এটি একটি সম্ভাব্য কারণ মত শোনাচ্ছে।

— jawtheshark

1

এটির সাথে ইনোডগুলির সাথে বিশেষভাবে করার কিছুই নেই । এনটিএফএস ফাইল স্থিতি ট্র্যাক করতে এমএফটি রেকর্ড ব্যবহার করে এবং FAT এর জন্য ডিরেক্টরি এন্ট্রি ব্যবহার করে, তবে লিনাক্স এখনও এই ফাইল সিস্টেমগুলির সাথে একইভাবে কাজ করে - ব্যবহারকারীর দৃষ্টিকোণ থেকে।

— রুসলান

13

অন্য সমস্ত উত্তর থেকে একটি জিনিস অনুপস্থিত মনে হচ্ছে তা হ'ল: একবার ফাইল খুললে এবং কোনও প্রোগ্রাম একটি ওপেন ফাইল বিবরণী ধরে রাখলে ফাইল ফাইল বিবরণী বন্ধ না হওয়া পর্যন্ত ফাইলটি সিস্টেম থেকে সরানো হবে না ।

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

তবুও যখন কার্নেল একটি ফাইল কার্যকর করে তখন এটি এক্সিকিউটেবল ফাইলের একটি রেফারেন্স রাখে এবং এটি আবার কার্যকর করার সময় এর কোনও পরিবর্তন রোধ করবে।

সুতরাং শেষ পর্যন্ত এমনকি যদি মনে হয় আপনি কোনও চলমান প্রোগ্রাম তৈরি করা ফাইলগুলি মুছে / মুভ করতে সক্ষম হয়েছেন তবে প্রোগ্রামটি শেষ না হওয়া পর্যন্ত এই ফাইলগুলির বিষয়বস্তু মেমরিতে রাখা হয়।

— Bakuriu
সূত্র

1

এটা সঠিক না. execve()কোনও এফডি ফিরিয়ে দেয় না, এটি প্রোগ্রামটি কেবল কার্যকর করে। সুতরাং উদাহরণস্বরূপ, যদি আপনি চালাতে tail -f /foo.logতাদের একটি এফডি (হয় /proc/PID/fd/<fd_num>) সঙ্গে যুক্ত tailজন্য foo.logকিন্তু এক্সিকিউটেবল নিজেই জন্য, না tail, না তার পিতা বা মাতা হিসাবে ভাল। এটি একক এক্সিকিউটেবলের জন্যও সত্য।

— হিমাইল

@ হাইমাইল আমি উল্লেখ করিনি execveতাই এটি কীভাবে প্রাসঙ্গিক তা আমি দেখতে পাই না। একবার কার্নেল কোনও ফাইল সম্পাদন করা শুরু করলে, ফাইলটি প্রতিস্থাপনের চেষ্টা করার পরে প্রোগ্রামটি পরিবর্তন করবে না কার্নেল পয়েন্ট মোট রেন্ডারিং লোড করতে চলেছে। চলমান অবস্থায় আপনি যদি এক্সিকিউটেবলকে "আপডেট" করতে চান execveতবে কার্নেলটি ফাইলটি পুনরায় পড়ার জন্য আপনি কোনও সময় কল করতে পারেন, তবে এটি কীভাবে গুরুত্বপূর্ণ তা আমি দেখতে পাই না। কথাটি হ'ল: "চালানো এক্সিকিউটেবল" মুছে ফেলা কার্যকর হওয়া বন্ধ না হওয়া অবধি কোনও ডেটা মুছে ফেলার চেষ্টা করে না।

— বাকুরিউ

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

— হিমাইল

2

ফাইলটির রেফারেন্স পেতে আপনার কোনও ফাইল হ্যান্ডেল লাগবে না - পৃষ্ঠাগুলি ম্যাপ করাও যথেষ্ট।

— সাইমন রিখর

1

ইউনিক্সের "ফাইল হ্যান্ডলগুলি" নেই। open()একটি ফাইল বর্ণনাকারী ফিরিয়ে দেয় , যা হিমাইলের সাথে এখানে কথা বলছে execve()। হ্যাঁ, একটি চলমান প্রক্রিয়াটির এক্সিকিউটেবলের জন্য একটি রেফারেন্স থাকে তবে এটি কোনও ফাইল বর্ণনাকারী নয়। সম্ভবত এটি যদি munmap()তার কার্যকরকরণের সমস্ত ম্যাপিংগুলি সম্পাদন করে, তবুও এটির একটি রেফারেন্স থাকবে (/ proc / স্ব / প্রতিবেদনে প্রতিফলিত) যা ইনোডকে মুক্ত হতে বাধা দেয়। (এটি যদি কোনও লাইব্রেরি ফাংশন থেকে কখনই ফিরে আসে না তবে এটি ক্র্যাশ না করেই সম্ভব হবে)) বিটিডাব্লু, কোনও ব্যবহারযোগ্য এক্সিকিউটেবলকে কাটা বা সংশোধন করা আপনাকে দিতে পারে ETXTBUSY, তবে কাজ করতে পারে।

— পিটার কর্ডেস

7

একটি লিনাক্স ফাইল সিস্টেমে আপনি যখন কোনও ফাইল সরান, এতক্ষণ এটি ফাইল সিস্টেমের সীমানা অতিক্রম না করে (পড়ুন: একই ডিস্ক / পার্টিশনে থাকে) আপনি যে সমস্ত পরিবর্তন করছেন ..তা নতুন স্থানের (প্যারেন্ট ডিরেক্টরি) এর ইনোড is । প্রকৃত ডেটা ডিস্কে মোটেও সরেনি, কেবল পয়েন্টার যাতে ফাইল সিস্টেমটি কোথায় এটি সন্ধান করতে পারে তা জানে।

এই কারণেই সরানো অপারেশনগুলি এত তাড়াতাড়ি এবং সম্ভবত কোনও চলমান প্রোগ্রাম সরানোর কোনও সমস্যা নেই কারণ আপনি প্রকৃতপক্ষে প্রোগ্রামটি নিজেই সরিয়ে নিচ্ছেন না।

— I_GNU_it_all_along
সূত্র

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

— jlliagre

6

এটি সম্ভব কারণ কোনও প্রোগ্রাম সরিয়ে নিয়ে যাওয়া শুরু হওয়া চলমান প্রক্রিয়াগুলিকে প্রভাবিত করে না।

একটি প্রোগ্রাম চালু হয়ে গেলে, তার অন-ডিস্ক বিটগুলি ওভাররাইট করা থেকে রক্ষা করা হয় তবে ফাইলটির নাম পরিবর্তন করে রক্ষা করার প্রয়োজন নেই, একই ফাইল সিস্টেমের ভিন্ন স্থানে সরানো হয়েছিল, যা ফাইলটির নাম পরিবর্তনের সমতুল্য, বা সরানো হয়েছে অন্য কোনও ফাইল সিস্টেমে ফাইলটি অন্যত্র অনুলিপি করার সমতুল্য হয় তারপরে এটি মুছে ফেলুন।

ব্যবহৃত একটি ফাইল অপসারণ করা হয়, কারণ কোনও প্রক্রিয়াটিতে একটি ফাইল বর্ণনাকারী খোলা থাকে, বা কোনও প্রক্রিয়া এটি চালিত করার কারণে ফাইল ডেটা সরিয়ে দেয় না, যা ফাইল ইনোড দ্বারা রেফারেন্সযুক্ত থাকে তবে কেবল ডিরেক্টরি এন্ট্রি সরিয়ে দেয়, যেমন একটি পথ যা থেকে ইনোডে পৌঁছানো যায়।

নোট করুন যে একটি প্রোগ্রাম চালু করা সমস্ত কিছু একবারে (শারীরিক) মেমোরিতে লোড করে না। বিপরীতে, প্রক্রিয়াটি শুরু করার জন্য প্রয়োজনীয় কঠোর ন্যূনতমটি লোড করা হয়। তারপরে, প্রক্রিয়াটির পুরো জীবনকালে প্রয়োজনীয় পৃষ্ঠাগুলি চাহিদা পূরণ করা হয়। একে বলা হয় ডিমান্ড পেজিং। যদি র‌্যামের ঘাটতি থাকে তবে ওএস এই পৃষ্ঠাগুলি ধারণ করে র‌্যাম প্রকাশ করতে মুক্ত so সুতরাং কোনও প্রক্রিয়া সম্পাদনযোগ্য ইনোড থেকে একই পৃষ্ঠায় একাধিকবার লোড করা ভাল।

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

— jlliagre
সূত্র

1

আমি বিশ্বাস করি উইন্ডোজের নতুন সংস্করণগুলি পুনরায় চালু না করে ব্যবহারে বাইনারিগুলি প্রতিস্থাপন করতে পারে।

— থরবজর্ন রাভন অ্যান্ডারসন

@

— থরবজরন রাভানএন্ডারসেন

1

পছন্দ করেছেন কাছ থেকে দেখুন। যদিও বাইনারিগুলি আপডেট করা যায় তবে কার্নেলটি (আমার জ্ঞানের কাছে) পারবেন না এবং নতুন সংস্করণে পুনরায় বুট করা দরকার। এটি বেশিরভাগ অপারেটিং সিস্টেম কার্নেলের জন্য বৈধ। আমি চেয়ে আরও স্মার্ট মানুষ লিনাক্সের জন্য kpatch লিখেছি যা একটি Linux কার্নেল যখন চলমান প্যাচ করতে পারেন - দেখুন en.wikipedia.org/wiki/Kpatch

— Thorbjørn Ravn অ্যান্ডারসনকে

@

— থরবজরন রাভানআ্যান্ডারসেন

@ ব্রাইয়াম হ্যাঁ - আমিও তাই করেছি Please দয়া করে আরও ঘনিষ্ঠভাবে দেখুন।

— থরবজর্ন রাভন অ্যান্ডারসন

4

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

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

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

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

— user584745
সূত্র