কেন আমি একই ফাইল সিস্টেমে একটি "মাউন্ট - বাইন্ড" ডিরেক্টরি থেকে একটি ফাইলটিতে একটি "হার্ডলিঙ্ক" তৈরি করতে পারি না?


9

আসল সমস্যা

একটি ফাইল সিস্টেমে আমার একটি ফাইল রয়েছে: /data/src/file

এবং আমি এটির সাথে কঠোর লিঙ্ক করতে চাই: /home/user/proj/src/file

তবে /homeএটি একটি ডিস্কে রয়েছে এবং /dataঅন্যটিতে রয়েছে যাতে আমি একটি ত্রুটি পাই:

$ cd /home/user/proj/src
$ ln /data/src/file .
ln: failed to create hard link './file' => '/data/src/file': Invalid cross-device link

ঠিক আছে, তাই আমি শিখেছি আমি ডিভাইসগুলিতে হার্ড লিঙ্ক করতে পারি না। বোধ হয়।

হাতে সমস্যা

সুতরাং আমি ভেবেছিলাম আমি অভিনব এবং srcফোল্ডারের মাউন্ট করে ফেলব যা /dataফাইল সিস্টেমের মধ্যে রয়েছে:

$ mkdir -p /data/other/src
$ cd /home/user/proj
$ sudo mount --bind /data/other/src src/
$ cd src
$ # (now we're technically on `/data`'s file system, right?)
$ ln /data/src/file .
ln: failed to create hard link './file' => '/data/src/file': Invalid cross-device link

কেন এটি এখনও কাজ করে না?

কার্যসংক্রান্ত

আমি জানি আমার এই সেটআপটি ঠিক আছে কারণ আমি যতক্ষণ /dataনা বাঁধার পরিবর্তে "আসল" ডিরেক্টরিতে আছি ততক্ষণ আমি শক্ত লিঙ্কটি তৈরি করতে পারি।

$ cd /data/other/src
$ ln /data/src/file .
$ # OK
$ cd /home/user/proj/src
$ ls -lh
total 35M
-rw------- 2 user user 35M Jul 17 22:22 file

$

কিছু সিস্টেম তথ্য

$ uname -a
Linux <host> 4.10.0-24-generic #28-Ubuntu SMP Wed Jun 14 08:14:34 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux

$ findmnt
.
.
.
├─/home                               /dev/sdb8   ext4       rw,relatime,data=ordered
│ └─/home/usr/proj/src             /dev/sda2[/other/src]
│                                                 ext4       rw,relatime,data=ordered
└─/data                               /dev/sda2   ext4       rw,relatime,data=ordered

$ mountpoint -d /data
8:2

$ mountpoint -d /home/usr/proj/src/
8:2

দ্রষ্টব্য : পরিস্থিতি আরও স্পষ্ট করার জন্য আমি ফাইল এবং ডিরেক্টরিগুলির নাম ম্যানুয়ালি পরিবর্তিত করেছি, সুতরাং কমান্ড রিডআউটগুলিতে একটি টাইপো বা দুটি থাকতে পারে।


2
আপনি কোথায় ফোল্ডার মাউন্ট করবেন তা বিবেচ্য নয়। তারা বিভিন্ন পার্টিশনে শারীরিক হয়। প্রতিটি পার্টিশনের নিজস্ব ফাইল টেবিল রয়েছে এবং হার্ডলিঙ্কটি এই টেবিলটিতে কেবল রেকর্ড।
ব্যবহারকারী 996142

2
এখানে মূল বিষয়টি হ'ল ফাইলগুলি শারীরিকভাবে আলাদা আলাদা পার্টিশনে নেই। এটি একই পার্টিশন থেকে একই ফাইল সিস্টেম। পার্থক্যটি হ'ল বাইন্ড মাউন্ট।
রোয়াইমা

বাইন্ড মাউন্টটি নিছক একটি কল্পকাহিনী। এটি ডিস্কগুলিতে ডেটা স্ট্রাকচার পরিবর্তন করে না। ফাইল সিস্টেমগুলি এখনও শারীরিকভাবে পৃথক।
বব ইগ্রার

তবে আমি যখন হার্ড লিঙ্কটি তৈরি করি তখন আমি /dataবাইন্ড মাউন্ট ডিরেক্টরি থেকে ইনোডটি অ্যাক্সেস করতে পারি, সুতরাং বাইন্ড মাউন্টটি অবশ্যই একই পার্টিশনে থাকতে হবে /data, বা হার্ড লিঙ্কটি ডিভাইসগুলিতে কাজ করছে যা অবৈধ হওয়া উচিত, তবে যে কোনওভাবে কাজ করে। আমি কী মিস করছি?
jdk1.0

উত্তর:


6

সেখানে মন্তব্য হতাশাজনক অভাব এর কোড । এটি এমনভাবে মনে হয় যেন কেউ কখনই এটি দরকারী বলে মনে করেনি, যেহেতু টাইম বাইন্ড মাউন্টগুলি v2.4 এ কার্যকর করা হয়েছিল। অবশ্যই আপনাকে যা করতে হবে তা হ'ল বিকল্পটি .mnt->mnt_sbযেখানে এটি বলেছেন .mnt...

কারণ এটি আপনাকে সাবট্রির চারপাশে একটি সুরক্ষা সীমানা দেয়।

PS: যে বেশ কয়েকবার আলোচনা হয়েছিল, তবে অনুসন্ধানগুলি এড়ানোর জন্য: যেমন - মাউন্ট --bind / tmp / tmp বিবেচনা করুন; ব্যবহারকারীদের কাছে / টেম্প লেখার যোগ্য হয়ে থাকলেও ব্যবহারকারীরা অন্য কোথাও কোনও রুট এফএসের লিঙ্ক তৈরি করতে না পারার মতো পরিস্থিতি এখন আপনার হাতে এসে গেছে। অনুরূপ টেকনিকগুলি অন্যান্য বিচ্ছিন্নতার প্রয়োজনীয়তার জন্য কাজ করে - মূলত, আপনি প্রদত্ত সাবট্রির নাম / নামটি সীমাবদ্ধ রাখতে পারেন। আইওউ, এটি একটি ইচ্ছাকৃত বৈশিষ্ট্য। নোট করুন যে আপনি একগুচ্ছ গাছকে ক্রুটে বেঁধে রাখতে পারেন এবং পূর্বে প্রাক গাছগুলিতে কীভাবে জিনিসটি পুনরায় সাজানো যায় তা নির্বিশেষে প্রাক্কলিত নিষেধাজ্ঞাগুলি পেতে পারেন etc.

- আল ভাইরো

থ্রেডের আরও নিচে একটি দৃ concrete় উদাহরণ রয়েছে

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

mkdir /usr/lib/libs.jail
for i in $LIST_OF_LIBRARIES; do
ln /usr/lib/$i /usr/lib/libs.jail/$i
done
mount -r /usr/lib/libs.jail /jail/lib
chown prisoner /usr/log/jail
mount /usr/log/jail /jail/usr/log
chrootuid /jail prisoner /bin/untrusted &

যদিও সুরক্ষা যথেষ্ট হওয়া উচিত তবে আমি সম্ভবত বন্দী / jail/lib/libfoo.so লিখিত লিখিত (এটারওএস লিখুন) / জেল / ইউএসআর / লগ যেখানে এটি সম্ভাব্যভাবে লেখার যোগ্য তা এড়াতে চাই।


-1

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

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

এই বিধিনিষেধটি সর্বদা ইউনিক্স সিস্টেমে রয়েছে। এটি সমাধানের জন্য প্রতীকী লিঙ্কটি আংশিকভাবে উদ্ভাবিত হয়েছিল। আমি জানি তারা কার্যকরীভাবে এক রকম নয় তবে তারা সাধারণত ঠিক থাকে।

একটি প্রতীকী লিঙ্ক চেষ্টা করবেন? ( ln -s)


এখানে কোনও ইনোড ভাড়া দেওয়ার নাম থাকবে না। দুটি ভিউ সহ একটি মাত্র অন্তর্নিহিত ফাইল সিস্টেম রয়েছে।
গিলস 23'17

আমি প্রতীকী লিঙ্কটি না চাওয়ার একটি কারণ হ'ল আমার পথগুলি দীর্ঘ ছিল এবং এটি কর্কশ ছিল ls -l। কিন্ডা প্রথমে নির্বুদ্ধ যুক্তি দিয়েছিল, কিন্তু তারপরে এটি একটি খরগোশের গর্তের দিকে নিয়ে যায় এবং কঠোর লিঙ্কগুলি নিয়ে কী চলছে তা সম্পর্কে আমি কৌতূহল পেয়েছিলাম ...
jdk1.0

@ গিলিস, আমি যা বলছিলাম আমি যে বিষয়টিটি তৈরি করছিলাম তা হ'ল ইনোড রেন্ডারিং করা হাস্যকর হবে। সঠিক উত্তরটি কেন হ্রাস পেয়েছে তা ধারণা নেই।
বব ইজিগার

আপনি উপসংহারটি সঠিকভাবে পেয়েছেন তবে আপনার ব্যাখ্যাটি এত জায়গায় ভুল হয়েছে যে পুরো হিসাবে আপনার উত্তরটি খুব বিভ্রান্তিকর। ভাল ব্যাখ্যার জন্য সোর্সজেদির উত্তর দেখুন।
গিলস 'অসন্তুষ্ট হওয়া বন্ধ করুন'

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