হার্ডলিঙ্কগুলির জন্য মামলাগুলি ব্যবহার করবেন? [বন্ধ]

Question

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

Comments

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

— রিচএফ

ঠিক আছে কোনও ফাইলের প্রথম হার্ডলিঙ্কটি খুব রঞ্জক কার্যকর।

— মনিকা মনিকার

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

— পিটার Cordes

পসিক্স ডিরেক্টরি সিনটেমিকসকে আলাদাভাবে ডিজাইন করতে হবে: প্যারেন্ট ডিরেক্টরিতে ..সর্বদা একই ইনোড থাকে .। ভীষণ পছন্দ findপরীক্ষা করতে পারবেন যে লিঙ্ক গোনা = 2 পাতার ডিরেক্টরি সনাক্ত করতে, এবং এড়ানোর statসাবডিরেক্টরি জন্য চেহারা দ্বারা readdir থেকে এন্ট্রি ing। তবে এটি কেবলমাত্র একটি গৌণ বৈশিষ্ট্য যা নন-ডিরেক্টরি ফাইলগুলির হার্ডলিঙ্কগুলির জন্য সমর্থন দ্বারা সক্ষম করা হয়েছে (নিয়মিত, সিমলিংক, ডিভাইস, সকেট এবং নামযুক্ত পাইপ)। (হ্যাঁ, সিমলিঙ্কগুলির নিজস্ব ইনোড রয়েছে এবং এটি হার্ডলিঙ্ক করা যেতে পারে))

— পিটার

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

— ম্যাথগুয়ে

Answer 1

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

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

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

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

যদি আসলটির নাম পরিবর্তন হয়, বা সরানো হয় (একক "ক্যাটালগ" ডিরেক্টরি পরিচালনা করতে খুব বড় হয়ে যায়, উদাহরণস্বরূপ) হার্ড-লিঙ্কগুলি বৈধ থাকে, নরম-লিঙ্কগুলি ভাঙা হয়। যদি "অনুলিপিগুলি" সরানো হয় এবং সফট-লিঙ্কগুলি আপেক্ষিক হয়, তবে সফট-লিঙ্কগুলি আবার ভেঙে যাবে, এবং হার্ড-লিঙ্কগুলি হবে না।

দ্রষ্টব্য: নরম-লিঙ্কগুলি জড়িত থাকাকালীন বিভিন্ন সরঞ্জাম কীভাবে ডিস্ক ব্যবহারের প্রতিবেদন করে তার মধ্যে অসঙ্গতি বলে মনে হচ্ছে। হার্ড-লিঙ্কগুলির সাথে তবে এটি সামঞ্জস্যপূর্ণ বলে মনে হচ্ছে। সুতরাং "ট্যাগ" সংকলনে সাজানো ক্যাটালগের 100 টি ফাইলের সাথে সহজেই 500 লিঙ্কযুক্ত "অনুলিপিগুলি" থাকতে পারে। (কোনও ফটোগ্রাফ সংগ্রহের জন্য, তারিখ, ফটোগ্রাফার এবং গড়ে 3 "বিষয়" ট্যাগগুলি বলুন)) উদাহরণস্বরূপ, ডলফিন হার্ড-লিঙ্কগুলির জন্য 100 টি ফাইল এবং নরম লিঙ্কগুলি ব্যবহার করা হলে 600 ফাইল হিসাবে রিপোর্ট করবে। মজার বিষয় হল, এটি যেভাবেই একই ডিস্ক-স্পেস ব্যবহারের প্রতিবেদন করে, তাই এটি সফট-লিঙ্কগুলির জন্য ছোট ফাইলগুলির একটি বৃহত সংগ্রহ এবং হার্ড-লিঙ্কগুলির জন্য বড় ফাইলগুলির একটি ছোট সংগ্রহের মতো দেখায়।

এই ধরণের ব্যবহারের ক্ষেত্রে একটি সতর্কতা হ'ল ফাইল-সিস্টেমে যেগুলি COW ব্যবহার করে, "আসল" পরিবর্তন করে হার্ড-লিঙ্কগুলি ভেঙে ফেলতে পারে, তবে নরম-লিঙ্কগুলি ভেঙে দেয় না। তবে, যদি উদ্দেশ্যটি সম্পাদনা, সংরক্ষণ এবং বাছাইয়ের পরে মাস্টার অনুলিপি হয়, তবে COW দৃশ্যে প্রবেশ করে না।

Comments

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

— ডারোবার্ট

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

— জিপসি স্পেলওয়েভার

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

— পিটার কর্ডস

Answer 2

আপনি উভয় ফাইলের অস্তিত্ব বাঁধতে চান না এমন ক্ষেত্রে লিঙ্কগুলি কার্যকর। এই বিবেচনা:

touch a
ln -s a b
rm a

এখন bঅকেজো। (এবং এই পদক্ষেপগুলি বেশ কিছুটা দূরে হতে পারে, বিভিন্ন ব্যক্তি দ্বারা করা ইত্যাদি etc.)

একটি শক্ত লিঙ্ক সহ,

touch a
ln a b
rm a

b এখনও উপস্থিত এবং সঠিক।

Comments

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

— অরেচো

@ ওচারো আমি মনে করি না যে আপনি আপনার ব্যাকআপ সিস্টেমের নিকটে কোথাও কঠোর লিঙ্কের আচরণ চান। github.com/bit-team/backintime/wiki/… ব্যাকটাইনটাই মূর্খভাবে ধরে নিয়েছে যে ফাইলগুলিতে সমস্ত পরিবর্তনগুলি স্থানে আপডেট হওয়ার পরিবর্তে একটি অপসারণ-চক্র দ্বারা হবে।

— হতাশ ড্যানিয়েল

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

— স্টিফেন কিট

এটি কোনও উত্তর নয় - বিশেষত এটি কোনও ব্যবহারের ক্ষেত্রে নয়। এটি কেবল কঠোর লিঙ্কগুলির আচরণের একটি প্রদর্শন।

— ব্যবহারকারী 394

@ থমাস প্যাড্রন-ম্যাকার্থি এটি একটি ভুল বোঝাবুঝি। বিআইটি বিভিন্ন স্ন্যাপশটের ভিতরে অভিন্ন ফাইলগুলি লিঙ্ক করতে শুধুমাত্র হার্ড-লিঙ্কগুলি ব্যবহার করে। তারা মূল ফাইলের সাথে লিঙ্কযুক্ত নয়! (আমি বিটি দেব)

— জার্মার

Answer 3

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

$ ls -li `which pgrep` `which pkill`
208330 -r-xr-xr-x  2 root  bin  19144 Jul 26  2016 /usr/bin/pgrep
208330 -r-xr-xr-x  2 root  bin  19144 Jul 26  2016 /usr/bin/pkill

উত্সে কোনটি শেষের মতো কোনও কিছুর মাধ্যমে সিদ্ধান্ত নেওয়া হয়

if (strcmp(__progname, "pgrep") == 0) {
    action = grepact;
    pgrep = 1;
} else {
    action = killact;

যদিও ওএস এবং ভাষা জড়িত তার উপর নির্ভর করে সঠিক বিশদটি ভিন্ন হয়।

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

#include <stdio.h>
#include <stdlib.h>
int main(int argc, char *argv[])
{
    printf("called as '%s'\n", *argv);
    exit(0);
}

এবং এর মাধ্যমে পরীক্ষিত:

$ cc -o myname myname.c 
$ ln -s myname alias
$ ./myname
called as './myname'
$ ./alias
called as './alias'
$ 

Comments

তবে কি সাধারণত সফটলিঙ্কগুলি দিয়ে পরিচালনা করা হয় না?

— ম্যাথু ক্লাইন

@ ম্যাথজিক্লাইন এটি আজ হতে পারে তবে এপিইউ-তে স্টিভেনস অনুসারে 4.2BSD (1983) এর আগে সিমলিংকগুলির অস্তিত্ব ছিল না।

— 28:38

@ থ্রিগ, প্রশ্নটি বিশেষত এমন ব্যবহারের জন্য জিজ্ঞাসা করে যা সিমলিংকগুলি দ্বারা সম্পাদন করা যায় না বা কমপক্ষে, সিমলিংকগুলি ব্যবহার করার চেয়ে পছন্দসই। আপনার উত্তরটি এইচএল এবং এসএল উভয় ক্ষেত্রেই প্রযোজ্য।

— মার্সেলো

ব্যস্তবক্স এটিকে সর্বাধিকতে নিয়ে যায়।

— সর্বাধিক Ried

Answer 4

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

সুবিধাদি:

• আমি rmবা mv"অনুলিপি" থাকা সত্ত্বেও আমি ফাইলটি এখনও পি 2 পি নেটওয়ার্কে ভাগ করি ।
• ফাইলটি আমার যেখানে প্রয়োজন সেখানেও রয়েছে; এই জাতীয় অবস্থানগুলির বেশিরভাগ ভাগ করা হয় না।
• আমি rmফাইলটি ভাগ করে নেওয়া বন্ধ করতে "আসল" করতে পারি; এই অপারেশনটি পছন্দসই জায়গায় "অনুলিপি" প্রভাবিত করে না।
• আমার ডিস্কস্পেসটি একবার ব্যবহার করা হয়েছে।

মূল বক্তব্য: যদি আমি আগে জানতাম যে কোন ফাইলটি rmপ্রথমে করব, আমি হয়ত সিমলিংকটি নিয়ে যেতে পারি। তবে আমি কখনই জানি না।

Answer 5

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

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

সুতরাং এখানে এমন কয়েকটি ব্যবহারের কেস রয়েছে যা হার্ডলিঙ্কগুলি উপস্থিত থাকে তবে সফটলিঙ্কগুলি এতে করে না :

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

2. আর একটি কারণ হ'ল স্টোরেজ স্পেসের অপচয়গুলি এড়ানো যা একই ফাইলের একাধিক অনুলিপি থাকা প্রয়োজন এবং chrootসিস্কালকে "মাস্টার" ফাইল সিস্টেমের রুটে ফাইলের উপসেট থেকে উপকার পেতে দেয় (প্রতীকী লিঙ্কগুলি কখনই বাইরে থেকে ফাইলগুলি রেফারেন্স করতে পারে না) chrootস্যান্ডবক্স, এমনকি যদি তারা আপেক্ষিক পাথ থাকে)।

3. হার্ডলিঙ্কগুলির অস্তিত্বের জন্য আরেকটি অত্যন্ত গুরুত্বপূর্ণ তবে খুব কমই উল্লেখ করা কারণ হ'ল ..সাব - ডিরেক্টরি। ..ডিরেক্টরি আসলে (অধিকাংশ মধ্যে UNIX বাস্তবায়নের FS) হয় পেরেন্ট ডাইরেক্টরি থেকে hardlinks hardlinks ছাড়াই এই একটি সম্পূর্ণ ভিন্ন ভাবে প্রয়োগ করা হয়েছে, যখন hardlinks অস্তিত্ব এই খুব সহজ প্রয়োগ করা সহজ করে তোলে।

Comments

পয়েন্ট 1 এর জন্য, uuids ফাইলগুলির 'ক্যানোনিকাল' নাম হিসাবে ব্যবহার করা এবং সমস্ত মানব-পঠনযোগ্য নামগুলি uuids এর সাথে প্রতীকী লিঙ্ক তৈরি করা একটি বিকল্প সমাধান।

— আর ..

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

— মার্সেলো

Answer 6

খুব সাধারণ, বাস্তব-বিশ্বের উদাহরণ যা হার্ডলিঙ্কগুলির প্রয়োজন:

git clone --reference <repository>

স্থানীয় গিট রেপো থেকে প্রায় শূন্যের অনুলিপি সহ এই ক্লোনগুলি। অবজেক্ট ফাইলগুলি অনুলিপি করার পরিবর্তে (গিট দ্বারা এটির "ডাটাবেস" ব্যবহার করার জন্য অপরিবর্তনীয় ফাইল) কপি করার পরিবর্তে এটি কেবল তাদের হার্ডলিঙ্ক করে।

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

---

একটা অ হার্ড-লিঙ্ক সংস্করণ: git clone --shared <repository>। এটি অবশ্য চঞ্চল এবং এতে একই সাথে আরও অনেক ক্যাভেট রয়েছে যেহেতু প্রত্যেকে একই ডিরেক্টরিতে কাজ করছে।

Answer 7

আমি সম্প্রতি ইউ-বুট ভিত্তিক সিস্টেমগুলির জন্য কিছুটা নিরাপদ আপডেট পদ্ধতির জন্য ব্যবহারের কেসটি পেয়েছি যেখানে uImageচিত্রটি বুট করার জন্য একটি নরম লিঙ্ক রয়েছে, ধারণাটি ছিল যে বিদ্যুৎ বিভ্রাটের কোনও সমস্যা হওয়া উচিত নয়, এটি কোন পর্যায়েই আসে না প্রক্রিয়াটি এটি ঘটে (ধরে নিলে ফাইল সিস্টেমটি চালিত হবে):

ln image.bin backup_image.bin
ln -sf backup_image.bin uImage

// replace image.bin

ln -sf image.bin uImage
rm backup_image.bin

হার্ডলিঙ্কগুলি ছাড়া এটি এত সহজ হবে না।

/ সম্পাদনা:

আমি এখন জানলাম যে মন্তব্যগুলি করার জন্য এটি আরও ভাল হবে:

ln image.bin backup_image.bin
ln -sf backup_image.bin uImageNew
mv uImageNew uImage || rm -rf uImage && mv uImageNew uImage

// replace image.bin

ln -sf image.bin uImageNew
mv uImageNew uImage || rm -rf uImage && mv uImageNew uImage
rm backup_image.bin

( rmএকটি অদ্ভুত অবস্থা থেকে আরও ভালভাবে পালাতে সক্ষম হওয়ার জন্য এটি এখানে রয়েছে, উদাহরণস্বরূপ যদি uImageএমন কোনও অপ্রত্যাশিত ঘটনা ঘটে যা mvব্যর্থ হয়ে যায় [তবে পূর্ববর্তী ln -sfসমাধানটি অগত্যা নয় ])

Comments

+1 কারণ এটি ধারণাগতভাবে খুব সুন্দর কারণ, তবে দুর্ভাগ্যক্রমে ln -sfএটি পারমাণবিক নয়। এটি পুরানো syMLink মুছে ফেলে এবং একটি নতুন করে তোলে। এই আপনি একটি অস্থায়ী নাম দিয়ে একটি নতুন সিমবলিক লিঙ্ক করতে হবে ঠিক করুন এবং rename(2)( mv) এটি আপনি প্রতিস্থাপন করতে চান তার নাম হবে।

— আর ..

@ আর .. আপনি ঠিক বলেছেন! 😲 stat("uImage", {st_mode=S_IFREG|0777, st_size=0, ...}) unlink("uImage"),symlink("backup_image.bin", "uImage")

— পিএইচকে

বিটিডাব্লু, আমার সংস্করণটির install.shসমস্যার সমাধানটি

— আর ..

@ আর .. দ্রষ্টব্য যে mvএমনকি -fগন্তব্যটি যেমন ইতিমধ্যে একটি সিমলিংক যা একটি সিমলিংক লুপের অংশ হিসাবে উপস্থিত রয়েছে এমনকি ব্যর্থ হতে পারে। ডেমো:ln -sf foo bar; ln -sf bar foo; echo "Before:"; ls -l foo bar; >testfile; mv testfile foo || { echo "Using mv -f"; mv -f testfile foo; }; echo "After:"; ls -l foo bar

— পিএইচকে

Answer 8

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

Answer 9

ব্যাকআপপিসি একটি ব্যাকআপ সিস্টেম যা ফাইল-স্তরের প্রতিলিপি সরবরাহের জন্য সার্ভারগুলিতে হার্ড লিঙ্কগুলি ব্যবহার করে।

ফাইলগুলি প্রথমে তাদের এমডি 5 হ্যাশের উপর ভিত্তি করে একটি "পুল" ডিরেক্টরি ট্রিতে সংরক্ষণ করা হয়। এই ফাইলটি ব্যবহার করে এমন কোনও ব্যাকআপ পুল ফাইলে একটি হার্ড লিঙ্ক তৈরি করে। ব্যাকআপগুলির মেয়াদ শেষ হওয়ার সাথে সাথে / মুছে ফেলা হওয়ার সাথে সাথে তাদের হার্ড লিঙ্কগুলি ফাইল সিস্টেম থেকে সরানো হবে।

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

এই পদ্ধতির কিছু অসুবিধাগুলি রয়েছে (মূলত, ব্যাকআপ স্টোরের প্রতিলিপি তৈরি করতে ফাইল-সিস্টেম-ভিত্তিক সরঞ্জামগুলি ব্যবহার করা কঠিন) তবে বাস্তবে এটি বেশ শক্তিশালী বলে প্রমাণিত।

---

অন্য ব্যবহারের ক্ষেত্রে: টমক্যাট জাভা ওয়েব অ্যাপ্লিকেশন সার্ভার ফাইলের নামগুলি মেটাডেটা হিসাবে বিবেচনা করে। ওয়েব সার্ভারের পাথের উপর ভিত্তি করে একটি জাভা "যুদ্ধ" ফাইলটির নামকরণ করতে হবে।

যেমন: foo.war জাভা কোড যা ইউআরএল পরিবেশন করে/foo

দুর্ভাগ্যক্রমে, এই সিদ্ধান্ত নেওয়ার আগে এটি প্রতীকগুলি সমাধান করে।

সুতরাং, বলুন যে আপনি একটি অ্যাপ্লিকেশন বিল্ড স্থাপন করতে চান এবং এটি বর্ণনামূলক ফাইলের নাম দিন (উদাহরণস্বরূপ, একটি প্রকাশের নম্বর বা তারিখ সহ)। আপনি করতে পারবেন না "বাস্তব" নাম দিয়ে ফাইলের একটি সিমবলিক লিঙ্ক করা - আপনি একটি hardlink করা আছে।

foo.warsymlinked foo-20170129.warকাজ করে না

foo.warহার্ডলিঙ্ক foo-20170129.warকাজ করে।

আমি এই টমকাট আচরণটি পছন্দ করি না, তবে হার্ডলিঙ্কগুলি আমাকে এর চারপাশে একটি উপায় দেয়।