ইউনিক্স / লিনাক্সে ডিরেক্টরিগুলির হার্ড লিঙ্কগুলি কেন অনুমোদিত নয়?


130

আমি পাঠ্য বইয়ে পড়েছি যে ইউনিক্স / লিনাক্স ডিরেক্টরিগুলিতে হার্ড লিঙ্কগুলিকে অনুমতি দেয় না তবে নরম লিঙ্কগুলিকে অনুমতি দেয়। এটি কি কারণ, যখন আমাদের চক্র থাকে এবং আমরা যদি হার্ড লিঙ্কগুলি তৈরি করি এবং কিছুক্ষণ পরে আমরা মূল ফাইলটি মুছি, এটি কিছু আবর্জনার মানকে নির্দেশ করবে?

হার্ড লিঙ্কগুলিকে অনুমতি না দেওয়ার পিছনে যদি চক্রই একমাত্র কারণ ছিল, তবে কেন ডিরেক্টরিগুলির নরম লিঙ্কগুলি অনুমোদিত?


2
কোথায় ..নির্দেশ করা উচিত ? বিশেষত এই ডিরেক্টরিটির হার্ড লিঙ্কটি সরিয়ে দেওয়ার পরে ডিরেক্টরিতে নির্দেশিত ডিরেক্টরিতে ..? এটি কোথাও নির্দেশ করা প্রয়োজন।
থরবজর্ন রাভন অ্যান্ডারসন

2
..কোনও ড্রাইভে শারীরিকভাবে অস্তিত্বের প্রয়োজন নেই। যাইহোক যাইহোক, বর্তমান ওয়ার্কিং ডিরেক্টরিটি ট্র্যাক করা অপারেটিং সিস্টেমের কাজ, সুতরাং প্রতিটি প্রসেসের সিডাব্লুডির সাথে যুক্ত আইওডগুলির তালিকা রাখাও অপেক্ষাকৃত সহজ হওয়া উচিত এবং যখন এটি ব্যবহারের বিষয়টি দেখেন তখন তা উল্লেখ করুন ..। অবশ্যই, এর অর্থ হ'ল সিমলিংকগুলি সেই বিষয়টি মাথায় রেখে তৈরি করা দরকার, তবে আপনাকে ইতিমধ্যে সতর্কতা অবলম্বন করতে হবে যে সিমলিংকগুলি না ভাঙবে, এবং আমি মনে করি না যে অতিরিক্ত নিয়ম এগুলি অকেজো করে দেবে।
পার্থিয়ান শট

আমি এই ব্যাখ্যা পছন্দ । সংক্ষিপ্ত এবং পড়া এবং / অথবা স্কিম সহজে।
ট্রেভর বয়েড স্মিথ 14

উত্তর:


143

এটি কেবল একটি খারাপ ধারণা, কারণ কোনও হার্ড লিঙ্ক এবং একটি মূল নামের মধ্যে পার্থক্য জানানোর উপায় নেই।

ডিরেক্টরিগুলিতে কঠোর লিঙ্কগুলি মঞ্জুরি দেওয়ার ফলে ফাইল সিস্টেমের নির্দেশিত অ্যাসাইক্লিক গ্রাফ কাঠামোটি ভেঙে যায়, সম্ভবত ডিরেক্টরি লুপ তৈরি হবে এবং ডিরেক্টরি সাবট্রিগুলি ঝুঁকবে, যা fsckঅন্য কোনও ফাইল ট্রি ওয়াকারদের ত্রুটির ঝুঁকিতে ফেলেছে।

প্রথমে এটি বোঝার জন্য আসুন ইনোডগুলি নিয়ে কথা বলি। ফাইল সিস্টেমে ডেটা ডিস্কের ব্লকগুলিতে রাখা হয় এবং সেগুলি ব্লকগুলি একটি ইনোড দ্বারা একসাথে সংগ্রহ করা হয়। আপনি ইনোডটিকে ফাইল হিসাবে ভাবতে পারেন। যদিও আইওনডের ফাইলের নাম নেই। লিঙ্কগুলি এখানে।

একটি লিঙ্ক একটি ইনোডের কেবলমাত্র পয়েন্টার। ডিরেক্টরি হ'ল একটি ইনোড যা লিঙ্কগুলি ধারণ করে। ডিরেক্টরিতে প্রতিটি ফাইলের নাম একটি ইনোডের লিঙ্ক। ইউনিক্সে একটি ফাইল খোলার ফলে একটি লিঙ্ক তৈরি হয় তবে এটি ভিন্ন ধরণের লিঙ্ক (এটি নামযুক্ত লিঙ্ক নয়)।

একটি হার্ড লিঙ্কটি কেবলমাত্র একটি অতিরিক্ত ডিরেক্টরি প্রবেশিকা যা সেই ইনোডকে নির্দেশ করে। যখন আপনি ls -l, অনুমতিগুলির পরে নম্বরটি লিঙ্কযুক্ত গণনা। বেশিরভাগ নিয়মিত ফাইলগুলির একটি লিঙ্ক থাকবে। কোনও ফাইলে একটি নতুন হার্ড লিঙ্ক তৈরি করা উভয় ফাইলের নাম একই ইনোডকে নির্দেশ করবে। বিঃদ্রঃ:

% ls -l test
ls: test: No such file or directory
% touch test
% ls -l test
-rw-r--r--  1 danny  staff  0 Oct 13 17:58 test
% ln test test2
% ls -l test*
-rw-r--r--  2 danny  staff  0 Oct 13 17:58 test
-rw-r--r--  2 danny  staff  0 Oct 13 17:58 test2
% touch test3
% ls -l test*
-rw-r--r--  2 danny  staff  0 Oct 13 17:58 test
-rw-r--r--  2 danny  staff  0 Oct 13 17:58 test2
-rw-r--r--  1 danny  staff  0 Oct 13 17:59 test3
            ^
            ^ this is the link count

এখন, আপনি পরিষ্কার দেখতে পাচ্ছেন যে হার্ড লিঙ্কের মতো কোনও জিনিস নেই। একটি হার্ড লিঙ্ক নিয়মিত নামের মতো। উপরের উদাহরণে, testবা test2, মূল ফাইলটি কোনটি এবং হার্ড লিঙ্কটি কোনটি? শেষ পর্যন্ত, আপনি সত্যিই বলতে পারবেন না (এমনকি টাইমস্ট্যাম্পগুলি দিয়েও) কারণ উভয় নাম একই বিষয়বস্তু, একই ইনোডকে নির্দেশ করে:

% ls -li test*  
14445750 -rw-r--r--  2 danny  staff  0 Oct 13 17:58 test
14445750 -rw-r--r--  2 danny  staff  0 Oct 13 17:58 test2
14445892 -rw-r--r--  1 danny  staff  0 Oct 13 17:59 test3

-iপতাকা lsআপনি লাইন প্রারম্ভে inode সংখ্যার দেখায়। কীভাবে testএবং test2একই ইনোড নম্বর রয়েছে তা নোট করুন তবে test3এর একটি আলাদা নম্বর রয়েছে।

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

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

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

তাহলে কেন duসহজ লিঙ্কগুলি সহজেই এবং প্রতীকগুলি ব্যবহার করতে পারে? আমরা উপরে দেখতে সক্ষম হয়েছি যে হার্ড লিঙ্কগুলি সাধারণ ডিরেক্টরি এন্ট্রি থেকে পৃথক হয়। সিমলিংকগুলি তবে বিশেষ, সনাক্তযোগ্য এবং এড়াতে সক্ষম!  duলক্ষ করুন যে সিমিলিংকটি একটি সিমিলিংক, এবং এটিকে পুরোপুরি এড়িয়ে যায়!

% ls -l 
total 4
drwxr-xr-x  3 danny  staff  102 Oct 13 18:14 test1/
lrwxr-xr-x  1 danny  staff    5 Oct 13 18:13 test2@ -> test1
% du -ah
242M    ./test1/bigfile
242M    ./test1
4.0K    ./test2
242M    .

7
Allowing hard links to directories would break the directed acyclic graph structure of the filesystem। আপনি কি দয়া করে হার্ড লিঙ্কগুলি ব্যবহার করে চক্রের সমস্যা সম্পর্কে আরও ব্যাখ্যা করতে পারেন?
সিমলিংকের

33
তারা লিঙ্ক () সিস্টেম কলের সাথে চক্র সনাক্তকরণ যুক্ত করে ম্যাক্সে এটিকে অনুমতি দিয়েছে বলে মনে হয় এবং এটি যদি চক্র তৈরি করে তবে আপনাকে ডিরেক্টরি হার্ড লিঙ্ক তৈরি করার অনুমতি দিতে অস্বীকার করেছেন। একটি যুক্তিসঙ্গত সমাধান বলে মনে হচ্ছে।
psusi

10
@psusi mkdir -pa / b; nocheckln ca; এমভি সিএ / বি; - nocheckln একটি তাত্ত্বিক ln আছে যা ডিরেক্টরি আরোগুলি পরীক্ষা করে না, এবং কেবলমাত্র লিঙ্কে চলে যায়, এবং কোনও চক্র তৈরি না হওয়ায় আমরা 'সি' তৈরিতে সকলেই ভাল। তারপরে আমরা 'সি' কে 'এ / বি' তে স্থানান্তরিত করি এবং একটি চক্র </ b / c -> a / - থেকে তৈরি করা হয় লিঙ্কে পরীক্ষা করা () যথেষ্ট ভাল না
ড্যানি দুলাই

3
চক্রগুলি খুব খারাপ। উইন্ডোজের "জংশনগুলি" নিয়ে এই সমস্যা রয়েছে যা হার্ড লিঙ্ক ডিরেক্টরি। যদি আপনি দুর্ঘটনাক্রমে আপনার সম্পূর্ণ প্রোফাইলটিতে অনুমতিগুলি প্রয়োগ করেন তবে এটি এমন এক জংশনের সন্ধান করে যা একটি অসীম চক্র তৈরি করে। ডিরেক্টরিগুলির মাধ্যমে পুনরাবৃত্তি হওয়া পর্যন্ত পাথ দৈর্ঘ্যের সীমাবদ্ধতা বন্ধ না হওয়া পর্যন্ত পুনরাবৃত্তি হয়।
doug65536

4
: @WhiteWinterWolf, এই লিঙ্কটি অনুযায়ী, তারা বিশেষভাবে সমর্থন জন্য টাইম মেশিন জন্য যোগ, কিন্তু শুধুমাত্র রুট এটা করতে অনুমতি দেওয়া হয় superuser.com/questions/360926/...
psusi

14

মাউন্ট পয়েন্ট ব্যতিক্রম হলে প্রতিটি ডিরেক্টরির এক এবং একমাত্র পিতা বা মাতা আছে: ..

করার এক উপায় pwdহ'ল ডিভাইসটি পরীক্ষা করা: 'এর জন্য ইনোড'। এবং '..'. যদি সেগুলি একই হয় তবে আপনি ফাইল সিস্টেমের মূলটিতে পৌঁছে গেছেন। অন্যথায়, পিতামাতার মধ্যে বর্তমান ডিরেক্টরিটির নামটি সন্ধান করুন, স্ট্যাকের উপর চাপ দিন এবং '../' তুলনা শুরু করুন। '../ ..' দিয়ে, তারপরে '../../।' '../../ ..' ... ইত্যাদি দিয়ে একবার আপনি যখন রুটটিকে আঘাত করলেন, তখন স্ট্যাক থেকে নামগুলি মুছতে এবং মুদ্রণ শুরু করুন। এই অ্যালগরিদম এই সত্যের উপর নির্ভর করে যে প্রতিটি ডিরেক্টরিতে একটি এবং একমাত্র পিতা-মাতা থাকে।

ডিরেক্টরিতে যদি হার্ড লিঙ্কগুলির অনুমতি দেওয়া হয়, তবে একাধিক পিতামাতার মধ্যে কোনটি ..নির্দেশ করা উচিত ? ডিরেক্টরিতে হার্ডলিঙ্কগুলি অনুমোদিত না হওয়ার কারণ এটি একটি বাধ্যতামূলক কারণ।

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


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

13

হার্ড লিঙ্কিং ডিরেক্টরিগুলি অনুকরণ করতে আপনি বাইন্ড মাউন্ট ব্যবহার করতে পারেন

sudo mount --bind /some/existing_real_contents /else/dummy_but_existing_directory
sudo umount /else/dummy_but_existing_directory

7

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

"আমরা যখন পরীক্ষা করতে পারি তার একটি উপায় হ'ল আমরা যখন কোনও ডিরেক্টরিগুলির বিষয়বস্তু তালিকাভুক্ত করি তখন আমরা দুটি বিশেষ ডিরেক্টরি পাই"। এবং "..". আমরা জানি যে "." একই ডিরেক্টরিতে নির্দেশ করে এবং ".." পিতামাতার ডিরেক্টরিতে নির্দেশ করে।

সুতরাং একটি ডিরেক্টরি ট্রি তৈরি করা যাক যেখানে "a" হল সেই প্যারেন্ট ডিরেক্টরি যা তার সন্তানের মতো ডিরেক্টরি "বি" রয়েছে।

 a
 `-- b

ডিরেক্টরি "এ" এর ইনোডটি নোট করুন। এবং যখন আমরা ls -laডিরেক্টরি "এ" থেকে একটি করি তখন আমরা সেটি দেখতে পাই "। ডিরেক্টরি একই ইনোডেও নির্দেশ করে।

797358 drwxr-xr-x 3 mkannan mkannan 4096 Sep 17 19:13 a

এবং এখানে আমরা দেখতে পাই যে ডিরেক্টরি "এ" এর তিনটি শক্ত লিঙ্ক রয়েছে। কারণ ইনোড 797358 "এর নামে তিনটি হার্ডলিঙ্ক রয়েছে।" "একটি" ডিরেক্টরিতে এবং ".." ডিরেক্টরিতে "বি" এবং "এ" এর নাম সম্বলিত একটির ভিতরে নাম।

$ ls -ali a/
797358 drwxr-xr-x 3 mkannan mkannan 4096 Sep 17 19:13 .

$ ls -ali a/b/
797358 drwxr-xr-x 3 mkannan mkannan 4096 Sep 17 19:13 ..

সুতরাং আমরা এখানে বুঝতে পারি যে হার্ডলিঙ্কগুলি কেবলমাত্র তাদের পিতামাতা এবং শিশু ডিরেক্টরিগুলির সাথে সংযোগ করার জন্য ডিরেক্টরি রয়েছে। এবং সুতরাং শিশু ব্যতীত একটি ডিরেক্টরিতে কেবল 2 টি হার্ডলিঙ্ক থাকবে এবং সুতরাং ডিরেক্টরি "বি" এর মধ্যে কেবল দুটি হার্ডলিংক থাকবে।

ডিরেক্টরিকে অবাধে লিঙ্ক করা বন্ধ করার কারণ হ'ল অসীম রেফারেন্স লুপগুলি এড়ানো যা ফাইল সিস্টেমকে অতিক্রম করে এমন প্রোগ্রামগুলিকে বিভ্রান্ত করবে।

ফাইল সিস্টেম যেমন গাছ হিসাবে সংগঠিত হয় এবং গাছের চক্রাকার রেফারেন্স থাকতে পারে না তাই এড়ানো উচিত ছিল।


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

1
যেহেতু আমাদের কাছে ডিরেক্টরিগুলির জন্য শক্ত লিঙ্কগুলির অনুমতি দেওয়ার একটি সীমিত উপায় রয়েছে "" "এবং"। " আমরা একটি সীমাহীন লুপে পৌঁছতে পারব না এবং তাই এগুলি যেহেতু হবে না সেগুলি এড়াতে আমাদের কোনও বিশেষ পদ্ধতির প্রয়োজন হবে না
কান্নান মোহন

5

নিম্নলিখিতগুলির মধ্যে ডিরেক্টরিগুলির হার্ড লিঙ্কগুলি অস্বীকার করার আসল কারণ নয়; প্রতিটি সমস্যা সমাধান করা মোটামুটি সহজ:

  • গাছের কাঠামোর চক্রগুলি অসুবিধাগ্রস্থ হয়ে পড়ে
  • একাধিক পিতা-মাতা, তাই "আসল" কোনটি?
  • ফাইল সিস্টেম জঞ্জাল সংগ্রহ

আসল কারণ (যেমন @ Thorbjørn Ravn অ্যান্ডারসনকে দ্বারা hinted) আসে যখন আপনি মুছে ফেলতে থেকে ডিরেক্টরির দ্বারা প্রতি ইঙ্গিত একটি ডিরেক্টরি একাধিক বাবা আছে, ..:

..এখন কি নির্দেশ করা উচিত ?

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

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


3
এটি সহজেই সমাধান করা সহজ: একটি শিশু ডিরেক্টরিতে পিতামাতার একটি তালিকা রাখুন, আপনি যখন সন্তানের সাথে কোনও লিঙ্ক যুক্ত করবেন বা মুছবেন তখন আপনি আপডেট করবেন। যখন আপনি ক্যানোনিকাল পিতামাতাকে (সন্তানের লক্ষ্য ..) মুছে ফেলেন .., তালিকার অন্য পিতামাতার মধ্যে একটিতে নির্দেশ করতে আপডেট করুন ।
জেঠডে

2
আমি রাজী. রকেট সায়েন্স নয় সমাধান করার জন্য। তবে তবুও একটি কর্মক্ষমতা ওভারহেড, এবং এটি ফাইল সিস্টেম মেটা ডেটাতে কিছুটা অতিরিক্ত স্থান গ্রহণ করবে এবং জটিলতা যুক্ত করবে। এবং তাই ডিজাইনাররা সহজ, দ্রুত পদ্ধতির জন্য গেলেন - হার্ড ডিরেক্টরিগুলির লিঙ্কগুলিকে অনুমতি দেবেন না।
Lqueryvg

1
ডায়ারের সাইম লিঙ্কগুলি "নিষ্পত্তি করা শব্দার্থবিধি এবং আচরণগুলি লঙ্ঘন করে", তবুও তাদের অনুমতি রয়েছে। সিম লিঙ্কগুলি অনুসরণ করা হয় কিনা তা নিয়ন্ত্রণ করার জন্য কিছু কমান্ডের বিকল্পের প্রয়োজন (যেমন-সন্ধানে এবং সিপিতে এল)। যখন কোনও প্রোগ্রাম '..' অনুসরণ করে তখন আরও বিভ্রান্তি দেখা দেয়, তাই সিম লিঙ্কটি অনুসরণ করার পরে পিডাব্লুডি এবং / বিন / পিডাব্লুডি থেকে আউটপুটের পার্থক্য। কোনও "ইউনিক্স উত্তর" নেই; শুধু সিদ্ধান্ত সিদ্ধান্ত। আমার উত্তর হিসাবে আমি যেমন বলেছি এটি এই ".." কী হয় তার চারপাশে ঘোরে। দুর্ভাগ্যক্রমে, '..' এমন উত্তরে এমনকি উল্লেখ করা হয়নি যে প্রত্যেকে সকলেই ভীষণভাবে ভোট দিচ্ছেন।
Lqueryvg

বিটিডাব্লু, আমি বলছি না যে আমি ডায়ারের সাথে কঠোর লিঙ্কের পক্ষে আছি। একদমই না. আমি চাই না যে আমার দিনের কাজটি আগের চেয়ে বেশি শক্ত হোক।
Lqueryvg

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

3

ডিরেক্টরিগুলিতে হার্ডলিংক সৃষ্টিটি পুনর্বারযোগ্য হবে। ধরুন আমাদের আছে:

/dir1
├──this.txt
├──directory
│  └──subfiles
└──etc

আমি এটিকে হার্ডলিঙ্ক করি /dir2

সুতরাং /dir2এখন এই সমস্ত ফাইল এবং ডিরেক্টরি রয়েছে

আমি যদি আমার মন পরিবর্তন করি? আমি ঠিক করতে পারি না rmdir /dir2(কারণ এটি খালি নয়)

এবং যদি আমি পুনরাবৃত্তভাবে মুছে ফেলতে /dir2... এটি /dir1খুব মুছে ফেলা হবে!

আইএমএইচও এটি এড়ানোর যথেষ্ট পরিমাণে কারণ!

সম্পাদনা করুন:

মন্তব্যগুলি ডিরেক্টরিটি rmকরে এটি সরিয়ে দেওয়ার পরামর্শ দেয় । তবে rmএকটি খালি খালি ডিরেক্টরিতে ব্যর্থ হয় এবং ডিরেক্টরিটি হার্ডলিঙ্কযুক্ত কিনা তা এই আচরণটি অবশ্যই থেকেই যায়। সুতরাং আপনি কেবল rmএটি লিঙ্কমুক্ত করতে পারবেন না । এটির জন্য একটি নতুন যুক্তি প্রয়োজন rm, কেবল "ডিরেক্টরি ইনোডের একটি রেফারেন্স গণনা> 1 থাকলে, তবে কেবল ডিরেক্টরিটিকে লিঙ্কমুক্ত করুন" বলতে হবে।

যা, পরিবর্তে, কমপক্ষে অবাক হওয়ার আরেকটি নীতি ভঙ্গ করে: এর অর্থ হ'ল আমি স্রেফ তৈরি করা ডিরেক্টরি হার্ডলিঙ্ক অপসারণ একটি সাধারণ ফাইল হার্ডলিঙ্ক অপসারণের মতো নয় ...

আমি আমার বাক্যটিকে পুনরায় বলব: আরও বিকাশ না করেই হার্ডলিঙ্ক সৃষ্টিটি প্রত্যাবর্তনযোগ্য হবে (যেহেতু কোনও বর্তমান কমান্ড বর্তমান আচরণের সাথে সম্পর্কিত না হয়ে অপসারণ পরিচালনা করতে পারে না)

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


এটি কোনও সমস্যা হওয়া উচিত নয়। আপনার ক্ষেত্রে, আমরা যখন dir2 তে হার্ডলিঙ্ক তৈরি করি তখন আমাদের সমস্ত বিষয়বস্তুগুলিকে dir1 এ হার্ডলিংক তৈরি করতে হয় এবং তাই আমরা যদি ডির 2টির নাম পরিবর্তন করি বা মুছি তবে কেবল ইনডের অতিরিক্ত লিঙ্কটি মুছে ফেলা হবে। এবং এটি ডির 1 এবং এর সামগ্রীগুলিকে প্রভাবিত করবে না কারণ ইনোডের কমপক্ষে একটি লিঙ্ক (dir1) রয়েছে।
কান্নান মোহন

3
আপনার যুক্তি ভুল। আপনি কেবল এটি লিঙ্কমুক্ত করবেন, আরএম-আরএফ করবেন না। এবং যদি লিঙ্কের সংখ্যা 0 এ পৌঁছায় তবে সিস্টেমটি জানতে পারে এটি সমস্ত সামগ্রীও মুছে ফেলতে পারে।
LtWorf

rmএগুলি কম-বেশি যা-ই হোক না কেন নীচে (লিঙ্কমুক্ত)। দেখুন: unix.stackexchange.com/questions/151951/… এটি সত্যিই কোনও সমস্যা নয়, হার্ডলিঙ্কযুক্ত ফাইলগুলির চেয়ে বেশি এটি। লিঙ্কমুক্ত করা কেবলমাত্র নামযুক্ত রেফারেন্সকে সরিয়ে দেয় এবং লিঙ্কের গণনা হ্রাস করে। সত্য যে rmdirখালি নয় এমন ডিরেক্টরি মুছে যাবে না অপ্রাসঙ্গিক - এটা যে কি না করবে dir1 পারেন। হার্ডলিঙ্কগুলি তথ্যের অনুলিপি নয়, এগুলি একই প্রকৃত ফাইল, সুতরাং dir2 ফাইলটি আসলে "মুছে ফেলা" dir1 এর জন্য ডিরেক্টরি তালিকা মুছে ফেলবে। আপনার সর্বদা লিঙ্কমুক্ত করা প্রয়োজন।
ব্রাইকান

আপনি কেবল এটি একটি সাধারণ ফাইলের মতো লিঙ্কমুক্ত করতে পারবেন না, কারণ rmকোনও ডিরেক্টরিতে যদি এটি খালি না থাকে তবে এটি লিঙ্কমুক্ত করবেন না । সম্পাদনা দেখুন।
পিয়েরে-অলিভিয়ের ভারেস

1

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

বেল ল্যাবস ইউএনআইএক্স-এ কমপক্ষে ভি free এবং ভি in, বার্কলে বা তার পরে সম্পর্কে জানেন না। কোন পতাকা প্রয়োজন। আপনি লুপ করতে পারেন? হ্যাঁ, এটা করবেন না। এটি লুপ তৈরি করলে আপনি কী করছেন তা খুব স্পষ্ট। নেদারকে আপনার গলায় গিঁট বেঁধে অনুশীলন করা উচিত যখন আপনি বিমানের আকাশে ডাইভ করার জন্য আপনার টার্নটির জন্য অপেক্ষা করছেন যদি আপনি অন্য প্রান্তটি খুব সহজেই বাল্ক-মাথার একটি হুক থেকে ঝুলিয়ে রাখেন।

কি আমি এটা দিয়ে কি আশা প্রকাশ করেন আজ বাড়িতে কঠিন-লিঙ্ক lhome ছিল যাতে আমি / হোম / থাকুক বা না থাকুক প্রাপ্তিসাধ্য administ হতে পারে / হোম বাড়িতে বেশী automout আপ ঢাকা ছিল, যে জন্য automount / lhome করার জন্য একটি সিমবলিক লিঙ্ক নামে administ থাকার / administ। এটি আমাকে এমন একটি প্রশাসনিক অ্যাকাউন্ট রাখতে সক্ষম করে যা আমার প্রাথমিক হোম ফাইল সিস্টেমের অবস্থা নির্বিশেষে কাজ করে। এই IS লিনাক্সের জন্য একটি পরীক্ষা, কিন্তু আমি ইউসিবি ভিত্তিক SunOS জন্য এক সময় যে automounts ASCII স্ট্রিং পর্যায়ে সম্পন্ন করা হয় এ শিখেছি চিন্তা করুন। এগুলি যে কোনও স্বেচ্ছাসেবীর এফএসের উপরে একটি স্তর হিসাবে অন্যভাবে কীভাবে করা যায় তা দেখা শক্ত।

আমি অন্য কোথাও পড়েছি। এবং .. ডিরেক্টরিতে আর কোনও ফাইল নয়। আমি নিশ্চিত যে এই সমস্ত কিছুর জন্য উপযুক্ত কারণ রয়েছে এবং আমরা যা উপভোগ করি তার অনেক কিছুই (যেমন এনটিএফএস মাউন্ট করতে সক্ষম হওয়া) এই জাতীয় কারণেই সম্ভব, তবে ইউএনআইএক্সের কিছু কমনীয়তা বাস্তবায়নে ছিল। সাধারণতা এবং তাত্পর্যতার মতো সুবিধাগুলিই এই কমনীয়তা প্রদান করেছিল যা এটিকে এত দৃ rob় হতে এবং চার দশক ধরে সহ্য করতে সক্ষম করেছে। আমরা মার্জিত বাস্তবায়নগুলি আলগা করার সাথে সাথে এটি শেষ পর্যন্ত উইন্ডোজের মতো হয়ে যাবে (আমি আশা করি আমি ভুল হয়েছি!)। এরপরে কেউ একটি নতুন ওএস তৈরি করবে যা মার্জিত নীতিগুলির উপর ভিত্তি করে। আমার মনে হয় কিছু। সম্ভবত আমি ভুল, আমি বর্তমান প্রয়োগের সাথে (স্পষ্টতই) পরিচিত নই। এটা হয় আশ্চর্যজনক যদিও লিনাক্সের জন্য 30 বছরের পুরাতন বোঝাপড়া কতটা প্রযোজ্য ... বেশিরভাগ সময়!


আমি মনে করি, যদিও আমি ভুল হতে পারে, .এবং ..ফাইল-সিস্টেমের মধ্যে hardlinks, আধুনিক ফাইল-সিস্টেমের জন্য নয়। তবে ফাইল-সিস্টেম ড্রাইভার তাদের নকল করে। এটি এই ফাইল-সিস্টেম যা হার্ড লিঙ্কিং ডিরেক্টরিগুলি বন্ধ করে দেয়। পুরানো ফাইল-সিস্টেমগুলির জন্য এটি সম্ভব ছিল (তবে বিপজ্জনক)। কি আপনি চেষ্টা করছেন করার জন্য, তাকান mount --bind, দেখতে mount --make…এবং হয়ত পাত্রে।
ctrl-alt-delor

0

আমি যা সংগ্রহ করি তার থেকে মূল কারণটি হ'ল ডিরেক্টরিগুলির নাম পরিবর্তন করতে সক্ষম হবেন যা চালানো প্রোগ্রামগুলিতে গণ্ডগোল না করে যা তাদের কার্যকরী ডিরেক্টরিটি অন্য ফাইলগুলির রেফারেন্সে ব্যবহার করে। ধরুন আপনি চালানোর জন্য ওয়াইন ব্যবহার করছেন ~/.newwineprefix/drive_c/Program Files/Firefox/Firefox.exeএবং আপনি পুরো উপসর্গটি ~/.wineপরিবর্তে সরিয়ে নিতে চেয়েছিলেন । যদি কোনও অদ্ভুত কারণে ফায়ারফক্স অ্যাক্সেস drive_c/windowsকরে উল্লেখ করে ../../windows, পুনর্নামকরণের ফলে পংক্তিক ডিরেক্টরিটিকে একটি ইনডের পরিবর্তে পাঠ্য স্ট্রিং হিসাবে রাখে ~/.newwineprefiximplement..

একটি একক পিতামাতার ডিরেক্টরিতে ইনোড সংরক্ষণ করা প্রতিটি পাঠকে একটি পাঠ্য স্ট্রিং এবং ইনোডের একটি সিরিজ হিসাবে ট্র্যাক রাখার চেয়ে সহজ হতে হবে।

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

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

তবুও আরেকটি কারণ হ'ল প্যারেন্ট ডিরেক্টরিটির ইনোড সংরক্ষণ করা ফাইল-সিস্টেমের দুর্নীতি বা ক্ষতির ক্ষেত্রে অতিরিক্ত অতিরিক্ত বাড়াবাড়ি সরবরাহ করতে পারে। আপনি চেয়েছিলেন ..সব পিতা বা মাতা ডিরেক্টরি যে এই এক hardlink তালিকা, তাই একটি ভিন্ন, নির্বিচারে পিতা বা মাতা সহজে খুঁজে পাওয়া যাবে না যদি বর্তমান এক delinked হয় না শুধুমাত্র আপনি ধারণা যে কঠিন সংযোগগুলি সমান লঙ্ঘন করে তা দেখুন, কেমন পরিবর্তন করতে হবে ফাইল সিস্টেম সংরক্ষণ করে এবং ইনোড ব্যবহার করে। ডিরেক্টরিগুলি আইওডগুলির সিরিজ (প্রতিটি হার্ডলিঙ্কের অনন্য) হিসাবে পাথগুলি ট্রিট করা এগুলি এড়াতে পারে তবে ফাইল-সিস্টেমের ক্ষতি হওয়ার ক্ষেত্রে আপনি অতিরিক্ত কাজ করতে পারবেন না।

আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.