ব্যাখ্যা_lca2010 - ক্লাউডে অনলাইন

কার্যক্রম:

NAME এর

ব্যাখ্যা_lca2010 - কোন মাধ্যম পাওয়া যায়নি: যখন পড়ার চেষ্টা বন্ধ করার সময় হয় স্ট্ররর(3) এর
মন।

প্রেরণা

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

এটা যে সহজ হতে পারে?

ভুল বার্তা as চাতুরতা
ভাল ত্রুটির বার্তাগুলি প্রায়শই সেই "এক শতাংশ" কাজ যা সময়সূচীর সময় বাদ দেওয়া হয়
চাপ আপনার প্রকল্প squeezes. যাইহোক, একটি ভাল ত্রুটি বার্তা একটি বিশাল করতে পারে,
ব্যবহারকারীর অভিজ্ঞতার অসামঞ্জস্যপূর্ণ উন্নতি, যখন ব্যবহারকারী ভীতিকর হয়ে যায়
অজানা অঞ্চল সাধারণত সম্মুখীন হয় না. এটি কোন সহজ কাজ নয়।

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

1.
আপনি একটি ডিবাগার চালাতে পারেন, যেমন জিডিবি(1), বা

2.
তুমি ব্যবহার করতে পার স্ট্রেস(এক্সএনএমএক্স) বা আঁটি(1) ভিতরে তাকান।

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

এই উদাহরণে, তবে, ব্যবহার করে স্ট্রেস(1) প্রকাশ করে
$ স্ট্রেস -e ট্রেস=খোলা ./মূর্খ
open("some/file", O_RDONLY) = -1 ENOENT (এমন কোন ফাইল বা ডিরেক্টরি নেই)
ফাইল খুলতে পারে না
$
এটি ত্রুটি বার্তা প্রদানের তুলনায় যথেষ্ট বেশি তথ্য। সাধারণত,
বোকা সোর্স কোড এই মত দেখায়
int fd = open("কিছু/কিছু", O_RDONLY);
যদি (fd <0)
{
fprintf(stderr, "ফাইল খুলতে পারছি না\n");
প্রস্থান(২০১১);
}
ব্যবহারকারীকে বলা হয় না যে ফাইল, এবং ব্যবহারকারীকে বলতেও ব্যর্থ হয় যে ত্রুটি. ফাইল ছিল
এমনকি সেখানে? একটি অনুমতি সমস্যা ছিল? এটি আপনাকে বলে যে এটি একটি খোলার চেষ্টা করছিল
ফাইল, কিন্তু যে সম্ভবত দুর্ঘটনা দ্বারা ছিল.

আপনার ক্লু স্টিকটি ধরুন এবং এটি দিয়ে লার্ভা প্রোগ্রামারকে মারতে যান। তার সম্পর্কে বলুন ভুল(3).
পরের বার আপনি প্রোগ্রামটি ব্যবহার করার সময় আপনি একটি ভিন্ন ত্রুটি বার্তা দেখতে পাবেন:
$ ./মূর্খ
open: এই ধরনের কোনো ফাইল বা ডিরেক্টরি নেই
$
অগ্রগতি, কিন্তু আমরা যা আশা করি তা নয়। ত্রুটি বার্তা হলে ব্যবহারকারী কিভাবে সমস্যা সমাধান করতে পারেন
তাকে বলেন না সমস্যা কি ছিল? উৎসের দিকে তাকিয়ে আমরা দেখতে পাই
int fd = open("কিছু/কিছু", O_RDONLY);
যদি (fd <0)
{
pererror("খোলা");
প্রস্থান(২০১১);
}
ক্লু স্টিক দিয়ে আরেকটি দৌড়ানোর সময়। এই সময়, ত্রুটি বার্তা এক ধাপ লাগে
এগিয়ে এবং এক ধাপ পিছনে:
$ ./মূর্খ
কিছু/কিছু: অনুরূপ কোন ফাইল বা ডিরেক্টরি নেই
$
এখন আমরা জানি যে ফাইলটি খোলার চেষ্টা করছিল, কিন্তু এখন আর জানানো হয় না যে এটি ছিল খোলা(2)
যে ব্যর্থ হয়েছে. এই ক্ষেত্রে এটি সম্ভবত তাৎপর্যপূর্ণ নয়, তবে এটির জন্য তাৎপর্যপূর্ণ হতে পারে
অন্যান্য সিস্টেম কল। এটা হতে পারতো তৈরি করুন(2) পরিবর্তে, একটি অপারেশন যা বোঝায়
বিভিন্ন অনুমতি প্রয়োজন।
const char * ফাইলের নাম = "কিছু/কিছু";
int fd = open(ফাইলের নাম, O_RDONLY);
যদি (fd <0)
{
pererror(ফাইলের নাম);
প্রস্থান(২০১১);
}
উপরের উদাহরণ কোডটি দুর্ভাগ্যবশত নন-লার্ভা প্রোগ্রামারদের জন্যও সাধারণ। সময়
সম্পর্কে আমাদের padawan শিক্ষার্থী বলতে স্ট্ররর(3) সিস্টেম কল।
$ ./মূর্খ
খোলা কিছু/কিছু: অনুরূপ কোন ফাইল বা ডিরেক্টরি নেই
$
এটি ব্যবহারকারীর কাছে উপস্থাপন করা যেতে পারে এমন তথ্যকে সর্বাধিক করে তোলে। কোডটি দেখে মনে হচ্ছে
এই:
const char * ফাইলের নাম = "কিছু/কিছু";
int fd = open(ফাইলের নাম, O_RDONLY);
যদি (fd <0)
{
fprintf(stderr, "ওপেন %s: %s\n", ফাইলের নাম, strerror(errno));
প্রস্থান(২০১১);
}
এখন আমাদের কাছে সিস্টেম কল, ফাইলের নাম এবং এরর স্ট্রিং আছে। এই সব রয়েছে
তথ্য যে স্ট্রেস(1) মুদ্রিত। যে এটি পায় হিসাবে ভাল.

অথবা এটা?

সীমাবদ্ধতা of ভুল এবং স্ট্ররর
1980 এর দশকে লেখক যে সমস্যাটি দেখেছিলেন তা হল যে ত্রুটি বার্তাটি অসম্পূর্ণ।
"এমন কোন ফাইল বা ডিরেক্টরি" কি "কে বোঝায় না?কিছু" ডিরেক্টরি, বা "জিনিস” ফাইল করুন
দ্য "কিছু" ডিরেক্টরি?

জন্য ম্যান পেজ এ একটি দ্রুত চেহারা স্ট্ররর(3) বলছে:
strerror - ত্রুটি নম্বর বর্ণনা করে রিটার্ন স্ট্রিং
ভালভাবে নোট করুন: এটি ত্রুটি বর্ণনা করছে সংখ্যা, ত্রুটি নয়।

অন্যদিকে, কার্নেল জানে ত্রুটি কি ছিল. একটি নির্দিষ্ট পয়েন্ট ছিল
কার্নেল কোড, একটি নির্দিষ্ট অবস্থার কারণে সৃষ্ট, যেখানে কার্নেল কোড শাখাযুক্ত এবং "না" বলে।
একটি ব্যবহারকারী-স্পেস প্রোগ্রাম নির্দিষ্ট শর্তটি বের করতে পারে এবং একটি ভাল ত্রুটি লিখতে পারে
বার্তা?

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

এবং এখানে একটি বিট যা grates: কার্নেল ইতিমধ্যেই জানে যে ফাইলটির নাম কি
বর্ণনাকারীর সাথে যুক্ত। কেন একজন প্রোগ্রামারকে সমস্ত অপ্রয়োজনীয় ডেটা পাস করতে হবে
কল স্ট্যাক নিচের উপায় শুধু একটি ত্রুটি বার্তা যা জারি করা হবে না উন্নত করতে? ভিতরে
বাস্তবতা, অনেক প্রোগ্রামার বিরক্ত করে না, এবং এর ফলে প্রাপ্ত ত্রুটি বার্তাগুলি আরও খারাপ
এটা.

কিন্তু এটি ছিল 1980-এর দশক, একটি PDP11-এ, সীমিত সংস্থান এবং কোনও ভাগ করা লাইব্রেরি ছিল না। পেছনে
তারপর, ইউনিক্সের কোন স্বাদ অন্তর্ভুক্ত করা হয় না / proc এমনকি প্রাথমিক আকারে, এবং lsof(1) প্রোগ্রাম
এক দশকেরও বেশি দূরে ছিল। তাই ধারণাটি অব্যবহারিক হিসাবে স্থগিত করা হয়েছিল।

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

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

প্রথম স্তরের প্রযুক্তি সহায়তার ত্রুটি বার্তাগুলি পাঠোদ্ধার করার প্রয়োজন না হলে এটি কি ভাল হবে না?
ব্যবহারকারীরা কল না করে বুঝতে পারে এমন ত্রুটির বার্তাগুলি থাকলে ভাল হবে না
কারিগরি সহায়তা?

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

2008 সালে, অনুবাদের অনুরোধের প্রবাহ লেখকের কাছে প্রায়ই ঘটেছিল। ইহা ছিল
25 বছরের পুরানো ধারণাটি পুনরায় পরীক্ষা করার সময়, এবং libexplain এর ফলাফল।

ব্যবহার দ্য লাইব্রেরি

লাইব্রেরির ইন্টারফেস সামঞ্জস্যপূর্ণ হওয়ার চেষ্টা করে, যেখানে সম্ভব। এর একটি দিয়ে শুরু করা যাক
উদাহরণ ব্যবহার করে স্ট্ররর(3)
যদি (পুনঃনামকরণ (পুরাতন_পথ, নতুন_পথ) < 0)
{
fprintf(stderr, "%s %s পুনঃনামকরণ করুন: %s\n", old_path, new_path,
strerror(errno));
প্রস্থান(২০১১);
}
libexplain এর পিছনে ধারণা হল একটি প্রদান করা স্ট্ররর(3) জন্য সমতুল্য প্রতি সিস্টেম কল,
সেই সিস্টেম কলের জন্য বিশেষভাবে তৈরি করা হয়েছে, যাতে এটি আরও বিস্তারিত ত্রুটি প্রদান করতে পারে
বার্তা, আপনি বিভাগের "ত্রুটি" শিরোনামের অধীনে যে তথ্য দেখতে পাচ্ছেন তার বেশিরভাগই রয়েছে৷
2 এবং 3 এক পৃষ্ঠাগুলি, প্রকৃত অবস্থা, প্রকৃত যুক্তি সম্পর্কে তথ্যের সাথে পরিপূরক
মান, এবং সিস্টেম সীমা।

সার্জারির সহজ কেস
সার্জারির স্ট্ররর(3) প্রতিস্থাপন:
যদি (পুনঃনামকরণ (পুরাতন_পথ, নতুন_পথ) < 0)
{
fprintf(stderr, "%s\n", ব্যাখ্যা_পুনঃনামকরণ(পুরানো_পথ, নতুন_পথ));
প্রস্থান(২০১১);
}

সার্জারির এরনো কেস
এটি একটি স্পষ্ট পাস করা সম্ভব ভুল(3) মান, আপনাকে প্রথমে কিছু করতে হবে
প্রক্রিয়াকরণ যে বিরক্ত হবে ভুল, যেমন ত্রুটি পুনরুদ্ধার:
যদি (নাম পরিবর্তন করুন(পুরাতন_পথ, নতুন_পথ < 0))
{
int old_errno = errno;
...কোড যে বিরক্ত করে ভুল...
fprintf(stderr, "%s\n", ব্যাখ্যা_errno_rename(old_errno,
পুরানো_পথ, নতুন_পথ));
প্রস্থান(২০১১);
}

সার্জারির মাল্টি থ্রেড মামলা
কিছু অ্যাপ্লিকেশন বহু-থ্রেডেড, এবং এইভাবে libexplain এর অভ্যন্তরীণ ভাগ করতে অক্ষম
বাফার আপনি ব্যবহার করে আপনার নিজস্ব বাফার সরবরাহ করতে পারেন
যদি (আনলিঙ্ক(পথের নাম))
{
char বার্তা[3000];
ব্যাখ্যা_বার্তা_আনলিঙ্ক(বার্তা, আকার(বার্তা), পথের নাম);
error_dialog(বার্তা);
রিটার্ন -1;
}
এবং সম্পূর্ণতা জন্য, উভয় ভুল(3) এবং থ্রেড-নিরাপদ:
ssize_t nbytes = read(fd, data, sizeof(data));
যদি (nbytes <0)
{
char বার্তা[3000];
int old_errno = errno;
...ভুল আরোগ্য...
ব্যাখ্যা_বার্তা_এরনো_রিড(বার্তা, আকার(বার্তা),
old_erno, fd, data, sizeof(data));
error_dialog(বার্তা);
রিটার্ন -1;
}

এই জন্য প্রতিস্থাপন হয় strerror_r(3), এটি আছে এমন সিস্টেমে।

ইন্টারফেস চিনি
সুবিধাজনক ফাংশন হিসাবে যোগ করা ফাংশনগুলির একটি সেট, প্রোগ্রামারদের ব্যবহার করার জন্য প্ররোচিত করার জন্য
libexplain লাইব্রেরি, লেখকের সবচেয়ে বেশি ব্যবহৃত libexplain ফাংশন হতে দেখা যাচ্ছে
কমান্ড লাইন প্রোগ্রাম:
int fd = ব্যাখ্যা_ক্রিয়েট_অর_ডাই(ফাইলের নাম, 0666);
এই ফাংশনটি একটি নতুন ফাইল তৈরি করার চেষ্টা করে। যদি এটি না করতে পারে, এটি একটি ত্রুটি বার্তা প্রিন্ট করে এবং
EXIT_FAILURE দিয়ে প্রস্থান করে। যদি কোন ত্রুটি না থাকে, তাহলে এটি নতুন ফাইল বর্ণনাকারী প্রদান করে।

একটি সম্পর্কিত ফাংশন:
int fd = ব্যাখ্যা_ক্রিয়েট_অন_এরর (ফাইলের নাম, 0666);
ব্যর্থতার উপর ত্রুটি বার্তাটি মুদ্রণ করবে, কিন্তু মূল ত্রুটির ফলাফলও প্রদান করবে, এবং
ভুল(3) unmolested, পাশাপাশি.

সব দ্য অন্যান্য পদ্ধতি কল
সাধারণভাবে, প্রতিটি সিস্টেম কলের নিজস্ব অন্তর্ভুক্ত ফাইল রয়েছে
#অন্তর্ভুক্তনাম.h>
যেটি ছয়টি ফাংশনের জন্য ফাংশন প্রোটোটাইপ সংজ্ঞায়িত করে:

· ব্যাখ্যা করা_নাম,

ব্যাখ্যানাম,

ব্যাখ্যা_বার্তা_নাম,

· ব্যাখ্যা_বার্তা_এরনো_নাম,

· ব্যাখ্যা করা_নাম_বা_মরি এবং

· ব্যাখ্যা করা_নাম_অন_ত্রুটি।

প্রতিটি ফাংশন প্রোটোটাইপ ডক্সিজেন ডকুমেন্টেশন, এবং এই ডকুমেন্টেশন আছে is না ছিনতাই
যখন অন্তর্ভুক্ত ফাইল ইনস্টল করা হয়।

সার্জারির অপেক্ষা করুন(2) সিস্টেম কলের (এবং বন্ধুদের) কিছু অতিরিক্ত রূপ রয়েছে যা ব্যর্থতাকে ব্যাখ্যা করে
একটি প্রস্থান অবস্থা হতে যা EXIT_SUCCESS নয়। এই প্রযোজ্য পদ্ধতি(3) এবং বন্ধ(3) হিসাবে
ভাল।

কভারেজের মধ্যে রয়েছে 221টি সিস্টেম কল এবং 547টি ioctl অনুরোধ। আরো অনেক সিস্টেম আছে
কল এখনও বাস্তবায়ন করা. সিস্টেম কল যে ফিরে না, যেমন প্রস্থান(2), উপস্থিত নেই
লাইব্রেরিতে, এবং কখনই হবে না। দ্য Exec সিস্টেম কল পরিবার হয় সমর্থিত, কারণ
একটি ত্রুটি হলে তারা ফিরে আসে।

বিড়াল
সম্পূর্ণ ত্রুটি রিপোর্টিং সহ একটি অনুমানমূলক "বিড়াল" প্রোগ্রাম দেখতে এটির মতো হতে পারে,
libexplain ব্যবহার করে।
#অন্তর্ভুক্ত
# অন্তর্ভুক্ত
#অন্তর্ভুক্ত
একটি libexplain জন্য অন্তর্ভুক্ত আছে, প্লাস স্বাভাবিক সন্দেহভাজন. (যদি আপনি কমাতে চান
প্রিপ্রসেসর লোড, আপনি নির্দিষ্ট ব্যবহার করতে পারেননাম.h> অন্তর্ভুক্ত।)
স্থির শূন্য
প্রক্রিয়া (ফাইল *এফপি)
{
জন্য (;;)
{
চার বাফার [4096];
size_t n = ব্যাখ্যা_fread_or_die(বাফার, 1, sizeof(বাফার), fp);
যদি (! n)
বিরতি;
ব্যাখ্যা করুন_fwrite_or_die(বাফার, 1, n, stdout);
}
}
সার্জারির প্রক্রিয়া ফাংশন স্ট্যান্ডার্ড আউটপুটে একটি ফাইল স্ট্রিম কপি করে। একটি ত্রুটি ঘটতে হবে
পড়া বা লেখার জন্য, এটি রিপোর্ট করা হয়েছে (এবং পাথনামটি অন্তর্ভুক্ত করা হবে
ত্রুটি) এবং কমান্ডটি EXIT_FAILURE এর সাথে প্রস্থান করে। আমরা এমনকি ট্র্যাকিং সম্পর্কে চিন্তা না
pathnames, অথবা কল স্ট্যাকের নিচে তাদের পাস.
কোন int
প্রধান (int argc, char **argv)
{
জন্য (;;)
{
int c = getopt(argc, argv, "o:");
যদি (c == EOF)
বিরতি;
সুইচ (গ)
{
কেস 'ও':
ব্যাখ্যা_ফ্রিওপেন_অর_ডাই(অপটার্গ, "ডব্লিউ", stdout);
বিরতি;
এই কোডের মজার অংশ হল libexplain ত্রুটি রিপোর্ট করতে পারে সুদ্ধ দ্য পথের নাম এমন কি
যদি তুমি না এখানে যেমন করা হয়েছে স্পষ্টভাবে stdout পুনরায় খুলুন। আমরা চিন্তাও করি না
ফাইলের নাম ট্র্যাকিং।
ডিফল্ট:
fprintf(stderr, "ব্যবহার: %ss [ -o ] ...\n",
argv[0]);
ফেরত EXIT_FAILURE;
}
}
যদি (অপটিন্ড == argc)
প্রক্রিয়া(stdin);
আর
{
যখন (অপটিন্ড < argc)
{
ফাইল *fp = ব্যাখ্যা_ফোপেন_অর_ডি(আর্গভি[অপটিন্ড]++, "আর");
প্রক্রিয়া(fp);
ব্যাখ্যা_fclose_or_die(fp);
}
}
স্ট্যান্ডার্ড আউটপুট পরোক্ষভাবে বন্ধ করা হবে, কিন্তু একটি ত্রুটি রিপোর্ট হতে অনেক দেরি হবে
জারি করা হয়েছে, তাই আমরা এখানে তা করি, যদি বাফার করা I/O এখনও কিছু না লিখে থাকে, এবং
একটি ENOSPC ত্রুটি বা কিছু আছে।
ব্যাখ্যা_ফ্লাশ_অর_ডাই(stdout);
ফেরত EXIT_SUCCESS;
}
এখানেই শেষ. সম্পূর্ণ ত্রুটি রিপোর্টিং, পরিষ্কার কোড.

মরিচা এর স্কেল of ইন্টারফেস ধার্মিকতা
আপনারা যারা এটির সাথে পরিচিত নন তাদের জন্য, রাস্টি রাসেলের "কিভাবে আমি এটিকে অপব্যবহার করা কঠিন করি?"
API ডিজাইনারদের জন্য পৃষ্ঠাটি অবশ্যই পড়া উচিত।
http://ozlabs.org/~rusty/index.cgi/tech/2008‐03-30.html

10. এটা অসম্ভব থেকে পাওয়া ভুল।

লক্ষ্যগুলি উচ্চ, উচ্চাভিলাষীভাবে উচ্চ সেট করা দরকার, পাছে আপনি সেগুলি অর্জন করতে পারেন এবং মনে করেন যে আপনি আছেন
আপনি না যখন শেষ.

libexplain লাইব্রেরি বোগাস পয়েন্টার এবং অন্যান্য অনেক জাল সিস্টেম কল প্যারামিটার সনাক্ত করে,
এবং সাধারণত সবচেয়ে কঠিন পরিস্থিতিতেও সেগফল্ট এড়াতে চেষ্টা করে।

libexplain লাইব্রেরি থ্রেড নিরাপদ হতে ডিজাইন করা হয়েছে. আরো বাস্তব-বিশ্ব ব্যবহার সম্ভবত হবে
এই উন্নত করা যেতে পারে স্থান প্রকাশ.

সবচেয়ে বড় সমস্যা হল প্রকৃত ফাংশনের নাম নিজেরাই। কারণ সি নেই
নাম-স্পেস, libexplain লাইব্রেরি সর্বদা একটি ব্যাখ্যা_ নাম উপসর্গ ব্যবহার করে। এই হল
প্রতীক দ্বন্দ্ব এড়াতে একটি ছদ্ম-নাম-স্পেস তৈরি করার ঐতিহ্যগত উপায়।
যাইহোক, এর ফলে কিছু অপ্রাকৃত-শব্দযুক্ত নাম হয়।

9. সার্জারির সংকলনকারী or linker না করবে না দিন আপনি পাওয়া it ভুল।

একটি সাধারণ ভুল হল ব্যাখ্যা_ওপেন ব্যবহার করা যেখানে ব্যাখ্যা_ওপেন_অর_ডাই উদ্দেশ্য ছিল।
সৌভাগ্যবশত, কম্পাইলার প্রায়ই এই সময়ে একটি টাইপ ত্রুটি জারি করবে (যেমন বরাদ্দ করতে পারে না
const char * rvalue থেকে একটি int lvalue)।

8. সার্জারির সংকলনকারী ইচ্ছা সতর্ক if আপনি পাওয়া it ভুল।

ব্যাখ্যা_পুনঃনাম_অর_ডাই এর উদ্দেশ্যে ব্যাখ্যা করার সময় যদি ব্যাখ্যা_রিনেম ব্যবহার করা হয়, তাহলে এটি অন্য কারণ হতে পারে
সমস্যা GCC এর একটি দরকারী warn_unused_result ফাংশন বৈশিষ্ট্য এবং libexplain আছে
লাইব্রেরি এটি সমস্ত ব্যাখ্যার সাথে সংযুক্ত করে_নাম ফাংশন একটি সতর্কতা তৈরি করতে কল যখন আপনি
এই ভুল করা সঙ্গে এই একত্রিত জিসিসি -ভুল এটিকে লেভেল 9 নেকিতে উন্নীত করতে।

7. সার্জারির সুস্পষ্ট ব্যবহার is (সম্ভবত) দ্য ঠিক এক.

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

6. সার্জারির নাম বলে আপনি কিভাবে থেকে ব্যবহার এটা.

ব্যাখ্যা পড়া বিশেষভাবে গুরুত্বপূর্ণ_নাম"ব্যাখ্যা করুন" হিসাবে _or_dieনাম অথবা মর)".
একটি সামঞ্জস্যপূর্ণ ব্যাখ্যা_ নাম-স্পেস উপসর্গ ব্যবহার করার কিছু দুর্ভাগ্যজনক পার্শ্ব-প্রতিক্রিয়া আছে
স্পষ্টতা বিভাগ, পাশাপাশি।

নামের মধ্যে শব্দের ক্রমও যুক্তির ক্রম নির্দেশ করে। যুক্তি
তালিকা সবসময় শেষ সিস্টেম কলে পাস করা একই আর্গুমেন্ট সহ; সব of তাহাদিগকে। যদি
_errno_ নামের মধ্যে উপস্থিত হয়, এর আর্গুমেন্ট সবসময় সিস্টেম কল আর্গুমেন্টের আগে থাকে। যদি
_message_ নামের মধ্যে উপস্থিত হয়, এর দুটি আর্গুমেন্ট সর্বদা প্রথমে আসে।

5. Do it অধিকার or it ইচ্ছা বিরতি at রানটাইম

libexplain লাইব্রেরি বোগাস পয়েন্টার এবং অন্যান্য অনেক জাল সিস্টেম কল প্যারামিটার সনাক্ত করে,
এবং সাধারণত সবচেয়ে কঠিন পরিস্থিতিতেও সেগফল্ট এড়াতে চেষ্টা করে। এটা উচিত
রানটাইমে কখনই বিরতি করবেন না, তবে আরও বাস্তব-বিশ্ব ব্যবহার নিঃসন্দেহে এটিকে উন্নত করবে।

কিছু ত্রুটি বার্তা শেষ ব্যবহারকারীদের পরিবর্তে বিকাশকারী এবং রক্ষণাবেক্ষণকারীদের লক্ষ্য করে
বাগ সমাধানে সহায়তা করতে পারে। এত "রানটাইমে বিরতি" হিসাবে "তথ্যপূর্ণ হতে হবে না"
রানটাইম" (সিস্টেম কল বারফের পরে)।

4. অনুসরণ করা সাধারণ সম্মেলন এবং আপনি হবে পাওয়া it ঠিক আছে।

যেহেতু C এর নাম-স্থান নেই, তাই libexplain লাইব্রেরি সর্বদা একটি ব্যাখ্যা_ নাম ব্যবহার করে
উপসর্গ এটি এড়ানোর জন্য একটি ছদ্ম-নাম-স্পেস তৈরি করার ঐতিহ্যগত উপায়
প্রতীক দ্বন্দ্ব।

সমস্ত libexplain কলের ট্রেলিং আর্গুমেন্টগুলি সিস্টেম কলের অনুরূপ
বর্ণনা করছেন। এটির সাথে সাদৃশ্যপূর্ণ একটি সামঞ্জস্যপূর্ণ সম্মেলন প্রদানের উদ্দেশ্যে করা হয়েছে৷
সিস্টেম নিজেদের কল.

3. পড়া দ্য ডকুমেন্টেশন এবং আপনি হবে পাওয়া it ঠিক আছে।

libexplain লাইব্রেরির লক্ষ্য প্রত্যেকের জন্য সম্পূর্ণ ডক্সিজেন ডকুমেন্টেশন থাকা
সর্বজনীন API কল (এবং অভ্যন্তরীণভাবেও)।

বার্তা বিষয়বস্তু

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

আমাদের প্রথম উদাহরণ পুনর্বিবেচনা করে, কোডটি এটি পছন্দ করবে যদি এটি libexplain ব্যবহার করে:
int fd = ব্যাখ্যা_ওপেন_অর_ডাই("some/thing", O_RDONLY, 0);
এই মত একটি ত্রুটি বার্তা দিয়ে ব্যর্থ হবে
open(pathname = "some/file", flags = O_RDONLY) ব্যর্থ হয়েছে, এরকম কোন ফাইল বা ডিরেক্টরি নেই
(2, ENOENT) কারণ বর্তমান ডিরেক্টরিতে "কিছু" ডিরেক্টরি নেই
এটি তিন টুকরো হয়ে যায়
সিস্টেম-কল ব্যর্থ হয়েছে, সিস্টেম ত্রুটি কারণ
ব্যাখ্যা

সামনে কারণ
"কারণ" অত্যধিক প্রযুক্তিগত থেকে অ-এর আগে বার্তাটির অংশটি দেখা সম্ভব।
প্রযুক্তিগত ব্যবহারকারীরা, বেশিরভাগই সঠিকভাবে সিস্টেমটি মুদ্রণের ফলে নিজেই কল করুন
ত্রুটি বার্তার শুরু। এবং এটা মনে হচ্ছে স্ট্রেস(1) আউটপুট, বোনাস geek জন্য
পয়েন্ট.
open(pathname = "some/file", flags = O_RDONLY) ব্যর্থ হয়েছে, এরকম কোন ফাইল বা ডিরেক্টরি নেই
(2, ENOENT)
ত্রুটি বার্তার এই অংশটি বিকাশকারীর জন্য অপরিহার্য যখন তিনি কোডটি লিখছেন,
এবং রক্ষণাবেক্ষণকারীর জন্য সমানভাবে গুরুত্বপূর্ণ যাকে বাগ রিপোর্ট পড়তে হবে এবং বাগগুলি ঠিক করতে হবে
কোড এটা ঠিক কি ব্যর্থ হয়েছে বলে.

যদি এই পাঠ্যটি ব্যবহারকারীর কাছে উপস্থাপিত না হয় তবে ব্যবহারকারী এটি কপি-পেস্ট করতে পারবেন না
বাগ রিপোর্ট, এবং যদি এটি বাগ রিপোর্টে না থাকে তবে রক্ষণাবেক্ষণকারী আসলে কী হয়েছে তা জানতে পারে না
ভুল।

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

সিস্টেম কল প্রতিনিধিত্ব এছাড়াও বার্তা বাকি প্রসঙ্গ দেয়. প্রয়োজন হলে
দেখা দেয়, আপত্তিকর সিস্টেম কল আর্গুমেন্ট ব্যাখ্যায় নাম দ্বারা উল্লেখ করা যেতে পারে
"কারণ" এর পরে। উপরন্তু, সমস্ত স্ট্রিং সম্পূর্ণরূপে উদ্ধৃত এবং সি স্ট্রিং এস্কেপ করা হয়, তাই
এম্বেড করা নতুন লাইন এবং অ-মুদ্রণ অক্ষর ব্যবহারকারীর টার্মিনালকে যেতে দেবে না
খড়কুটো

সার্জারির সিস্টেম ত্রুটি যা থেকে বেরিয়ে আসে স্ট্ররর(2), প্লাস ত্রুটি চিহ্ন। অধৈর্য এবং
বিশেষজ্ঞ sysadmins এই সময়ে পড়া বন্ধ করতে পারে, কিন্তু লেখকের আজ পর্যন্ত অভিজ্ঞতা
যে আরও পড়া ফলপ্রসূ হয়. (যদি এটি ফলপ্রসূ না হয় তবে এটি সম্ভবত এর একটি এলাকা
libexplain যে উন্নত করা যেতে পারে. কোড অবদান অবশ্যই স্বাগত জানাই।)

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

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

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

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

যে ভাষাগুলির অংশগুলিকে একত্রিত করতে হবে সেগুলির জন্য বিধান করা হয়েছে৷
সিস্টেম-কল ব্যর্থ হয়েছে, সিস্টেম ত্রুটি কারণ ব্যাখ্যা
স্থানীয় ভুল বার্তাগুলিতে সঠিক ব্যাকরণের জন্য বিভিন্ন ক্রমে।

পোস্টমর্টেম
এমন সময় আছে যখন একটি প্রোগ্রাম এখনও libexplain ব্যবহার করতে পারে না এবং আপনি ব্যবহার করতে পারবেন না স্ট্রেস(1)
হয় এখানে একটি ব্যাখ্যা করা(1) libexplain সহ কমান্ড অন্তর্ভুক্ত যা ব্যবহার করা যেতে পারে
ডিসিফার ত্রুটি বার্তা, যদি অন্তর্নিহিত সিস্টেমের অবস্থা খুব বেশি পরিবর্তিত না হয়।
$ ব্যাখ্যা করা নামান্তর foo বিন্যাস /tmp/bar/baz -e ENOENT
পুনঃনামকরণ(oldpath = "foo", newpath = "/tmp/bar/baz") ব্যর্থ হয়েছে, এরকম কোনো ফাইল বা ডিরেক্টরি নেই
(2, ENOENT) কারণ নতুনপথে "বার" ডিরেক্টরি নেই"/ tmp -র পরিবর্তে" ডিরেক্টরি
$
সিস্টেম কল আর্গুমেন্ট নাম ব্যবহার করে পথের অস্পষ্টতা কীভাবে সমাধান করা হয় তা নোট করুন। এর
অবশ্যই, আপনাকে ত্রুটি এবং সিস্টেম কল জানতে হবে ব্যাখ্যা করা(1) দরকারী হতে. একটি হিসাবে
পাশাপাশি, এটি যাচাই করার জন্য libexplain স্বয়ংক্রিয় পরীক্ষা স্যুট দ্বারা ব্যবহৃত উপায়গুলির মধ্যে একটি
libexplain কাজ করছে।

দর্শন
"আমাকে সবকিছু বলুন, এমন জিনিসগুলি সহ যা আমি খুঁজতে জানি না।"

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

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

পাথগুলি সমাধান করার সময়, যদি একটি পাথ উপাদান বিদ্যমান না থাকে তবে libexplain অনুরূপ সন্ধান করবে
টাইপোগ্রাফিক ত্রুটির জন্য বিকল্প প্রস্তাব করার জন্য নাম।

libexplain লাইব্রেরি যতটা সম্ভব কম হিপ ব্যবহার করার চেষ্টা করে, এবং সাধারণত কোনটিই নয়। এই
প্রক্রিয়ার অবস্থাকে বিরক্ত না করার জন্য, যতদূর সম্ভব, যদিও কখনও কখনও এটি হয়
অনিবার্য

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

libexplain লাইব্রেরি একটি প্রক্রিয়ার সিগন্যাল হ্যান্ডলারদের বিরক্ত করে না। এটা তৈরি করে
একটি পয়েন্টার একটি চ্যালেঞ্জ সেগফল্ট করবে কিনা তা নির্ধারণ করা, কিন্তু অসম্ভব নয়।

যখন তথ্য একটি সিস্টেম কলের মাধ্যমে পাওয়া যায় সেইসাথে একটি মাধ্যমে উপলব্ধ / proc
এন্ট্রি, সিস্টেম কল পছন্দ করা হয়. এটি প্রক্রিয়াটির অবস্থাকে বিরক্ত না করার জন্য।
এমনও সময় আছে যখন কোনো ফাইল বর্ণনাকারী পাওয়া যায় না।

libexplain লাইব্রেরি বড় ফাইল সমর্থন সহ কম্পাইল করা হয়. বড়/ছোট নেই
সিজোফ্রেনিয়া যেখানে এটি API-তে আর্গুমেন্টের ধরনকে প্রভাবিত করে এবং ত্রুটি জারি করা হবে
যদি প্রয়োজনীয় বড় ফাইলের সংজ্ঞা অনুপস্থিত থাকে।

FIXME: কোডে ফাইল সিস্টেম কোটা পরিচালনা করা হয়েছে তা নিশ্চিত করার জন্য কাজ করা প্রয়োজন। এই
কিছু ক্ষেত্রে প্রযোজ্য getrlimit(2) সীমানা, পাশাপাশি।

এমন কিছু ক্ষেত্রে রয়েছে যখন আত্মীয়দের পথগুলি তথ্যহীন। যেমন: সিস্টেম ডেমন,
সার্ভার এবং ব্যাকগ্রাউন্ড প্রসেস। এই ক্ষেত্রে, ত্রুটিতে পরম পথ ব্যবহার করা হয়
ব্যাখ্যা

পাথ রেজোলিউশন

সংক্ষিপ্ত সংস্করণ: দেখুন পথ_রেজোলিউশন(7).

দীর্ঘ সংস্করণ: বেশীরভাগ ব্যবহারকারী কখনও শোনেননি পথ_রেজোলিউশন(7), এবং অনেক উন্নত ব্যবহারকারী
এটা পড়া না. এখানে একটি টীকা সংস্করণ আছে:

ধাপ 1: শুরু of দ্য সমাধান প্রক্রিয়া
যদি পাথনামটি স্ল্যাশ (“/”) অক্ষর দিয়ে শুরু হয়, তাহলে শুরুর লুকআপ ডিরেক্টরি হবে
কলিং প্রক্রিয়ার রুট ডিরেক্টরি।

যদি পাথনেমটি স্ল্যাশ(“/”) অক্ষর দিয়ে শুরু না হয়, তাহলে স্টার্টিং লুকআপ
রেজোলিউশন প্রক্রিয়ার ডিরেক্টরিটি প্রক্রিয়াটির বর্তমান কার্যকারী ডিরেক্টরি।

ধাপ 2: ওয়াক বরাবর দ্য পথ
বর্তমান লুকআপ ডিরেক্টরিকে প্রারম্ভিক লুকআপ ডিরেক্টরিতে সেট করুন। এখন, প্রতিটি অ-এর জন্য
পথনামের চূড়ান্ত উপাদান, যেখানে একটি উপাদান হল একটি সাবস্ট্রিং যা স্ল্যাশ (“/”) দ্বারা সীমাবদ্ধ
অক্ষর, এই উপাদানটি বর্তমান লুকআপ ডিরেক্টরিতে দেখা হয়।

যদি প্রক্রিয়াটির বর্তমান লুকআপ ডিরেক্টরিতে অনুসন্ধানের অনুমতি না থাকে, একটি EACCES
ত্রুটি ফেরত দেওয়া হয় ("অনুমতি অস্বীকার")।
open(pathname = "/home/archives/.ssh/private_key", flags = O_RDONLY) ব্যর্থ হয়েছে,
অনুমতি অস্বীকার করা হয়েছে (13, EACCES) কারণ প্রক্রিয়াটিতে অনুসন্ধানের অনুমতি নেই৷
পাথনাম "/home/archives/.ssh" ডিরেক্টরিতে, প্রক্রিয়া কার্যকর GID 1000
"pmiller" ডিরেক্টরির মালিকের সাথে মেলে না 1001 "আর্কাইভস" তাই মালিক
অনুমতি মোড "rwx" উপেক্ষা করা হয়েছে, অন্য অনুমতি মোড হল "---", এবং
প্রক্রিয়া বিশেষাধিকারপ্রাপ্ত নয় (DAC_READ_SEARCH ক্ষমতা নেই)

যদি উপাদানটি পাওয়া না যায়, একটি ENOENT ত্রুটি ফেরত দেওয়া হয় ("এমন কোনো ফাইল বা ডিরেক্টরি নেই")।
আনলিঙ্ক (পথের নাম = "/home/microsoft/rubbish") ব্যর্থ হয়েছে, এই ধরনের কোনো ফাইল বা ডিরেক্টরি নেই (2,
ENOENT) কারণ পথনামে কোন "মাইক্রোসফ্ট" ডিরেক্টরি নেই "/ হোম" ডিরেক্টরি

ব্যবহারকারীরা যখন পথের নাম ভুল টাইপ করে, তখন পরামর্শ দেয় তাদের জন্য কিছু সমর্থনও রয়েছে
ENOENT ফেরত দেওয়া হয়:
open(pathname = "/user/include/fcntl.h", পতাকা = O_RDONLY) ব্যর্থ হয়েছে, এই ধরনের কোনো ফাইল বা
ডিরেক্টরি (2, ENOENT) কারণ পথনাম "/" এ কোন "ব্যবহারকারী" ডিরেক্টরি নেই
ডিরেক্টরি, আপনি পরিবর্তে "usr" ডিরেক্টরি বলতে চান?

যদি উপাদানটি পাওয়া যায়, তবে এটি একটি ডিরেক্টরি বা প্রতীকী লিঙ্ক নয়, একটি ENOTDIR
ত্রুটি ফিরে এসেছে ("একটি ডিরেক্টরি নয়")।
open(pathname = "/home/pmiller/.netrc/lca", পতাকা = O_RDONLY) ব্যর্থ হয়েছে, একটি নয়
ডিরেক্টরি (20, ENOTDIR) কারণ পাথনেমে ".netrc" নিয়মিত ফাইল
"/home/pmiller" ডিরেক্টরিটি একটি ডিরেক্টরি হিসাবে ব্যবহার করা হচ্ছে যখন এটি নেই

যদি উপাদানটি পাওয়া যায় এবং একটি ডিরেক্টরি হয়, তাহলে আমরা বর্তমান লুকআপ ডিরেক্টরিকে সেটিতে সেট করি
ডিরেক্টরিতে যান এবং পরবর্তী উপাদানে যান।

যদি উপাদানটি পাওয়া যায় এবং একটি প্রতীকী লিঙ্ক (symlink), আমরা প্রথমে এই প্রতীকী সমাধান করি
লিঙ্ক (স্টার্টিং লুকআপ ডিরেক্টরি হিসাবে বর্তমান লুকআপ ডিরেক্টরির সাথে)। ত্রুটির উপর, যে
ত্রুটি ফেরত দেওয়া হয়। ফলাফল একটি ডিরেক্টরি না হলে, একটি ENOTDIR ত্রুটি ফিরে আসে।
আনলিঙ্ক (পথের নাম = "/tmp/dangling/rubbish") ব্যর্থ হয়েছে, এই ধরনের কোনো ফাইল বা ডিরেক্টরি নেই (2,
ENOENT) কারণ পথনামে "ঝুলন্ত" প্রতীকী লিঙ্ক "/ tmp -র পরিবর্তে" ডিরেক্টরি
"কোথাও নয়" বোঝায় যা বিদ্যমান নেই
যদি সিমলিংকের রেজোলিউশন সফল হয় এবং একটি ডিরেক্টরি প্রদান করে, আমরা বর্তমান সেট করি
যে ডিরেক্টরিতে ডিরেক্টরি দেখুন, এবং পরবর্তী উপাদানে যান। উল্লেখ্য যে
রেজোলিউশন প্রক্রিয়া এখানে পুনরাবৃত্তি জড়িত. স্ট্যাকের বিরুদ্ধে কার্নেল রক্ষা করার জন্য
ওভারফ্লো, এবং পরিষেবা অস্বীকার থেকে রক্ষা করার জন্য, সর্বাধিক সীমা রয়েছে
পুনরাবৃত্তি গভীরতা, এবং সর্বাধিক সংখ্যক প্রতীকী লিঙ্ক অনুসরণ করা হয়েছে। একটি ELOOP ত্রুটি
সর্বাধিক অতিক্রম করা হলে ফেরত দেওয়া হয় ("অত্যধিক স্তরের প্রতীকী লিঙ্ক")।
open(pathname = "/tmp/dangling", flags = O_RDONLY) ব্যর্থ হয়েছে, এর অনেকগুলি স্তর
প্রতীকী লিঙ্ক (40, ELOOP) কারণ একটি প্রতীকী লিঙ্ক লুপের সম্মুখীন হয়েছে
পথের নাম, "/tmp/dangling" থেকে শুরু
অনেকগুলি সিমলিংক থাকলে একটি ELOOP বা EMLINK ত্রুটি পাওয়াও সম্ভব, কিন্তু না
লুপ সনাক্ত করা হয়েছে।
open(pathname = "/tmp/র্যাবিট-হোল", পতাকা = O_RDONLY) ব্যর্থ হয়েছে, এর অনেকগুলি স্তর
সিম্বলিক লিংক (40, ELOOP) কারণ অনেকগুলো সিম্বলিক লিঙ্ক এর সম্মুখীন হয়েছে
পথের নাম (8)
লক্ষ্য করুন কিভাবে প্রকৃত সীমা মুদ্রিত হয়।

ধাপ 3: আবিষ্কার দ্য চূড়ান্ত প্রবেশ
পাথনামের চূড়ান্ত উপাদানের সন্ধান অন্য সকলের মতোই হয়
উপাদান, পূর্ববর্তী ধাপে বর্ণিত, দুটি পার্থক্য সহ:

(i) চূড়ান্ত উপাদানটি একটি ডিরেক্টরি হতে হবে না (অন্তত পাথ রেজোলিউশন পর্যন্ত
প্রক্রিয়া উদ্বিগ্ন। এটি একটি ডিরেক্টরি হতে পারে, বা একটি নন-ডিরেক্টরি, কারণ
নির্দিষ্ট সিস্টেম কলের প্রয়োজনীয়তা)।

(২)
চূড়ান্ত উপাদান পাওয়া না গেলে এটি অগত্যা একটি ত্রুটি নয়; হয়তো আমরা শুধু
এটি তৈরি করা চূড়ান্ত এন্ট্রি চিকিত্সার উপর বিস্তারিত বর্ণনা করা হয়
নির্দিষ্ট সিস্টেম কলের ম্যানুয়াল পৃষ্ঠা।

(গ)
এটি একটি প্রতীকী লিঙ্ক হলে শেষ উপাদানটির সাথে সমস্যা হওয়াও সম্ভব
এবং এটি অনুসরণ করা উচিত নয়। উদাহরণস্বরূপ, ব্যবহার করে খোলা(2) O_NOFOLLOW পতাকা:
open(pathname = "a-symlink", flags = O_RDONLY | O_NOFOLLOW) ব্যর্থ হয়েছে, এর অনেকগুলি স্তর
সিম্বলিক লিঙ্ক (ELOOP) কারণ O_NOFOLLOW নির্দিষ্ট করা হয়েছিল কিন্তু পাথনাম একটিকে বোঝায়
প্রতীকী লিঙ্ক

(ঈ)
পথনাম টাইপ করার সময় ব্যবহারকারীদের ভুল করা সাধারণ। libexplain লাইব্রেরি
যখন ENOENT ফেরত দেওয়া হয় তখন পরামর্শ দেওয়ার চেষ্টা করে, উদাহরণস্বরূপ:
open(pathname = "/usr/include/filecontrl.h", পতাকা = O_RDONLY) ব্যর্থ হয়েছে, এই ধরনের কোনো ফাইল বা
ডিরেক্টরি (2, ENOENT) কারণ পথনামে কোন "filecontrl.h" নিয়মিত ফাইল নেই
"/ usr / অন্তর্ভুক্ত" ডিরেক্টরি, আপনি কি এর পরিবর্তে "fcntl.h" নিয়মিত ফাইল বলতে চান?

(v) এটাও সম্ভব যে চূড়ান্ত উপাদানটি a ছাড়া অন্য কিছু হতে হবে
নিয়মিত ফাইল:
রিডলিংক (পাথের নাম = "শুধু-এ-ফাইল", ডেটা = 0x7F930A50, ডেটা_সাইজ = 4097) ব্যর্থ হয়েছে,
অবৈধ যুক্তি (22, EINVAL) কারণ পথনাম একটি নিয়মিত ফাইল, একটি প্রতীকী লিঙ্ক নয়

(ঊ)
FIXME: "t" বিট পরিচালনা।

সীমা
পথের নাম এবং ফাইলের নামগুলির ক্ষেত্রে অনেকগুলি সীমাবদ্ধতা রয়েছে৷

পাথনামের দৈর্ঘ্য সীমা
পাথনামের জন্য সর্বোচ্চ দৈর্ঘ্য আছে। যদি পথের নাম (বা কিছু মধ্যবর্তী
প্রতীকী লিঙ্কগুলি সমাধান করার সময় প্রাপ্ত পথনাম) খুব দীর্ঘ, একটি ENAMETOOLONG৷
ত্রুটি ফিরে এসেছে ("ফাইলের নাম খুব দীর্ঘ")। কিভাবে সিস্টেম সীমা অন্তর্ভুক্ত করা হয় লক্ষ্য করুন
ত্রুটি বার্তা.
খুলুন (পথের নাম = "খুব দীর্ঘ", পতাকা = O_RDONLY) ব্যর্থ হয়েছে, ফাইলের নাম অনেক বড় (36,
ENAMETOOLONG) কারণ পাথনাম সিস্টেমের সর্বাধিক পাথ দৈর্ঘ্য (4096) ছাড়িয়ে গেছে

ফাইলের নামের দৈর্ঘ্য সীমা
কিছু ইউনিক্স ভেরিয়েন্টের প্রতিটি পাথ কম্পোনেন্টে বাইটের সংখ্যার একটি সীমা থাকে।
তাদের কেউ কেউ নীরবে এটি মোকাবেলা করে, এবং কেউ কেউ ENAMETOOLONগ দেয়; lib ব্যাখ্যা
লাইব্রেরি ব্যবহার করে pathconf(3) _PC_NO_TRUNC যা বলবেন। এই ত্রুটি ঘটলে,
libexplain লাইব্রেরি ত্রুটি বার্তায় সীমাটি বলবে, সীমাটি হল
থেকে প্রাপ্ত pathconf(3) _PC_NAME_MAX। কিভাবে সিস্টেম সীমা অন্তর্ভুক্ত করা হয় লক্ষ্য করুন
ত্রুটি বার্তা.
খুলুন (পথের নাম = "system7/only-had-14-অক্ষর", পতাকা = O_RDONLY) ব্যর্থ হয়েছে, ফাইল
নামটি খুব দীর্ঘ (36, ENAMETOOLONG) কারণ "শুধুমাত্র-14-অক্ষর" উপাদান হল
সিস্টেম সীমার চেয়ে বেশি (14)

খালি পথের নাম
মূল ইউনিক্সে, খালি পাথনামটি বর্তমান ডিরেক্টরিকে উল্লেখ করে।
আজকাল POSIX আদেশ দেয় যে একটি খালি পথনাম সফলভাবে সমাধান করা উচিত নয়।
open(pathname = "", flags = O_RDONLY) ব্যর্থ হয়েছে, এরকম কোন ফাইল বা ডিরেক্টরি নেই (2,
ENOENT) কারণ POSIX আদেশ দেয় যে একটি খালি পথনাম অবশ্যই সমাধান করা যাবে না
সফলভাবে

অনুমতিসমূহ
একটি ফাইলের অনুমতি বিট তিনটি বিটের তিনটি গ্রুপ নিয়ে গঠিত। প্রথম গ্রুপ
তিন ব্যবহার করা হয় যখন কলিং প্রক্রিয়ার কার্যকরী ব্যবহারকারী আইডি এর মালিক আইডির সমান হয়
ফাইল তিনটির দ্বিতীয় গ্রুপটি ব্যবহার করা হয় যখন ফাইলের গ্রুপ আইডি হয় সমান হয়
কলিং প্রক্রিয়ার কার্যকরী গ্রুপ আইডি, বা এর পরিপূরক গ্রুপ আইডিগুলির মধ্যে একটি
কলিং প্রক্রিয়া। যখন কোনটিই ধরে না, তৃতীয় গ্রুপটি ব্যবহার করা হয়।
খুলুন (পথের নাম = "/ Etc / passwd", পতাকা = O_WRONLY) ব্যর্থ হয়েছে, অনুমতি অস্বীকার করা হয়েছে (13,
EACCES) কারণ প্রক্রিয়াটির "passwd" নিয়মিত লেখার অনুমতি নেই
পাথনামে ফাইল "জন্য / etc" ডিরেক্টরি, প্রক্রিয়া কার্যকর UID 1000 "pmiller"
নিয়মিত ফাইল মালিক 0 "রুট" এর সাথে মেলে না তাই মালিকের অনুমতি মোড "rw-"
উপেক্ষা করা হয়, অন্যান্য অনুমতি মোড হল "r--", এবং প্রক্রিয়াটি বিশেষাধিকারপ্রাপ্ত নয়
(DAC_OVERRIDE ক্ষমতা নেই)
এই ব্যাখ্যায় কিছু উল্লেখযোগ্য স্থান দেওয়া হয়েছে, কারণ বেশিরভাগ ব্যবহারকারীই এটি জানেন না
অনুমতি সিস্টেম কিভাবে কাজ করে। বিশেষ করে: মালিক, গোষ্ঠী এবং অন্যান্য
অনুমতি একচেটিয়া, তারা একসাথে "বা" করা হয় না।

স্ট্র্যাং এবং মজাদার সিস্টেম কল করুন

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

এনোমেডিয়াম, না মধ্যম পাওয়া
একটি সিডি অনুলিপি করার কাজটি এই কাগজের শিরোনামের উত্স ছিল।
$ dd if=/dev/cdrom of=fubar.iso
dd: "/dev/cdrom" খোলা হচ্ছে: কোনো মাধ্যম খুঁজে পাওয়া যায়নি
$
লেখক আশ্চর্য হয়েছিলেন কেন তার কম্পিউটার তাকে বলছে যে মানসিক বলে কিছু নেই
মধ্যম. বেশ ব্যতীত যে বিপুল সংখ্যক স্থানীয় ইংরেজি ভাষাভাষী নয়
এমনকি সচেতন যে "মিডিয়া" একটি বহুবচন, একা ছেড়ে দিন যে "মাধ্যম" এর একবচন, স্ট্রিং
দ্বারা ফিরে স্ট্ররর(3) ENOMEDIUM-এর জন্য এতটাই কঠিন যে প্রায় সম্পূর্ণ মুক্ত
বিষয়বস্তু।

কখন খোলা(2) ENOMEDIUM ফেরত দেয় এটা ভালো হবে যদি libexplain লাইব্রেরি একটি প্রসারিত করতে পারে
এই সামান্য, এটা ড্রাইভ ধরনের উপর ভিত্তি করে. উদাহরণ স্বরূপ:
...কারণ ফ্লপি ড্রাইভে কোনো ডিস্ক নেই
... কারণ CD-ROM ড্রাইভে কোনো ডিস্ক নেই
... কারণ টেপ ড্রাইভে কোন টেপ নেই
...কারণ কার্ড রিডারে কোনো মেমরি স্টিক নেই

এবং তাই এটি পাস এসেছিল ...
open(pathname = "/dev/cdrom", flags = O_RDONLY) ব্যর্থ হয়েছে, কোনো মাধ্যম খুঁজে পাওয়া যায়নি (123,
ENOMEDIUM) কারণ CD-ROM ড্রাইভে কোনো ডিস্ক আছে বলে মনে হচ্ছে না
কৌশলটি, যা লেখক আগে অজানা ছিল, সেটি হল ব্যবহার করে ডিভাইসটি খুলতে
O_NONBLOCK পতাকা, যা আপনাকে মাধ্যম ছাড়াই একটি ড্রাইভ খুলতে দেবে৷ তারপর আপনি
ইস্যু ডিভাইস নির্দিষ্ট ioctls(2) অনুরোধ যতক্ষণ না আপনি বুঝতে পারেন যে এটি কী। (না
এটি POSIX হলে নিশ্চিত, তবে এটি BSD এবং Solaris-এও সেভাবে কাজ করে বলে মনে হচ্ছে, অনুযায়ী
দ্য wodim(1) সূত্র।)

প্রেক্ষাপটে "ডিস্ক" এবং "ডিস্ক" এর ভিন্ন ভিন্ন ব্যবহারও নোট করুন। সিডি মান উদ্ভূত
ফ্রান্সে, কিন্তু অন্য সব কিছুর একটি "k" আছে।

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

যখন উপলব্ধ, মিনকোর(2) মেমরি অঞ্চলটি বৈধ কিনা তা জিজ্ঞাসা করতে সিস্টেম কল ব্যবহার করা হয়।
এটি তিনটি ফলাফল ফিরিয়ে দিতে পারে: ম্যাপ করা কিন্তু শারীরিক মেমরিতে নয়, ম্যাপ করা এবং শারীরিকভাবে
মেমরি, এবং ম্যাপ করা হয়নি। একটি পয়েন্টারের বৈধতা পরীক্ষা করার সময়, প্রথম দুটি "হ্যাঁ"
এবং শেষটি হল "না"।

সি স্ট্রিং চেক করা আরও কঠিন, কারণ পয়েন্টার এবং সাইজের পরিবর্তে আমরা শুধুমাত্র
একটি পয়েন্টার আছে আকার নির্ধারণ করতে আমাদের NUL খুঁজে বের করতে হবে, এবং এটি হতে পারে
segfault, catch-22.

এটিকে ঘিরে কাজ করার জন্য, libexplain লাইব্রেরি ব্যবহার করে lstat(2) সিস্টেম কল (একটি পরিচিত সঙ্গে
ভাল দ্বিতীয় যুক্তি) বৈধতার জন্য সি স্ট্রিং পরীক্ষা করতে। একটি ব্যর্থতা ফেরত && errno == EFAULT
একটি "না" এবং অন্য কিছু একটি "হ্যাঁ"। এটি অবশ্যই স্ট্রিংগুলিকে PATH_MAX-এ সীমাবদ্ধ করে৷
অক্ষর, কিন্তু এটি সাধারণত libexplain লাইব্রেরির জন্য একটি সমস্যা নয়, কারণ এটি
প্রায় সবসময় দীর্ঘতম স্ট্রিং এটি সম্পর্কে যত্নশীল.

EMFILE, অত্যধিক অনেক খোলা নথি পত্র
এই ত্রুটিটি ঘটে যখন একটি প্রক্রিয়া ইতিমধ্যেই সর্বাধিক সংখ্যক ফাইল বর্ণনাকারী খোলা থাকে।
যদি প্রকৃত সীমা প্রিন্ট করা হয়, এবং libexplain লাইব্রেরি চেষ্টা করে, আপনি খুলতে পারবেন না
একটি ফাইল / proc এটা কি পড়তে.
open_max = sysconf(_SC_OPEN_MAX);
এই এক তাই কঠিন না, একটি আছে sysconf(3) সীমা প্রাপ্তির উপায়।

ENFILE, অত্যধিক অনেক খোলা নথি পত্র in পদ্ধতি
এই ত্রুটি ঘটে যখন সিস্টেম সীমা খোলা ফাইলের মোট সংখ্যা হয়েছে
পৌঁছেছে এই ক্ষেত্রে কোন হাত নেই sysconf(3) সীমা পাওয়ার উপায়।

আরও গভীরে খনন করলে, কেউ আবিষ্কার করতে পারে যে লিনাক্সে একটি আছে / proc এন্ট্রি আমরা পড়তে পারে
এই মান প্রাপ্ত. ক্যাচ-22: আমরা ফাইল বর্ণনাকারীর বাইরে, তাই আমরা একটি ফাইল খুলতে পারি না
সীমা পড়ুন।

লিনাক্সে এটি পাওয়ার জন্য একটি সিস্টেম কল রয়েছে, তবে এটিতে কোনও [ই] glibc র্যাপার ফাংশন নেই, তাই
আপনাকে এটি খুব সাবধানে করতে হবে:
দীর্ঘ
ব্যাখ্যা_ম্যাক্সফাইল(অকার্যকর)
{
#ifdef __linux__
struct __sysctl_args args;
int32_t ম্যাক্সফাইল;
size_t maxfile_size = আকার(maxfile);
int name[] = { CTL_FS, FS_MAXFILE };
memset(&args, 0, sizeof(struct __sysctl_args));
args.name = নাম;
args.nlen = 2;
args.oldval = &maxfile;
args.oldlenp = &maxfile_size;
যদি (syscall(SYS__sysctl, &args) >= 0)
রিটার্ন ম্যাক্সফাইল;
#endif
রিটার্ন -1;
}
এটি ত্রুটি বার্তায় অন্তর্ভুক্ত করার সীমাকে অনুমতি দেয়, যখন উপলব্ধ থাকে।

EINVAL "অবৈধ যুক্তি" vs ENOSYS "ফাংশন না বাস্তবায়িত"
অসমর্থিত কর্ম (যেমন সিমবলিক লিঙ্ক(2) একটি FAT ফাইল সিস্টেমে) রিপোর্ট করা হয় না
ধারাবাহিকভাবে এক সিস্টেম কল থেকে পরবর্তীতে। এটা EINVAL বা হতে পারে
ENOSYS ফিরে এসেছে।

ফলস্বরূপ, এই ত্রুটির ক্ষেত্রে মনোযোগ দিতে হবে যাতে সেগুলি সঠিক হয়, বিশেষ করে৷
যেহেতু EINVAL এক বা একাধিক সিস্টেম কল আর্গুমেন্টের সমস্যার কথাও উল্লেখ করতে পারে।

বিঃদ্রঃ যে ভুল(3) is না সর্বদা সেট
এমন কিছু সময় আছে যখন কিভাবে এবং কিভাবে তা নির্ধারণ করতে [e]glibc উত্সগুলি পড়তে হবে
যখন কিছু সিস্টেম কলের জন্য ত্রুটিগুলি ফেরত দেওয়া হয়।

feof(২০১১), নথি নম্বর(3)
এটা প্রায়ই অনুমান করা হয় যে এই ফাংশন একটি ত্রুটি ফেরত দিতে পারে না. এই শুধুমাত্র যদি সত্য
দ্য প্রবাহ যুক্তি বৈধ, তবে তারা একটি অবৈধ সনাক্ত করতে সক্ষম
পয়েন্টার

fpathconf(২০১১), pathconf(3)
এর রিটার্ন মান fpathconf(2) এবং pathconf(2) বৈধভাবে -1 হতে পারে, তাই এটি
দেখতে হবে কিনা ভুল(3) স্পষ্টভাবে সেট করা হয়েছে.

ioctls(2)
এর রিটার্ন মান ioctls(2) বৈধভাবে -1 হতে পারে, তাই দেখতে হবে কিনা
ভুল(3) স্পষ্টভাবে সেট করা হয়েছে.

readdir(3)
এর রিটার্ন মান readdir(3) উভয় ত্রুটি এবং ফাইলের শেষের জন্য NULL। এটাই
দেখতে হবে কিনা ভুল(3) স্পষ্টভাবে সেট করা হয়েছে.

সেটবাফ(২০১১), সেটবাফার(২০১১), সেটলাইনবাফ(২০১১), setvbuf(3)
এই ফাংশন শেষ ছাড়া সব অকার্যকর ফিরে. এবং setvbuf(3) শুধুমাত্র হিসাবে নথিভুক্ত করা হয়
ত্রুটিতে "অ-শূন্য" ফেরত দেওয়া হচ্ছে। কিনা তা দেখা দরকার ভুল(3) স্পষ্টভাবে করা হয়েছে
সেট।

স্ট্রটোড(২০১১), strtol(২০১১), strtold(২০১১), স্ট্রোল(২০১১), strtoul(২০১১), স্ট্রটউল(3)
এই ফাংশনগুলি ত্রুটিতে 0 প্রদান করে, তবে এটি একটি বৈধ রিটার্ন মানও। এটাই
দেখতে হবে কিনা ভুল(3) স্পষ্টভাবে সেট করা হয়েছে.

ungetc(3)
যদিও ANSI C স্ট্যান্ডার্ড দ্বারা ব্যাকআপের শুধুমাত্র একটি একক অক্ষর বাধ্যতামূলক করা হয়, এটি মোড় নেয়
আউট যে [e]glibc আরো অনুমতি দেয়... কিন্তু তার মানে এটি ENOMEM এর সাথে ব্যর্থ হতে পারে। এটা হতে পারে
এছাড়াও যদি EBADF এর সাথে ব্যর্থ হয় fp জাল সবচেয়ে কঠিন, যদি আপনি EOF পাস করেন একটি ত্রুটি
প্রত্যাবর্তন ঘটে, কিন্তু ত্রুটি সেট করা হয় না।

libexplain লাইব্রেরি সঠিকভাবে এই সমস্ত ত্রুটি সনাক্ত করে, এমনকি এমন ক্ষেত্রেও যেখানে
ত্রুটি মান খারাপভাবে নথিভুক্ত করা হয়, যদি সব.

ENOSPC, না স্থান বাম on যন্ত্র
যখন এই ত্রুটিটি একটি ফাইল সিস্টেমের একটি ফাইলকে বোঝায়, তখন libexplain লাইব্রেরি মাউন্টটি প্রিন্ট করে
সমস্যা সহ ফাইল সিস্টেমের পয়েন্ট। এই ত্রুটির উৎস অনেক করতে পারেন
পরিষ্কার।
লিখুন(fildes = 1 "উদাহরণ", data = 0xbfff2340, data_size = 5) ব্যর্থ হয়েছে, কোনো স্থান অবশিষ্ট নেই
ডিভাইসে (28, ENOSPC) কারণ ফাইল সিস্টেমে ফাইলগুলি রয়েছে ("/ হোম") নাই
ডেটার জন্য আরও জায়গা
যেহেতু আরও বিশেষ ডিভাইস সমর্থন যোগ করা হয়েছে, ত্রুটি বার্তাগুলি ডিভাইসটি অন্তর্ভুক্ত করবে বলে আশা করা হচ্ছে
নাম এবং ডিভাইসের প্রকৃত আকার।

EROFS, শুধুমাত্র পাঠযোগ্য ফাইল পদ্ধতি
যখন এই ত্রুটিটি একটি ফাইল সিস্টেমের একটি ফাইলকে বোঝায়, তখন libexplain লাইব্রেরি মাউন্টটি প্রিন্ট করে
সমস্যা সহ ফাইল সিস্টেমের পয়েন্ট। এই ত্রুটির উৎস অনেক করতে পারেন
পরিষ্কার।

যেহেতু আরও বিশেষ ডিভাইস সমর্থন যোগ করা হয়েছে, ত্রুটি বার্তাগুলি ডিভাইসটি অন্তর্ভুক্ত করবে বলে আশা করা হচ্ছে
নাম এবং প্রকার।
open(pathname = "/dev/fd0", O_RDWR, 0666) ব্যর্থ হয়েছে, শুধুমাত্র পঠনযোগ্য ফাইল সিস্টেম (30, EROFS)
কারণ ফ্লপি ডিস্কে রাইট সুরক্ষা ট্যাব সেট আছে

...কারণ একটি CD-ROM লেখার যোগ্য নয়
...কারণ মেমরি কার্ডে রাইট সুরক্ষা ট্যাব সেট আছে
...কারণ ½ ইঞ্চি ম্যাগনেটিক টেপে লেখার রিং নেই

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

তবে সীমাবদ্ধতা রয়েছে: আপনি শুধুমাত্র অন্য একটি ডিরেক্টরির উপরে একটি ডিরেক্টরির নাম পরিবর্তন করতে পারেন
ডিরেক্টরি যদি গন্তব্য ডিরেক্টরি খালি না থাকে।
পুনঃনামকরণ(oldpath = "foo", newpath = "bar") ব্যর্থ হয়েছে, ডিরেক্টরি খালি নয় (39,
ENOTEMPTY) কারণ newpath একটি খালি ডিরেক্টরি নয়; অর্থাৎ, এতে এন্ট্রি রয়েছে
আর অন্যান্য "." এবং ".."
আপনি একটি নন-ডিরেক্টরির উপরে একটি ডিরেক্টরির নাম পরিবর্তন করতে পারবেন না।
পুনঃনামকরণ(oldpath = "foo", newpath = "bar") ব্যর্থ হয়েছে, একটি ডিরেক্টরি নয় (20, ENOTDIR)
কারণ oldpath একটি ডিরেক্টরি, কিন্তু newpath একটি নিয়মিত ফাইল, একটি ডিরেক্টরি নয়
বা বিপরীত অনুমোদিত
পুনঃনামকরণ(oldpath = "foo", newpath = "bar") ব্যর্থ হয়েছে, এটি একটি ডিরেক্টরি (21, EISDIR)
কারণ newpath একটি ডিরেক্টরি, কিন্তু oldpath একটি নিয়মিত ফাইল, একটি ডিরেক্টরি নয়

এটি অবশ্যই libexplain লাইব্রেরির কাজকে আরও জটিল করে তোলে, কারণ
লিঙ্কমুক্ত(এক্সএনএমএক্স) বা কাছে rmdir(2) সিস্টেম কল দ্বারা অন্তর্নিহিতভাবে বলা হয় নামান্তর(2), এবং তাই সব
লিঙ্কমুক্ত(এক্সএনএমএক্স) বা কাছে rmdir(2) ত্রুটি সনাক্ত এবং পরিচালনা করা আবশ্যক, পাশাপাশি.

dup2
সার্জারির dup2(2) সিস্টেম কল একটি দ্বিতীয় ফাইল বর্ণনাকারী তৈরি করতে ব্যবহৃত হয় যা রেফারেন্স করে
প্রথম ফাইল বর্ণনাকারী হিসাবে একই বস্তু। সাধারণত এটি শেল ইনপুট বাস্তবায়ন করতে ব্যবহৃত হয়
এবং আউটপুট পুনর্নির্দেশ।

মজার ব্যাপার হলো, ঠিক যেমন নামান্তর(2) পারমাণবিকভাবে একটি ফাইলের উপরে নাম পরিবর্তন করতে পারে
বিদ্যমান ফাইল এবং পুরানো ফাইল সরান, dup2(2) এটি ইতিমধ্যেই খোলা ফাইলে করতে পারে
বর্ণনাকারী।

আবার, এটি libexplain লাইব্রেরির কাজকে আরও জটিল করে তোলে, কারণ ঘনিষ্ঠ(2)
সিস্টেম কল দ্বারা অন্তর্নিহিতভাবে বলা হয় dup2(2), এবং তাই সব ঘনিষ্ঠ(2) এর ত্রুটি হতে হবে
সনাক্ত করা এবং পরিচালনা করা, পাশাপাশি.

অ্যাডভেঞ্চারস IN আইওসিটিএল সাপোর্ট

সার্জারির ioctls(2) সিস্টেম কল ডিভাইস ড্রাইভার লেখকদের সাথে যোগাযোগ করার একটি উপায় প্রদান করে
ইউজার-স্পেস যা বিদ্যমান কার্নেল API-এর মধ্যে মাপসই করে না। দেখা ioctl_list(2).

পাঠোদ্ধারতা অনুরোধ নাম্বার
একটি সারসংক্ষেপ থেকে দেখুন ioctls(2) ইন্টারফেস, একটি বড় কিন্তু সসীম হতে প্রদর্শিত হবে
সম্ভাব্য সংখ্যা ioctls(2) অনুরোধ। প্রতিটি ভিন্ন ioctls(2) অনুরোধ কার্যকরভাবে
অন্য সিস্টেম কল, কিন্তু কোনো প্রকার-নিরাপত্তা ছাড়াই - কম্পাইলার সাহায্য করতে পারে না
প্রোগ্রামার এই অধিকার পেতে. এর পেছনে সম্ভবত এটাই ছিল প্রেরণা tcflush(3) এবং
বন্ধুদের।

প্রাথমিক ধারণা হল যে আপনি ডিকোড করতে পারেন ioctls(2) একটি বিশাল সুইচ ব্যবহার করে অনুরোধ
বিবৃতি এটি অসম্ভাব্য হতে দেখা যাচ্ছে কারণ একজন খুব দ্রুত আবিষ্কার করে যে এটি
সমস্ত প্রয়োজনীয় সিস্টেম হেডার অন্তর্ভুক্ত করা অসম্ভব যা বিভিন্ন সংজ্ঞায়িত করে ioctls(2)
অনুরোধ, কারণ তাদের একে অপরের সাথে সুন্দরভাবে খেলতে অসুবিধা হয়।

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

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

বাস্তবায়ন ioctls(2) libexplain লাইব্রেরির মধ্যে সাপোর্ট এর একটি টেবিল আছে
নির্দেশক ioctls(2) বর্ণনাকারীদের অনুরোধ করুন। এই বর্ণনাকারীর প্রতিটি একটি ঐচ্ছিক অন্তর্ভুক্ত
একটি দ্ব্যর্থতা নিরসন ফাংশন নির্দেশক.

প্রতিটি অনুরোধ আসলে একটি পৃথক উৎস ফাইলে বাস্তবায়িত হয়, যাতে প্রয়োজনীয়
অন্তর্ভুক্ত ফাইলগুলি অন্যদের সাথে সুন্দরভাবে খেলার বাধ্যবাধকতা থেকে মুক্তি পায়।

প্রতিনিধিত্ব
libexplain লাইব্রেরির পিছনে দর্শন যতটা তথ্য প্রদান করা হয়
সম্ভব, সিস্টেম কলের একটি সঠিক উপস্থাপনা সহ। এর ব্যাপারে
ioctls(2) এর অর্থ সঠিক অনুরোধ নম্বর (নাম দ্বারা) এবং একটি সঠিক (বা
অন্তত দরকারী) তৃতীয় আর্গুমেন্টের উপস্থাপনা।

সার্জারির ioctls(2) প্রোটোটাইপ এই মত দেখায়:
int ioctl(int fildes, int অনুরোধ, ...);
যা আপনার টাইপ-সেফটি অ্যালার্ম বন্ধ করা উচিত। [e]glibc-এর অভ্যন্তরীণ, এটি পরিণত হয়েছে
বিভিন্ন আকারে:
int __ioctl(int fildes, int request, long arg);
int __ioctl(int fildes, int অনুরোধ, void *arg);
এবং লিনাক্স কার্নেল সিস্কল ইন্টারফেস আশা করে
asmlinkage লং sys_ioctl(অস্বাক্ষরিত int ফিল্ডস, স্বাক্ষরবিহীন int অনুরোধ, স্বাক্ষরবিহীন দীর্ঘ
arg);
তৃতীয় যুক্তির চরম পরিবর্তনশীলতা একটি চ্যালেঞ্জ, যখন libexplain লাইব্রেরি
যে তৃতীয় যুক্তি একটি উপস্থাপনা মুদ্রণ করার চেষ্টা করে. তবে একবার অনুরোধ নম্বর
দ্ব্যর্থহীন করা হয়েছে, libexplain লাইব্রেরির ioctl টেবিলের প্রতিটি এন্ট্রিতে একটি আছে
কাস্টম প্রিন্ট_ডেটা ফাংশন (ওও ম্যানুয়ালি করা হয়েছে)।

ব্যাখ্যা
ব্যবহার করা ব্যাখ্যা নির্ধারণে কম সমস্যা আছে। একবার অনুরোধ নম্বর
দ্ব্যর্থহীন করা হয়েছে, libexplain লাইব্রেরির ioctl টেবিলের প্রতিটি এন্ট্রির একটি কাস্টম আছে
print_explanation ফাংশন (আবার, OO ম্যানুয়ালি করা হয়েছে)।

সেকশন 2 এবং সেকশন 3 সিস্টেম কলের বিপরীতে, বেশিরভাগ ioctls(2) অনুরোধে কোন ত্রুটি নেই
নথিভুক্ত এর মানে, ভাল ত্রুটির বিবরণ দিতে, কার্নেল পড়তে হবে
আবিষ্কার করার জন্য উৎস

· কি ভুল(3) মান ফেরত দেওয়া যেতে পারে, এবং

· প্রতিটি ত্রুটির কারণ।

কার্নেলের সাথে ফাংশন কল প্রেরণের OO প্রকৃতির কারণে, আপনাকে পড়তে হবে
সব সূত্র যে বাস্তবায়ন ioctls(2) অনুরোধ, শুধুমাত্র সাধারণ বাস্তবায়ন নয়। এটা
আশা করা যায় যে বিভিন্ন কার্নেলের বিভিন্ন ত্রুটি সংখ্যা এবং সূক্ষ্মভাবে থাকবে
বিভিন্ন ত্রুটির কারণ।

EINVAL vs ইনোটি
জন্য পরিস্থিতি আরও খারাপ ioctls(2) সিস্টেম কলের চেয়ে অনুরোধ, EINVAL এবং সহ
ENOTTY উভয়ই ইঙ্গিত করতে ব্যবহৃত হচ্ছে যে একটি ioctls(2) অনুরোধ যে অনুপযুক্ত
প্রসঙ্গ, এবং মাঝে মাঝে ENOSYS, ENOTSUP এবং EOPNOTSUPP (সকেটের জন্য ব্যবহার করা হয়) হিসাবে
আমরা হব. লিনাক্স কার্নেল উত্সগুলিতে মন্তব্য রয়েছে যা একটি প্রগতিশীল নির্দেশ করে বলে মনে হচ্ছে
পরিষ্কার করা হচ্ছে। অতিরিক্ত বিশৃঙ্খলার জন্য, বিএসডি বিভ্রান্তিতে ENOIOCTL যোগ করে।

ফলস্বরূপ, এই ত্রুটির ক্ষেত্রে মনোযোগ দিতে হবে যাতে সেগুলি সঠিক হয়, বিশেষ করে৷
যেহেতু EINVAL এক বা একাধিক সিস্টেম কল আর্গুমেন্টের সমস্যার কথাও উল্লেখ করতে পারে।

intptr_t
C99 স্ট্যান্ডার্ড একটি পূর্ণসংখ্যার ধরণকে সংজ্ঞায়িত করে যা যে কোনো পয়েন্টার ধরে রাখতে সক্ষম হবে
প্রতিনিধিত্ব ক্ষতি ছাড়া।

উপরের ফাংশন syscall প্রোটোটাইপ ভাল লেখা হবে
long sys_ioctl(আনসাইন করা int ফিল্ডস, স্বাক্ষরবিহীন int অনুরোধ, intptr_t arg);
সমস্যাটি হল ডিভাইস-নির্দিষ্ট বা ফাইল-সিস্টেম-নির্দিষ্ট দ্বারা প্রবর্তিত জ্ঞানীয় অসঙ্গতি
ioctls(2) বাস্তবায়ন, যেমন:
long vfs_ioctl(struct file *filp, unsigned int cmd, unsigned long arg);
সংখ্যাগরিষ্ঠ ioctls(2) অনুরোধের আসলে একটি int * arg তৃতীয় আর্গুমেন্ট আছে। কিন্তু এটা থাকার
ঘোষিত লং লিড কোডে এটিকে লং *আর্গ হিসাবে বিবেচনা করে। এটি 32-বিটে নিরীহ
(sizeof(long) == sizeof(int)) কিন্তু 64-বিটে খারাপ (sizeof(long) != sizeof(int))।
অন্তিমতার উপর নির্ভর করে, আপনি যে মান আশা করেন তা আপনি করেন বা পান না, কিন্তু আপনি সর্বদা পাওয়া
একটি মেমরি স্ক্রাইবল বা স্ট্যাক স্ক্রিবল পাশাপাশি।

এই সব হিসাবে লেখা
int ioctl(int fildes, int অনুরোধ, ...);
int __ioctl(int fildes, int অনুরোধ, intptr_t arg);
long sys_ioctl(আনসাইন করা int ফিল্ডস, স্বাক্ষরবিহীন int অনুরোধ, intptr_t arg);
long vfs_ioctl(struct file *filp, unsigned int cmd, intptr_t arg);
জোর দেয় যে পূর্ণসংখ্যা শুধুমাত্র একটি পূর্ণসংখ্যা যা প্রায় একটি পরিমাণের প্রতিনিধিত্ব করে
সর্বদা একটি সম্পর্কহীন পয়েন্টার টাইপ।

উপসংহার

libexplain ব্যবহার করুন, আপনার ব্যবহারকারীরা এটি পছন্দ করবে।

কপিরাইট

libexplain সংস্করণ 1.4
কপিরাইট (সি) 2008, 2009, 2010, 2011, 2012, 2013, 2014 পিটার মিলার

onworks.net পরিষেবা ব্যবহার করে ব্যাখ্যা_lca2010 অনলাইন ব্যবহার করুন