.\" -*- coding: UTF-8 -*- .\" Copyright 1992, Drew Eckhardt .\" Copyright 2006-2014, Michael Kerrisk .\" Copyright, the authors of the Linux man-pages project .\" .\" SPDX-License-Identifier: Linux-man-pages-copyleft .\" .\"******************************************************************* .\" .\" This file was generated with po4a. Translate the source file. .\" .\"******************************************************************* .TH open 2 "8 فبراير 2026" "صفحات دليل لينكس 6.18" .SH الاسم open، openat، creat \- فتح ملف وربما إنشاؤه .SH المكتبة مكتبة سي المعيارية (\fIlibc\fP،\ \fI\-lc\fP) .SH موجز .nf \fB#include \fP .P \fBint open(const char *\fP\fIالمسار\fP\fB, int \fP\fIالأعلام\fP\fB, ...\fP \fB \fP\f[R]/*\fB mode_t \fP\fIالوضع\fP\fB \fP\f[R]*/\fB );\fP .P \fBint creat(const char *\fP\fIالمسار\fP\fB, mode_t \fP\fIالوضع\fP\fB);\fP .P \fBint openat(int \fP\fIواصف_دليل\fP\fB, const char *\fP\fIالمسار\fP\fB, int \fP\fIالأعلام\fP\fB, ...\fP \fB \fP\f[R]/*\fB mode_t \fP\fIالوضع\fP\fB \fP\f[R]*/\fB );\fP .P /* وُثقت منفصلة في \fBopenat2\fP(2): \& */ \fBint openat2(int \fP\fIواصف_دليل\fP\fB, const char *\fP\fIالمسار\fP\fB,\fP \fB const struct open_how *\fP\fIالكيفية\fP\fB, size_t \fP\fIالحجم\fP\fB);\fP .fi .P .RS -4 متطلبات ماكروات اختبار الميزات لـ glibc (انظر \fBfeature_test_macros\fP(7)): .RE .P \fBopenat\fP(): .nf منذ glibc 2.10: _POSIX_C_SOURCE >= 200809L قبل glibc 2.10: _ATFILE_SOURCE .fi .SH الوصف يفتح استدعاء النظام \fBopen\fP() الملف المحدد بواسطة \fIالمسار\fP. إذا كان الملف المحدد غير موجود، فيمكن اختيارياً (إذا حُدد \fBO_CREAT\fP في \fIالأعلام\fP) أن يُنشأ بواسطة \fBopen\fP(). .P قيمة الإرجاع لـ \fBopen\fP() هي واصف ملف، وهو عدد صحيح صغير غير سالب يمثل فهرساً لمدخل في جدول واصفات الملفات المفتوحة للعملية. يُستخدم واصف الملف في استدعاءات النظام اللاحقة (\fBread\fP(2)، \fBwrite\fP(2)، \fBlseek\fP(2)، \fBfcntl\fP(2)، إلخ) للإشارة إلى الملف المفتوح. سيكون واصف الملف الذي يعيده استدعاء ناجح هو واصف الملف ذو الرقم الأقل غير المفتوح حالياً للعملية. .P افتراضياً، يُضبط واصف الملف الجديد ليظل مفتوحاً عبر \fBexecve\fP(2) (أي أن علم واصف الملف \fBFD_CLOEXEC\fP الموصوف في \fBfcntl\fP(2) يكون معطلاً في البداية)؛ يمكن استخدام العلم \fBO_CLOEXEC\fP، الموصوف أدناه، لتغيير هذا المبدأ. يُضبط إزاحة الملف على بداية الملف (انظر \fBlseek\fP(2)). .P يؤدي استدعاء \fBopen\fP() إلى إنشاء \fIوصف ملف مفتوح\fP جديد، وهو مدخل في الجدول العام للملفات المفتوحة على مستوى النظام. يسجل وصف الملف المفتوح إزاحة الملف وأعلام حالة الملف (انظر أدناه). واصف الملف هو مرجع لوصف ملف مفتوح؛ ولا يتأثر هذا المرجع إذا حُذف \fIالمسار\fP لاحقًا أو عُدل ليشير إلى ملف مختلف. لمزيد من التفاصيل حول أوصاف الملفات المفتوحة، انظر الملاحظات (NOTES). .P يجب أن يتضمن المعامل \fIالأعلام\fP أحد \fIأوضاع الوصول\fP التالية: \fBO_RDONLY\fP أو \fBO_WRONLY\fP أو \fBO_RDWR\fP. تطلب هذه الأوضاع فتح الملف للقراءة فقط، أو للكتابة فقط، أو للقراءة والكتابة، على التوالي. .P .\" SUSv4 divides the flags into: .\" * Access mode .\" * File creation .\" * File status .\" * Other (O_CLOEXEC, O_DIRECTORY, O_NOFOLLOW) .\" though it's not clear what the difference between "other" and .\" "File creation" flags is. I raised an Aardvark to see if this .\" can be clarified in SUSv4; 10 Oct 2008. .\" http://thread.gmane.org/gmane.comp.standards.posix.austin.general/64/focus=67 .\" TC1 (balloted in 2013), resolved this, so that those three constants .\" are also categorized" as file status flags. .\" بالإضافة إلى ذلك، يمكن إجراء عملية OR بتية لصفر أو أكثر من أعلام إنشاء الملف وأعلام حالة الملف في \fIالأعلام\fP. \fIأعلام إنشاء الملف\fP هي \fBO_CLOEXEC\fP و \fBO_CREAT\fP و \fBO_DIRECTORY\fP و \fBO_EXCL\fP و \fBO_NOCTTY\fP و \fBO_NOFOLLOW\fP و \fBO_TMPFILE\fP و \fBO_TRUNC\fP. \fIأعلام حالة الملف\fP هي جميع الأعلام المتبقية المدرجة أدناه. الفرق بين هاتين المجموعتين من الأعلام هو أن أعلام إنشاء الملف تؤثر على دلالات عملية الفتح نفسها، بينما تؤثر أعلام حالة الملف على دلالات عمليات الإدخال/الإخراج اللاحقة. يمكن استرداد أعلام حالة الملف وتعديلها (في بعض الحالات)؛ انظر \fBfcntl\fP(2) للتفاصيل. .P القائمة الكاملة لأعلام إنشاء الملف وأعلام حالة الملف هي كما يلي: .TP \fBO_APPEND\fP يُفتح الملف في وضع الإلحاق. قبل كل عملية \fBwrite\fP(2)، يتم وضع إزاحة الملف عند نهاية الملف، كما هو الحال مع \fBlseek\fP(2). يتم تنفيذ تعديل إزاحة الملف وعملية الكتابة كخطوة ذرية واحدة. .IP .\" For more background, see .\" http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=453946 .\" http://nfs.sourceforge.net/ قد يؤدي \fBO_APPEND\fP إلى ملفات تالفة على أنظمة ملفات NFS إذا قامت أكثر من عملية بإلحاق بيانات بملف في وقت واحد. هذا لأن NFS لا يدعم الإلحاق بملف، لذا يتعين على نواة العميل محاكاته، وهو ما لا يمكن القيام به دون حالة تسابق. .TP \fBO_ASYNC\fP تمكين الإدخال/الإخراج المدفوع بالإشارات: توليد إشارة (\fBSIGIO\fP افتراضياً، ولكن يمكن تغيير ذلك عبر \fBfcntl\fP(2)) عندما يصبح الإدخال أو الإخراج ممكناً على واصف الملف هذا. هذه الميزة متاحة فقط للأطراف، والأطراف الوهمية، والمقابس، و(منذ لينكس 2.6) الأنابيب و FIFOs. انظر \fBfcntl\fP(2) لمزيد من التفاصيل. انظر أيضًا العلل (BUGS) أدناه. .TP \fBO_CLOEXEC\fP (منذ لينكس 2.6.23) .\" NOTE! several other man pages refer to this text .\" FIXME . for later review when Issue 8 is one day released... .\" POSIX proposes to fix many APIs that provide hidden FDs .\" http://austingroupbugs.net/tag_view_page.php?tag_id=8 .\" http://austingroupbugs.net/view.php?id=368 تمكين علم الغلق\-عند\-التنفيذ (close\-on\-exec) لواصف الملف الجديد. يسمح تحديد هذا العلم للبرنامج بتجنب عمليات \fBfcntl\fP(2) \fBF_SETFD\fP إضافية لضبط علم \fBFD_CLOEXEC\fP. .IP .\" This flag fixes only one form of the race condition; .\" The race can also occur with, for example, file descriptors .\" returned by accept(), pipe(), etc. لاحظ أن استخدام هذا العلم ضروري في بعض البرامج متعددة الخيوط، لأن استخدام عملية \fBfcntl\fP(2) \fBF_SETFD\fP منفصلة لضبط علم \fBFD_CLOEXEC\fP لا يكفي لتجنب حالات التسابق حيث يفتح أحد الخيوط واصف ملف ويحاول ضبط علم الغلق\-عند\-التنفيذ الخاص به باستخدام \fBfcntl\fP(2) في نفس الوقت الذي يقوم فيه خيط آخر بعمل \fBfork\fP(2) بالإضافة إلى \fBexecve\fP(2). اعتماداً على ترتيب التنفيذ، قد يؤدي التسابق إلى تسريب واصف الملف الذي أعاده \fBopen\fP() عن غير قصد إلى البرنامج الذي تنفذه العملية الابن التي أنشأها \fBfork\fP(2). (هذا النوع من التسابق ممكن من حيث المبدأ لأي استدعاء نظام ينشئ واصف ملف يجب ضبط علم الغلق\-عند\-التنفيذ الخاص به، وتوفر العديد من استدعاءات نظام لينكس الأخرى مقابلاً لعلم \fBO_CLOEXEC\fP للتعامل مع هذه المشكلة). .TP \fBO_CREAT\fP إذا كان \fIالمسار\fP غير موجود، فيُنشأ كملف عادي. .IP يُضبط مالك (معرف المستخدم) الملف الجديد على معرف المستخدم الفعلي للعملية. .IP .\" As at Linux 2.6.25, bsdgroups is supported by ext2, ext3, ext4, and .\" XFS (since Linux 2.6.14). يُضبط مالك المجموعة (معرف المجموعة) للملف الجديد إما على معرف المجموعة الفعلي للعملية (دلالات System V) أو على معرف المجموعة للدليل الأب (دلالات BSD). على لينكس، يعتمد السلوك على ما إذا كانت بتة وضع set\-group\-ID مضبوطة على الدليل الأب: إذا كانت تلك البتة مضبوطة، فستُطبق دلالات BSD؛ وإلا فتُطبق دلالات System V. بالنسبة لبعض أنظمة الملفات، يعتمد السلوك أيضًا على خيارات الوصل \fIbsdgroups\fP و \fIsysvgroups\fP الموصوفة في \fBmount\fP(8). .IP يحدد المعامل \fIالوضع\fP بتات وضع الملف التي ستُطبق عند إنشاء ملف جديد. إذا لم يُحدد \fBO_CREAT\fP ولا \fBO_TMPFILE\fP في \fIالأعلام\fP، فيتم تجاهل \fIالوضع\fP (وبالتالي يمكن تحديده كـ 0، أو حذفه ببساطة). \fBيجب\fP توفير المعامل \fIالوضع\fP إذا حُدد \fBO_CREAT\fP أو \fBO_TMPFILE\fP في \fIالأعلام\fP؛ وإذا لم يتم توفيره، فستُطبق بعض البايتات العشوائية من المكدس كوضع للملف. .IP يُعدل الوضع الفعلي بواسطة \fIumask\fP للعملية بالطريقة المعتادة: في حالة عدم وجود ACL مبدئي، يكون وضع الملف المنشأ هو \fI(الوضع\ &\ \[ti]umask)\fP. .IP لاحظ أن \fIالوضع\fP ينطبق فقط على الوصول المستقبلي للملف المنشأ حديثاً؛ قد يعيد استدعاء \fBopen\fP() الذي ينشئ ملفاً للقراءة فقط واصف ملف للقراءة والكتابة. .IP تتوفر الثوابت الرمزية التالية لـ \fIالوضع\fP: .RS .TP 9 \fBS_IRWXU\fP 00700 يمتلك المستخدم (مالك الملف) أذونات القراءة والكتابة والتنفيذ .TP \fBS_IRUSR\fP 00400 يمتلك المستخدم إذن القراءة .TP \fBS_IWUSR\fP 00200 يمتلك المستخدم إذن الكتابة .TP \fBS_IXUSR\fP 00100 يمتلك المستخدم إذن التنفيذ .TP \fBS_IRWXG\fP 00070 تمتلك المجموعة أذونات القراءة والكتابة والتنفيذ .TP \fBS_IRGRP\fP 00040 تمتلك المجموعة إذن القراءة .TP \fBS_IWGRP\fP 00020 تمتلك المجموعة إذن الكتابة .TP \fBS_IXGRP\fP 00010 تمتلك المجموعة إذن التنفيذ .TP \fBS_IRWXO\fP 00007 يمتلك الآخرون أذونات القراءة والكتابة والتنفيذ .TP \fBS_IROTH\fP 00004 يمتلك الآخرون إذن القراءة .TP \fBS_IWOTH\fP 00002 يمتلك الآخرون إذن الكتابة .TP \fBS_IXOTH\fP 00001 يمتلك الآخرون إذن التنفيذ .RE .IP وفقاً لـ POSIX، يكون التأثير عند ضبط بتات أخرى في \fIالوضع\fP غير محدد. على لينكس، تُحترم أيضًا البتات التالية في \fIالوضع\fP: .RS .TP 9 \fBS_ISUID\fP 0004000 بتة set\-user\-ID .TP \fBS_ISGID\fP 0002000 بتة set\-group\-ID (انظر \fBinode\fP(7)). .TP \fBS_ISVTX\fP 0001000 البتة اللاصقة (sticky bit) (انظر \fBinode\fP(7)). .RE .TP \fBO_DIRECT\fP (منذ لينكس 2.4.10) محاولة تقليل آثار الخبيئة للإدخال/الإخراج من وإلى هذا الملف. بشكل عام، سيؤدي ذلك إلى تدهور الأداء، ولكنه مفيد في حالات خاصة، مثل عندما تقوم التطبيقات بعمليات التخبئة الخاصة بها. يتم الإدخال/الإخراج للملف مباشرة من/إلى مخازن مساحة المستخدم. يبذل العلم \fBO_DIRECT\fP بمفرده جهداً لنقل البيانات بشكل متزامن، ولكنه لا يعطي ضمانات العلم \fBO_SYNC\fP بأن البيانات والبيانات الوصفية اللازمة قد نُقلت. لضمان إدخال/إخراج متزامن، يجب استخدام \fBO_SYNC\fP بالإضافة إلى \fBO_DIRECT\fP. انظر الملاحظات (NOTES) أدناه لمزيد من النقاش. .IP وُصفت واجهة مشابهة دلالياً (ولكنها مهجورة) للأجهزة الكتلية في \fBraw\fP(8). .TP \fBO_DIRECTORY\fP .\" But see the following and its replies: .\" http://marc.theaimsgroup.com/?t=112748702800001&r=1&w=2 .\" [PATCH] open: O_DIRECTORY and O_CREAT together should fail .\" O_DIRECTORY | O_CREAT causes O_DIRECTORY to be ignored. إذا لم يكن \fIالمسار\fP دليلاً، فسيؤدي ذلك إلى فشل \fBopen\fP(). أُضيف هذا العلم في لينكس 2.1.126، لتجنب مشاكل الحرمان من الخدمة إذا استُدعي \fBopendir\fP(3) على FIFO أو جهاز شريط. .TP \fBO_DSYNC\fP ستكتمل عمليات الكتابة على الملف وفقاً لمتطلبات اكتمال سلامة \fIبيانات\fP الإدخال/الإخراج المتزامنة. .IP بحلول وقت عودة \fBwrite\fP(2) (وما شابه)، تكون بيانات المخرج قد نُقلت إلى العتاد الأساسي، إلى جانب أي بيانات وصفية للملف قد تكون مطلوبة لاسترداد تلك البيانات (أي كما لو أن كل عملية \fBwrite\fP(2) تبعها استدعاء لـ \fBfdatasync\fP(2)). انظر الإصدارات (VERSIONS). .TP \fBO_EXCL\fP التأكد من أن هذا الاستدعاء ينشئ الملف: إذا حُدد هذا العلم بالاقتران مع \fBO_CREAT\fP، وكان \fIالمسار\fP موجوداً بالفعل، فسيَفشل \fBopen\fP() مع الخطأ \fBEEXIST\fP. .IP .\" POSIX.1-2001 explicitly requires this behavior. عند تحديد هذين العلمين، لا تُتبع الروابط الرمزية: إذا كان \fIالمسار\fP رابطاً رمزياً، فسيَفشل \fBopen\fP() بغض النظر عن المكان الذي يشير إليه الرابط الرمزي. .IP بشكل عام، يكون سلوك \fBO_EXCL\fP غير محدد إذا استُخدم بدون \fBO_CREAT\fP. هناك استثناء واحد: في لينكس 2.6 وما بعده، يمكن استخدام \fBO_EXCL\fP بدون \fBO_CREAT\fP إذا كان \fIالمسار\fP يشير إلى جهاز كتلي. إذا كان الجهاز الكتلي قيد الاستخدام من قبل النظام (مثلاً، موصول)، فسيَفشل \fBopen\fP() مع الخطأ \fBEBUSY\fP. .IP على NFS، يُدعم \fBO_EXCL\fP فقط عند استخدام NFSv3 أو أحدث على نواة 2.6 أو أحدث. في بيئات NFS حيث لا يتوفر دعم \fBO_EXCL\fP، فإن البرامج التي تعتمد عليه لأداء مهام القفل ستحتوي على حالة تسابق. يمكن للبرامج المنقولة التي تريد إجراء قفل ملف ذري باستخدام ملف قفل، وتحتاج إلى تجنب الاعتماد على دعم NFS لـ \fBO_EXCL\fP، أن تنشئ ملفاً فريداً على نفس نظام الملفات (مثلاً، بدمج اسم المضيف ومعرف العملية)، واستخدام \fBlink\fP(2) لعمل رابط لملف القفل. إذا أعاد \fBlink\fP(2) القيمة 0، فقد نجح القفل. وإلا، فاستخدم \fBstat\fP(2) على الملف الفريد للتحقق مما إذا كان عدد روابطه قد زاد إلى 2، وفي هذه الحالة يكون القفل قد نجح أيضًا. .TP \fBO_LARGEFILE\fP (LFS) السماح بفتح الملفات التي لا يمكن تمثيل أحجامها في \fIoff_t\fP (ولكن يمكن تمثيلها في \fIoff64_t\fP). يجب تعريف ماكرو \fB_LARGEFILE64_SOURCE\fP (قبل تضمين \fIأي\fP ملفات ترويسة) للحصول على هذا التعريف. إن ضبط ماكرو اختبار الميزات \fB_FILE_OFFSET_BITS\fP على 64 (بدلاً من استخدام \fBO_LARGEFILE\fP) هو الطريقة المفضلة للوصول إلى الملفات الكبيرة على الأنظمة ذات 32 بت (انظر \fBfeature_test_macros\fP(7)). .TP \fBO_NOATIME\fP (منذ لينكس 2.6.8) عدم تحديث وقت آخر وصول للملف (\fIst_atime\fP في inode) عندما يُقرأ الملف بواسطة \fBread\fP(2). .IP يمكن توظيف هذا العلم فقط إذا تحقق أحد الشروط التالية: .RS .IP \[bu] 3 .\" Strictly speaking: the filesystem UID معرف المستخدم الفعلي للعملية يطابق معرف المستخدم لمالك الملف. .IP \[bu] العملية المستدعِية تمتلك قدرة \fBCAP_FOWNER\fP في فضاء أسماء المستخدم الخاص بها ومعرف المستخدم لمالك الملف لديه تعيين (mapping) في فضاء الأسماء. .RE .IP .\" The O_NOATIME flag also affects the treatment of st_atime .\" by mmap() and readdir(2), MTK, Dec 04. هذا العلم مخصص للاستخدام من قبل برامج الفهرسة أو النسخ الاحتياطي، حيث يمكن لاستخدامه أن يقلل بشكل كبير من مقدار نشاط القرص. قد لا يكون هذا العلم فعالاً على جميع أنظمة الملفات. أحد الأمثلة هو NFS، حيث يحتفظ الخادم بوقت الوصول. .TP \fBO_NOCTTY\fP إذا كان \fIالمسار\fP يشير إلى جهاز طرفي\[em]انظر \fBtty\fP(4)\[em]فلن يصبح الطرفية المتحكمة في العملية حتى لو لم يكن للعملية واحدة. .TP \fBO_NOFOLLOW\fP إذا كان المكون الأخير (أي الاسم الأساسي) لـ \fIالمسار\fP رابطاً رمزياً، فسيَفشل الفتح مع الخطأ \fBELOOP\fP. ستظل الروابط الرمزية في المكونات السابقة لاسم المسار تُتتبع. (لاحظ أن خطأ \fBELOOP\fP الذي يمكن أن يحدث في هذه الحالة لا يمكن تمييزه عن الحالة التي يفشل فيها الفتح لوجود عدد كبير جداً من الروابط الرمزية أثناء حل المكونات في بادئة المسار لاسم المسار). .IP هذا العلم هو امتداد لـ FreeBSD، أُضيف في لينكس 2.1.126، ووُحد لاحقًا في POSIX.1\-2008. .IP .\" The headers from glibc 2.0.100 and later include a .\" definition of this flag; \f[I]kernels before Linux 2.1.126 will ignore it if .\" used\f[]. انظر أيضًا \fBO_PATH\fP أدناه. .TP \fBO_NONBLOCK\fP أو \fBO_NDELAY\fP يُفتح الملف في وضع غير مانع (nonblocking) كلما أمكن ذلك. لن يتسبب استدعاء \fBopen\fP() ولا أي عمليات إدخال/إخراج لاحقة على واصف الملف المعاد في جعل عملية الاستدعاء تنتظر. .IP لاحظ أن ضبط هذه العلامة ليس له أي تأثير على عمل \fBpoll\fP(2) و \fBselect\fP(2) و \fBepoll\fP(7) وما شابهها، بما أن تلك الواجهات تكتفي بإبلاغ \fBالمستدعِي\fP بما إذا كان واصف الملف "جاهزًا"، وهو ما يعني أن عملية إدخال/إخراج تُجرى على واصف الملف مع \fIمسح\fP علامة \fBO_NONBLOCK\fP لن تمنع (block). .IP لاحظ أن هذه العلامة ليس لها أي تأثير على الملفات العادية والأجهزة الكتلية؛ أي أن عمليات الإدخال/الإخراج ستُمنع (لفترة وجيزة) عندما يتطلب الأمر نشاطًا للجهاز، بغض النظر عما إذا كان قد ضُبطت \fBO_NONBLOCK\fP. بما أن دلالات \fBO_NONBLOCK\fP قد تُطبق في نهاية المطاف، فلا ينبغي للتطبيقات أن تعتمد على سلوك المنع عند تحديد هذه العلامة للملفات العادية والأجهزة الكتلية. .IP للتعامل مع الأنابيب المسماة (FIFOs)، انظر أيضًا \fBfifo\fP(7). لمناقشة تأثير \fBO_NONBLOCK\fP بالاقتران مع أقفال الملفات الإلزامية وعقود إيجار الملفات، انظر \fBfcntl\fP(2). .TP \fBO_PATH\fP (منذ لينكس 2.6.39) .\" commit 1abf0c718f15a56a0a435588d1b104c7a37dc9bd .\" commit 326be7b484843988afe57566b627fb7a70beac56 .\" commit 65cfc6722361570bfe255698d9cd4dccaf47570d .\" .\" http://thread.gmane.org/gmane.linux.man/2790/focus=3496 .\" Subject: Re: [PATCH] open(2): document O_PATH .\" Newsgroups: gmane.linux.man, gmane.linux.kernel .\" الحصول على واصف ملف يمكن استخدامه لغرضين: للإشارة إلى موقع في شجرة نظام الملفات، ولإجراء عمليات تعمل فقط على مستوى واصف الملف. لا يُفتح الملف نفسه، وتفشل عمليات الملف الأخرى (مثل \fBread\fP(2) و \fBwrite\fP(2) و \fBfchmod\fP(2) و \fBfchown\fP(2) و \fBfgetxattr\fP(2) و \fBioctl\fP(2) و \fBmmap\fP(2)) بالخطأ \fBEBADF\fP. .IP العمليات التالية \fIيمكن\fP إجراؤها على واصف الملف الناتج: .RS .IP \[bu] 3 \fBclose\fP(2). .IP \[bu] .\" commit 332a2e1244bd08b9e3ecd378028513396a004a24 \fBfchdir\fP(2)، إذا كان واصف الملف يشير إلى دليل (منذ لينكس 3.5). .IP \[bu] \fBfstat\fP(2) (منذ لينكس 3.6). .IP \[bu] .\" fstat(): commit 55815f70147dcfa3ead5738fd56d3574e2e3c1c2 .\" fstatfs(): commit 9d05746e7b16d8565dddbe3200faa1e669d23bbf \fBfstatfs\fP(2) (منذ لينكس 3.12). .IP \[bu] مضاعفة واصف الملف (\fBdup\fP(2)، \fBfcntl\fP(2) \fBF_DUPFD\fP، وما إلى ذلك). .IP \[bu] جلب وضبط علامات واصف الملف (\fBfcntl\fP(2) \fBF_GETFD\fP و \fBF_SETFD\fP). .IP \[bu] استرجاع علامات حالة الملف المفتوح باستخدام عملية \fBfcntl\fP(2) \fBF_GETFL\fP: ستتضمن العلامات المعادة البت \fBO_PATH\fP. .IP \[bu] تمرير واصف الملف كمعامل \fIdirfd\fP لـ \fBopenat\fP() واستدعاءات النظام الأخرى "*at()". يتضمن ذلك \fBlinkat\fP(2) مع \fBAT_EMPTY_PATH\fP (أو عبر procfs باستخدام \fBAT_SYMLINK_FOLLOW\fP) حتى لو لم يكن الملف دليلاً. .IP \[bu] تمرير واصف الملف إلى عملية أخرى عبر مقبس نطاق يونكس (انظر \fBSCM_RIGHTS\fP في \fBunix\fP(7)). .RE .IP عند تحديد \fBO_PATH\fP في \fIflags\fP، تُتجاهل بتات العلامات الأخرى باستثناء \fBO_CLOEXEC\fP و \fBO_DIRECTORY\fP و \fBO_NOFOLLOW\fP. .IP فتح ملف أو دليل باستخدام العلامة \fBO_PATH\fP لا يتطلب أي أذونات على الكائن نفسه (ولكنه يتطلب إذن التنفيذ على الأدلة في بادئة المسار). اعتمادًا على العملية اللاحقة، قد يُجرى فحص لأذونات الملف المناسبة (على سبيل المثال، يتطلب \fBfchdir\fP(2) إذن التنفيذ على الدليل المشار إليه بواسطة معامل واصف الملف الخاص به). في المقابل، يتطلب الحصول على مرجع لكائن نظام ملفات عن طريق فتحه بالعلامة \fBO_RDONLY\fP أن يكون لدى \fBالمستدعِي\fP إذن القراءة على الكائن، حتى عندما لا تتطلب العملية اللاحقة (مثل \fBfchdir\fP(2) و \fBfstat\fP(2)) إذن القراءة على الكائن. .IP إذا كان \fIpath\fP وصلة رمزية وحُددت أيضًا العلامة \fBO_NOFOLLOW\fP، فحينئذٍ يعيد الاستدعاء واصف ملف يشير إلى الوصلة الرمزية. يمكن استخدام واصف الملف هذا كمعامل \fIdirfd\fP في استدعاءات \fBfchownat\fP(2) و \fBfstatat\fP(2) و \fBlinkat\fP(2) و \fBreadlinkat\fP(2) مع مسار فارغ لجعل الاستدعاءات تعمل على الوصلة الرمزية. .IP إذا كان \fIpath\fP يشير إلى نقطة وصل آلي لم تُحفز بعد، بحيث لا يوجد نظام ملفات آخر موصول عليها، فإن الاستدعاء يعيد واصف ملف يشير إلى دليل الوصل الآلي دون تحفيز عملية وصل. يمكن بعد ذلك استخدام \fBfstatfs\fP(2) لتحديد ما إذا كانت في الواقع نقطة وصل آلي غير محفزة (\fB.f_type == AUTOFS_SUPER_MAGIC\fP). .IP أحد استخدامات \fBO_PATH\fP للملفات العادية هو توفير ما يعادل وظيفة \fBO_EXEC\fP في POSIX.1. يسمح لنا ذلك بفتح ملف نملك إذن تنفيذه ولكن ليس لدينا إذن قراءته، ثم تنفيذ ذلك الملف بخطوات تشبه ما يلي: .IP .in +4n .EX char buf[PATH_MAX]; fd = open("some_prog", O_PATH); snprintf(buf, PATH_MAX, "/proc/self/fd/%d", fd); execl(buf, "some_prog", (char *) NULL); .EE .in .IP يمكن أيضًا تمرير واصف ملف \fBO_PATH\fP كمعامل لـ \fBfexecve\fP(3). .TP \fBO_SYNC\fP ستكتمل عمليات الكتابة على الملف وفقًا لمتطلبات إكمال سلامة \fIملف\fP الإدخال/الإخراج المتزامن (على عكس إكمال سلامة \fIبيانات\fP الإدخال/الإخراج المتزامن الذي توفره \fBO_DSYNC\fP.) .IP بحلول وقت عودة \fBwrite\fP(2) (أو ما شابه)، تكون بيانات الإخراج والبيانات الوصفية للملف المرتبطة بها قد نُقلت إلى العتاد الأساسي (أي كما لو أن كل \fBwrite\fP(2) تُبع باستدعاء لـ \fBfsync\fP(2)). انظر VERSIONS. .TP \fBO_TMPFILE\fP (منذ لينكس 3.11) .\" commit 60545d0d4610b02e55f65d141c95b18ccf855b6e .\" commit f4e0c30c191f87851c4a53454abb55ee276f4a7e .\" commit bb458c644a59dbba3a1fe59b27106c5e68e1c4bd إنشاء ملف عادي مؤقت غير مسمى. يحدد معامل \fIpath\fP دليلاً؛ وستُنشأ عقدة فهارس (inode) غير مسماة في نظام ملفات ذلك الدليل. أي شيء يُكتب في الملف الناتج سيُفقد عند إغلاق آخر واصف ملف، ما لم يُعطَ الملف اسمًا. .IP يجب تحديد \fBO_TMPFILE\fP مع أحد \fBO_RDWR\fP أو \fBO_WRONLY\fP و \fBO_EXCL\fP اختياريًا. إذا لم تُحدد \fBO_EXCL\fP، فيمكن استخدام \fBlinkat\fP(2) لربط الملف المؤقت بنظام الملفات، مما يجعله دائمًا، باستخدام كود مثل التالي: .IP .in +4n .EX char path[PATH_MAX]; fd = open("/path/to/dir", O_TMPFILE | O_RDWR, S_IRUSR | S_IWUSR); \& /* إدخال/إخراج ملف على \[aq]fd\[aq]... */ \& linkat(fd, "", AT_FDCWD, "/path/for/file", AT_EMPTY_PATH); \& /* إذا لم يكن لدى المستدعِي إمكانية CAP_DAC_READ_SEARCH (المطلوبة لاستخدام AT_EMPTY_PATH مع linkat(2))، وكان هناك نظام ملفات proc(5) موصول، فيمكن استبدال استدعاء linkat(2) أعلاه بـ: \& snprintf(path, PATH_MAX, "/proc/self/fd/%d", fd); linkat(AT_FDCWD, path, AT_FDCWD, "/path/for/file", AT_SYMLINK_FOLLOW); */ .EE .in .IP في هذه الحالة، يحدد معامل \fBopen\fP() \fImode\fP وضع أذونات الملف، كما هو الحال مع \fBO_CREAT\fP. .IP تحديد \fBO_EXCL\fP بالاقتران مع \fBO_TMPFILE\fP يمنع ربط ملف مؤقت بنظام الملفات بالطريقة المذكورة أعلاه. (لاحظ أن معنى \fBO_EXCL\fP في هذه الحالة يختلف عن معنى \fBO_EXCL\fP في حالات أخرى). .IP .\" Inspired by http://lwn.net/Articles/559147/ هناك حالتا استخدام رئيستان لـ \fBO_TMPFILE\fP: .RS .IP \[bu] 3 وظيفة \fBtmpfile\fP(3) محسنة: إنشاء ملفات مؤقتة خالية من حالات السباق (race\-free) بحيث: (1) تُحذف آليًا عند إغلاقها؛ (2) لا يمكن الوصول إليها أبدًا عبر أي مسار؛ (3) لا تخضع لهجمات الوصلات الرمزية؛ (4) لا تتطلب من \fBالمستدعِي\fP ابتكار أسماء فريدة. .IP \[bu] إنشاء ملف غير مرئي في البداية، ثم ملؤه بالبيانات وتعديله للحصول على سمات نظام ملفات مناسبة (\fBfchown\fP(2) و \fBfchmod\fP(2) و \fBfsetxattr\fP(2) وما إلى ذلك) قبل ربطه ذريًا بنظام الملفات في حالة كاملة التكوين (باستخدام \fBlinkat\fP(2) كما هو موضح أعلاه). .RE .IP .\" To check for support, grep for "tmpfile" in kernel sources .\" commit 99b6436bc29e4f10e4388c27a3e4810191cc4788 .\" commit ab29743117f9f4c22ac44c13c1647fb24fb2bafe .\" commit ef3b9af50bfa6a1f02cd7b3f5124b712b1ba3e3c .\" commit 50732df02eefb39ab414ef655979c2c9b64ad21c يتطلب \fBO_TMPFILE\fP دعمًا من نظام الملفات الأساسي؛ توفر مجموعة فرعية فقط من أنظمة ملفات لينكس ذلك الدعم. في التنفيذ الأولي، وُفر الدعم في أنظمة ملفات ext2 و ext3 و ext4 و UDF و Minix و tmpfs. أُضيف الدعم لأنظمة ملفات أخرى لاحقًا كما يلي: XFS (لينكس 3.15)؛ Btrfs (لينكس 3.16)؛ F2FS (لينكس 3.16)؛ و ubifs (لينكس 4.9) .TP \fBO_TRUNC\fP إذا كان الملف موجودًا بالفعل وكان ملفًا عاديًا وكان وضع الوصول يسمح بالكتابة (أي \fBO_RDWR\fP أو \fBO_WRONLY\fP) فسيُبتر إلى الطول 0. إذا كان الملف عبارة عن FIFO أو ملف جهاز طرفي، فسيُتجاهل العلم \fBO_TRUNC\fP. بخلاف ذلك، يكون تأثير \fBO_TRUNC\fP غير محدد. .SS creat() استدعاء \fBcreat\fP() يعادل استدعاء \fBopen\fP() بـ \fIflags\fP تساوي \fBO_CREAT|O_WRONLY|O_TRUNC\fP. .SS openat() يعمل استدعاء النظام \fBopenat\fP() بنفس طريقة \fBopen\fP() تمامًا، باستثناء الاختلافات الموضحة هنا. .P يُستخدم معامل \fIdirfd\fP بالاقتران مع معامل \fIpath\fP كما يلي: .IP \[bu] 3 إذا كان اسم المسار المعطى في \fIpath\fP مطلقًا، فسيُتجاهل \fIdirfd\fP. .IP \[bu] إذا كان اسم المسار المعطى في \fIpath\fP نسبيًا وكان \fIdirfd\fP هو القيمة الخاصة \fBAT_FDCWD\fP، فسيُفسر \fIpath\fP بالنسبة لدليل العمل الحالي للعملية المستدعية (مثل \fBopen\fP()). .IP \[bu] إذا كان اسم المسار المعطى في \fIpath\fP نسبيًا، فسيُفسر بالنسبة للدليل المشار إليه بواسطة واصف الملف \fIdirfd\fP (بدلاً من تفسيره بالنسبة لدليل العمل الحالي للعملية المستدعية، كما يفعل \fBopen\fP() للمسار النسبي). في هذه الحالة، يجب أن يكون \fIdirfd\fP دليلاً فُتح للقراءة (\fBO_RDONLY\fP) أو باستخدام العلامة \fBO_PATH\fP. .P .\" إذا كان اسم المسار المعطى في \fIpath\fP نسبيًا، ولم يكن \fIdirfd\fP واصف ملف صالحًا، فسينتج خطأ (\fBEBADF\fP). (يمكن استخدام تحديد رقم واصف ملف غير صالح في \fIdirfd\fP كوسيلة لضمان أن \fIpath\fP مطلق). .SS openat2(2) استدعاء النظام \fBopenat2\fP(2) هو امتداد لـ \fBopenat\fP()، ويوفر مجموعة فوقية من ميزات \fBopenat\fP(). وثّق بشكل منفصل في \fBopenat2\fP(2). .SH "قيمة الإرجاع" عند النجاح، تعيد \fBopen\fP() و \fBopenat\fP() و \fBcreat\fP() واصف الملف الجديد (عدد صحيح غير سالب). عند الخطأ، يعاد \-1 وتُضبط \fIerrno\fP للإشارة إلى الخطأ. .SH الأخطاء يمكن أن تفشل \fBopen\fP() و \fBopenat\fP() و \fBcreat\fP() بالأخطاء التالية: .TP \fBEACCES\fP الوصول المطلوب للملف غير مسموح به، أو أُرفض إذن البحث لأحد الأدلة في بادئة مسار \fIpath\fP، أو الملف لم يكن موجودًا بعد والوصول للكتابة إلى الدليل الأب غير مسموح به. (انظر أيضًا \fBpath_resolution\fP(7).) .TP \fBEACCES\fP .\" commit 30aba6656f61ed44cba445a3c0d38b296fa9e8f5 عند تحديد \fBO_CREAT\fP، وتمكين \fIprotected_fifos\fP أو \fIprotected_regular\fP في sysctl، والملف موجود بالفعل وهو FIFO أو ملف عادي، ومالك الملف ليس المستخدم الحالي ولا مالك الدليل المحتوي، والدليل المحتوي قابل للكتابة من قبل العالم أو المجموعة وله سمة الالتصاق (sticky). للتفاصيل، انظر أوصاف \fI/proc/sys/fs/protected_fifos\fP و \fI/proc/sys/fs/protected_regular\fP في \fBproc_sys_fs\fP(5). .TP \fBEBADF\fP (\fBopenat\fP()) المسار \fIpath\fP نسبي ولكن \fIdirfd\fP ليس \fBAT_FDCWD\fP ولا واصف ملف صالحًا. .TP \fBEBUSY\fP حُددت \fBO_EXCL\fP في \fIflags\fP ويشير \fIpath\fP إلى جهاز كتلي قيد الاستخدام من قبل النظام (على سبيل المثال، هو موصول). .TP \fBEDQUOT\fP عند تحديد \fBO_CREAT\fP، والملف غير موجود، وتجاوزت حصة (quota) المستخدم من كتل القرص أو عقد الفهارس (inodes) على نظام الملفات. .TP \fBEEXIST\fP المسار \fIpath\fP موجود بالفعل واستُخدمت \fBO_CREAT\fP و \fBO_EXCL\fP. .TP \fBEFAULT\fP المسار \fIpath\fP يشير إلى خارج مساحة العناوين التي يمكن الوصول إليها. .TP \fBEFBIG\fP انظر \fBEOVERFLOW\fP. .TP \fBEINTR\fP أثناء المنع لانتظار اكتمال فتح جهاز بطيء (مثل FIFO؛ انظر \fBfifo\fP(7))، قاطع الاستدعاء بواسطة معالج إشارة؛ انظر \fBsignal\fP(7). .TP \fBEINVAL\fP نظام الملفات لا يدعم العلامة \fBO_DIRECT\fP. انظر \fBNOTES\fP لمزيد من المعلومات. .TP \fBEINVAL\fP .\" In particular, __O_TMPFILE instead of O_TMPFILE قيمة غير صالحة في \fIflags\fP. .TP \fBEINVAL\fP حُددت \fBO_TMPFILE\fP في \fIflags\fP، ولكن لم يحدد أي من \fBO_WRONLY\fP أو \fBO_RDWR\fP. .TP \fBEINVAL\fP حُدد كل من \fBO_CREAT\fP و \fBO_DIRECTORY\fP في \fIflags\fP، وإصدار نواة لينكس هو 6.4 أو أحدث. (كانت النوى السابقة غير متسقة في هذا المجال، ولا يحدد POSIX هذا السلوك). .TP \fBEINVAL\fP حُددت \fBO_CREAT\fP في \fIflags\fP والمكون الأخير ("basename") لـ \fIpath\fP الملف الجديد غير صالح (على سبيل المثال، يحتوي على محارف غير مسموح بها في نظام الملفات الأساسي). .TP \fBEINVAL\fP المكون الأخير ("basename") لـ \fIpath\fP غير صالح (على سبيل المثال، يحتوي على محارف غير مسموح بها في نظام الملفات الأساسي). .TP \fBEISDIR\fP يشير \fIpath\fP إلى دليل والوصول المطلوب تضمن الكتابة (أي ضُبطت \fBO_WRONLY\fP أو \fBO_RDWR\fP). .TP \fBEISDIR\fP يشير \fIpath\fP إلى دليل موجود، وحُددت \fBO_TMPFILE\fP وأحد \fBO_WRONLY\fP أو \fBO_RDWR\fP في \fIflags\fP، ولكن إصدار النواة هذا لا يوفر وظيفة \fBO_TMPFILE\fP. .TP \fBELOOP\fP وُجد عدد كبير جدًا من الوصلات الرمزية أثناء تحليل \fIpath\fP. .TP \fBELOOP\fP كان \fIpath\fP وصلة رمزية، وحددت \fIflags\fP القيمة \fBO_NOFOLLOW\fP ولكن ليس \fBO_PATH\fP. .TP \fBEMFILE\fP وُصل إلى الحد الأقصى لعدد واصفات الملفات المفتوحة لكل عملية (انظر وصف \fBRLIMIT_NOFILE\fP في \fBgetrlimit\fP(2)). .TP \fBENAMETOOLONG\fP المسار \fIpath\fP كان طويلاً جداً. .TP \fBENFILE\fP وُصل إلى الحد الأقصى لإجمالي عدد الملفات المفتوحة على مستوى النظام. .TP \fBENODEV\fP يشير \fIpath\fP إلى ملف جهاز خاص ولا يوجد جهاز مقابل له. (هذا خطأ في نواة لينكس؛ في هذه الحالة يجب إعادة \fBENXIO\fP). .TP \fBENOENT\fP لم تضبط \fBO_CREAT\fP والملف المسمى غير موجود. .TP \fBENOENT\fP مكون الدليل في \fIpath\fP غير موجود أو أنه وصلة رمزية معلقة. .TP \fBENOENT\fP يشير \fIpath\fP إلى دليل غير موجود، وحُددت \fBO_TMPFILE\fP وأحد \fBO_WRONLY\fP أو \fBO_RDWR\fP في \fIflags\fP، ولكن إصدار النواة هذا لا يوفر وظيفة \fBO_TMPFILE\fP. .TP \fBENOMEM\fP الملف المسمى هو FIFO، ولكن تعذر تخصيص ذاكرة لخبيئة FIFO لأن الحد الأقصى الصارم لكل مستخدم لتخصيص الذاكرة للأنابيب قد وُصل إليه و \fBالمستدعِي\fP لا يملك صلاحيات؛ انظر \fBpipe\fP(7). .TP \fBENOMEM\fP ذاكرة النواة المتوفرة غير كافية. .TP \fBENOSPC\fP كان من المفترض إنشاء \fIpath\fP ولكن الجهاز الذي يحتوي على \fIpath\fP لا يملك مساحة للملف الجديد. .TP \fBENOTDIR\fP أحد المكونات المستخدمة كدليل في \fIpath\fP ليس دليلاً في الواقع، أو حُدد \fBO_DIRECTORY\fP ولم يكن \fIpath\fP دليلاً. .TP \fBENOTDIR\fP (\fBopenat\fP()) يكون \fIpath\fP مساراً نسبياً و \fIdirfd\fP واصف ملف يشير إلى ملف آخر غير الدليل. .TP \fBENXIO\fP عُين \fBO_NONBLOCK\fP | \fBO_WRONLY\fP، والملف المسمى هو FIFO، ولا توجد عملية فتحت FIFO للقراءة. .TP \fBENXIO\fP الملف هو ملف جهاز خاص ولا يوجد جهاز مطابق له. .TP \fBENXIO\fP الملف هو مقبس نطاق UNIX. .TP \fBEOPNOTSUPP\fP نظام ملفات الذي يحتوي على \fIpath\fP لا يدعم \fBO_TMPFILE\fP. .TP \fBEOVERFLOW\fP .\" See http://bugzilla.kernel.org/show_bug.cgi?id=7253 .\" "Open of a large file on 32-bit fails with EFBIG, should be EOVERFLOW" .\" Reported 2006-10-03 يشير \fIpath\fP إلى ملف عادي كبير جداً لدرجة لا يمكن فتحه. السيناريو المعتاد هنا هو أن تطبيقاً جُمّع على منصة 32 بت بدون \fI\-D_FILE_OFFSET_BITS=64\fP حاول فتح ملف يتجاوز حجمه \fI(1<<31)\-1\fP بايت؛ انظر أيضًا \fBO_LARGEFILE\fP أعلاه. هذا هو الخطأ المحدد بواسطة POSIX.1؛ قبل لينكس 2.6.24، كان لينكس يعطي الخطأ \fBEFBIG\fP لهذه الحالة. .TP \fBEPERM\fP .\" Strictly speaking, it's the filesystem UID... (MTK) حُددت الراية \fBO_NOATIME\fP، ولكن معرف المستخدم الفعلي لـ \fBالمستدعِي\fP لم يطابق مالك الملف ولم يكن \fBالمستدعِي\fP ذا صلاحيات. .TP \fBEPERM\fP مُنعت العملية بواسطة ختم ملف؛ انظر \fBfcntl\fP(2). .TP \fBEROFS\fP يشير \fIpath\fP إلى ملف على نظام ملفات للقراءة فقط وطُلب وصول للكتابة. .TP \fBETXTBSY\fP يشير \fIpath\fP إلى صورة تنفيذية تُنفذ حالياً وطُلب وصول للكتابة. .TP \fBETXTBSY\fP يشير \fIpath\fP إلى ملف مُستخدم حالياً كملف تبديل، وحُددت الراية \fBO_TRUNC\fP. .TP \fBETXTBSY\fP يشير \fIpath\fP إلى ملف يُقرأ حالياً بواسطة \fBنواة\fP (مثلاً، لتحميل وحدة/برمجية ثابتة)، وطُلب وصول للكتابة. .TP \fBEWOULDBLOCK\fP حُددت الراية \fBO_NONBLOCK\fP، وكان هناك عقد إيجار غير متوافق للملف (انظر \fBfcntl\fP(2)). .SH الإصدارات .\" Linux 2.0, 2.5: truncate .\" Solaris 5.7, 5.8: truncate .\" Irix 6.5: truncate .\" Tru64 5.1B: truncate .\" HP-UX 11.22: truncate .\" FreeBSD 4.7: truncate يختلف التأثير (غير المحدد) لـ \fBO_RDONLY | O_TRUNC\fP باختلاف التطبيقات. في عديد من الأنظمة، يُقتطع الملف بالفعل. .SS "المدخلات/المخرجات المتزامنة" يحدد خيار "المدخلات/المخرجات المتزامنة" في POSIX.1\-2008 أنواعاً مختلفة من المدخلات/المخرجات المتزامنة، ويحدد رايات \fBopen\fP()‏ \fBO_SYNC\fP و \fBO_DSYNC\fP و \fBO_RSYNC\fP للتحكم في السلوك. وبغض النظر عما إذا كان التطبيق يدعم هذا الخيار، يجب أن يدعم على الأقل استخدام \fBO_SYNC\fP للملفات العادية. .P ينفذ لينكس \fBO_SYNC\fP و \fBO_DSYNC\fP، ولكن ليس \fBO_RSYNC\fP. وبشكل غير دقيق إلى حد ما، تعرّف glibc‏ \fBO_RSYNC\fP لتكون لها نفس قيمة \fBO_SYNC\fP. (عُرّفت \fBO_RSYNC\fP في ملف ترويسة لينكس \fI\fP على HP PA\-RISC، ولكنها غير مستخدمة.) .P يوفر \fBO_SYNC\fP إكمال سلامة \fIملف\fP المدخلات/المخرجات المتزامن، مما يعني أن عمليات الكتابة ستدفع البيانات وجميع البيانات الوصفية المرتبطة بها إلى العتاد الأساسي. يوفر \fBO_DSYNC\fP إكمال سلامة \fIبيانات\fP المدخلات/المخرجات المتزامن، مما يعني أن عمليات الكتابة ستدفع البيانات إلى العتاد الأساسي، ولكنها ستدفع فقط تحديثات البيانات الوصفية المطلوبة للسماح لعملية قراءة لاحقة بالاكتمال بنجاح. يمكن أن يقلل إكمال سلامة البيانات من عدد عمليات القرص المطلوبة للتطبيقات التي لا تحتاج إلى ضمانات إكمال سلامة الملف. .P لفهم الفرق بين نوعي الإكمال، تأمل في قطعتين من البيانات الوصفية للملف: طابع وقت آخر تعديل للملف (\fIst_mtime\fP) وطول الملف. ستعمل جميع عمليات الكتابة على تحديث طابع وقت آخر تعديل للملف، ولكن الكتابات التي تضيف بيانات إلى نهاية الملف فقط هي التي ستغير طول الملف. طابع وقت آخر تعديل ليس مطلوباً لضمان اكتمال القراءة بنجاح، ولكن طول الملف مطلوب. وبذلك، يضمن \fBO_DSYNC\fP فقط دفع تحديثات البيانات الوصفية لطول الملف (بينما سيدفع \fBO_SYNC\fP دائماً أيضًا البيانات الوصفية لطابع وقت آخر تعديل). .P قبل لينكس 2.6.33، نفذ لينكس فقط الراية \fBO_SYNC\fP لـ \fBopen\fP(). ومع ذلك، عند تحديد هذه الراية، كانت معظم أنظمة الملفات توفر فعلياً ما يعادل إكمال سلامة \fIبيانات\fP المدخلات/المخرجات المتزامن (أي أن \fBO_SYNC\fP نُفذت فعلياً بما يعادل \fBO_DSYNC\fP). .P .\" منذ لينكس 2.6.33، دُعم \fBO_SYNC\fP بشكل صحيح. ومع ذلك، لضمان التوافق الثنائي التراجعي، عُرّفت \fBO_DSYNC\fP بنفس قيمة \fBO_SYNC\fP التاريخية، وعُرّفت \fBO_SYNC\fP كقيمة راية جديدة (بتّين) تتضمن قيمة راية \fBO_DSYNC\fP. يضمن هذا حصول التطبيقات التي جُمّعت باستخدام الترويسات الجديدة على الأقل على دلالات \fBO_DSYNC\fP قبل لينكس 2.6.33. .SS "الاختلافات بين مكتبة C والنواة" .\" منذ glibc 2.26، توظف دالة الغلاف glibc لـ \fBopen\fP() استدعاء النظام \fBopenat\fP()، بدلاً من استدعاء النظام \fBopen\fP() الخاص بالنواة. بالنسبة لمعماريات معينة، ينطبق هذا أيضًا قبل glibc 2.26. .SS POSIX يحدد POSIX.1\-2024‏ \fBO_CLOFORK\fP، لكن لينكس لا يدعمه. .SH المعايير .TP \fBopen\fP() .TQ \fBcreat\fP() .TQ \fBopenat\fP() POSIX.1\-2024. .TP \fBopenat2\fP(2) لينكس. .TP \fBO_DIRECT\fP .TQ \fBO_NOATIME\fP .TQ \fBO_PATH\fP .TQ \fBO_TMPFILE\fP لينكس. .SH التاريخ .TP \fBopen\fP() .TQ \fBcreat\fP() SVr4، 4.3BSD، POSIX.1\-2001. .TP \fBopenat\fP() POSIX.1\-2008. لينكس 2.6.16،‏ glibc 2.4. .TP \fBO_CLOEXEC\fP .TQ \fBO_DIRECTORY\fP .TQ \fBO_NOFOLLOW\fP POSIX.1\-2008. .SH ملاحظات تحت نظام لينكس، تُستخدم الراية \fBO_NONBLOCK\fP أحياناً في الحالات التي يُراد فيها الفتح ولكن ليس بالضرورة نية القراءة أو الكتابة. على سبيل المثال، قد يُستخدم هذا لفتح جهاز من أجل الحصول على واصف ملف لاستخدامه مع \fBioctl\fP(2). .P لاحظ أن \fBopen\fP() يمكنه فتح ملفات الأجهزة الخاصة، لكن \fBcreat\fP() لا يمكنه إنشاءها؛ استخدم \fBmknod\fP(2) بدلاً من ذلك. .P إذا أُنشئ الملف حديثاً، تُعين حقول \fIst_atime\fP و \fIst_ctime\fP و \fIst_mtime\fP الخاصة به (على التوالي، وقت آخر وصول، ووقت آخر تغيير للحالة، ووقت آخر تعديل؛ انظر \fBstat\fP(2)) إلى الوقت الحالي، وكذلك حقول \fIst_ctime\fP و \fIst_mtime\fP للدليل الأصل. وإلا، إذا عُدل الملف بسبب الراية \fBO_TRUNC\fP، تُعين حقول \fIst_ctime\fP و \fIst_mtime\fP الخاصة به إلى الوقت الحالي. .P تُظهر الملفات الموجودة في دليل \fI/proc/\fPpid\fI/fd\fP واصفات الملفات المفتوحة للعملية ذات المعرف \fIpid\fP. تُظهر الملفات في دليل \fI/proc/\fPpid\fI/fdinfo\fP معلومات أكثر عن واصفات الملفات هذه. انظر \fBproc\fP(5) لمزيد من التفاصيل حول كلا الدليلين. .P .\" .\" لا يعرف ملف ترويسة لينكس \fB\fP‏ \fBO_ASYNC\fP؛ بل عُرّف المرادف \fBFASYNC\fP (المشتق من BSD) بدلاً منه. .SS "أوصاف الملفات المفتوحة" مصطلح وصف الملف المفتوح هو المصطلح الذي يستخدمه POSIX للإشارة إلى المدخلات في جدول الملفات المفتوحة على مستوى النظام. في سياقات أخرى، يُسمى هذا الكائن أيضًا بأسماء متنوعة مثل "كائن ملف مفتوح"، أو "مقبض ملف"، أو "مدخل جدول ملفات مفتوحة"، أو\[em]بلغة مطوري النواة\[em]‏ \fIstruct file\fP. .P عند مضاعفة واصف ملف (باستخدام \fBdup\fP(2) أو ما شابه)، تشير النسخة المكررة إلى نفس وصف الملف المفتوح الذي يشير إليه واصف الملف الأصلي، وبالتالي يتشارك واصفا الملف في إزاحة الملف ورايات حالة الملف. يمكن أن يحدث هذا التشارك أيضًا بين العمليات: ترث العملية الابنة المنشأة عبر \fBfork\fP(2) نسخاً مكررة من واصفات ملفات والدها، وتشير تلك النسخ إلى نفس أوصاف الملفات المفتوحة. .P كل \fBopen\fP() لملف ينشئ وصف ملف مفتوحاً جديداً؛ وبالتالي، قد يكون هناك عدة أوصاف ملفات مفتوحة تقابل ملفاً واحداً (inode). .P .\" في لينكس، يمكن استخدام عملية \fBKCMP_FILE\fP في \fBkcmp\fP(2) لاختبار ما إذا كان واصفا ملف (في نفس العملية أو في عمليتين مختلفتين) يشيران إلى نفس وصف الملف المفتوح. .SS NFS هناك العديد من العيوب في البروتوكول الأساسي لـ NFS، مما يؤثر من بين أمور أخرى على \fBO_SYNC\fP و \fBO_NDELAY\fP. .P .\" .\" في أنظمة ملفات NFS مع تفعيل تخطيط UID، قد يعيد \fBopen\fP() واصف ملف ولكن، على سبيل المثال، تُرفض طلبات \fBread\fP(2) مع الخطأ \fBEACCES\fP. هذا لأن العميل ينفذ \fBopen\fP() عبر التحقق من الأذونات، ولكن تخطيط UID ينفذه الخادم عند طلبات القراءة والكتابة. .SS FIFOs .\" .\" يؤدي فتح طرف القراءة أو الكتابة لـ FIFO إلى الحظر حتى يُفتح الطرف الآخر أيضًا (بواسطة عملية أو خيط آخر). انظر \fBfifo\fP(7) لمزيد من التفاصيل. .SS "وضع الوصول للملف" على عكس القيم الأخرى التي يمكن تحديدها في \fIflags\fP، فإن قيم \fIaccess mode\fP‏ \fBO_RDONLY\fP و \fBO_WRONLY\fP و \fBO_RDWR\fP لا تحدد بتاتاً فردية. بدلاً من ذلك، فإنها تعرف البتّين الأدنى في \fIflags\fP، وتعرف على التوالي كـ 0 و 1 و 2. بمعنى آخر، الجمع \fBO_RDONLY | O_WRONLY\fP هو خطأ منطقي، وبالتأكيد ليس له نفس معنى \fBO_RDWR\fP. .P .\" See for example util-linux's disk-utils/setfdprm.c .\" For some background on access mode 3, see .\" http://thread.gmane.org/gmane.linux.kernel/653123 .\" "[RFC] correct flags to f_mode conversion in __dentry_open" .\" LKML, 12 Mar 2008 .\" .\" يحتفظ لينكس بوضع الوصول الخاص غير المعياري 3 (ثنائي 11) في \fIflags\fP ليعني: التحقق من إذن القراءة والكتابة على الملف وإعادة واصف ملف لا يمكن استخدامه للقراءة أو الكتابة. يُستخدم وضع الوصول غير المعياري هذا بواسطة بعض برامج قيادة لينكس لإعادة واصف ملف ليُستخدم فقط لعمليات \fBioctl\fP(2) الخاصة بالجهاز. .SS "الأساس المنطقي لـ openat() وواجهات برمجة تطبيقات واصف ملف الدليل الأخرى" تعالج \fBopenat\fP() واستدعاءات النظام الأخرى ودوال المكتبة التي تأخذ وسيط واصف ملف الدليل (مثل \fBexecveat\fP(2) و \fBfaccessat\fP(2) و \fBfanotify_mark\fP(2) و \fBfchmodat\fP(2) و \fBfchownat\fP(2) و \fBfspick\fP(2) و \fBfstatat\fP(2) و \fBfutimesat\fP(2) و \fBlinkat\fP(2) و \fBmkdirat\fP(2) و \fBmknodat\fP(2) و \fBmount_setattr\fP(2) و \fBmove_mount\fP(2) و \fBname_to_handle_at\fP(2) و \fBopen_tree\fP(2) و \fBopenat2\fP(2) و \fBreadlinkat\fP(2) و \fBrenameat\fP(2) و \fBrenameat2\fP(2) و \fBstatx\fP(2) و \fBsymlinkat\fP(2) و \fBunlinkat\fP(2) و \fButimensat\fP(2) و \fBmkfifoat\fP(3) و \fBscandirat\fP(3)) مشكلتين في الواجهات الأقدم التي سبقتها. التفسير هنا بمصطلحات استدعاء \fBopenat\fP()، لكن الأساس المنطقي مماثل للواجهات الأخرى. .P أولاً، تسمح \fBopenat\fP() للتطبيق بتجنب حالات السباق التي قد تحدث عند استخدام \fBopen\fP() لفتح ملفات في أدلة غير دليل العمل الحالي. تنتج حالات السباق هذه عن حقيقة أن بعض مكونات بادئة الدليل المعطاة لـ \fBopen\fP() يمكن تغييرها بالتوازي مع استدعاء \fBopen\fP(). لنفترض، على سبيل المثال، أننا نرغب في إنشاء الملف \fIdir1/dir2/xxx.dep\fP إذا كان الملف \fIdir1/dir2/xxx\fP موجوداً. المشكلة هي أنه بين التحقق من الوجود وخطوة إنشاء الملف، يمكن تعديل \fIdir1\fP أو \fIdir2\fP (والتي قد تكون وصلات رمزية) لتشير إلى موقع مختلف. يمكن تجنب مثل هذه السباقات بفتح واصف ملف للدليل المستهدف، ثم تحديد واصف الملف هذا كوسيط \fIdirfd\fP لـ (مثلاً) \fBfstatat\fP(2) و \fBopenat\fP(). لاستخدام واصف الملف \fIdirfd\fP فوائد أخرى أيضًا: .IP \[bu] 3 واصف الملف هو مرجع مستقر للدليل، حتى لو أُعيدت تسمية الدليل؛ و .IP \[bu] واصف الملف المفتوح يمنع نظام ملفات الأساسي من أن يُفصل، تماماً كما لو كان للعملية دليل عمل حالي على نظام ملفات. .P ثانياً، تسمح \fBopenat\fP() بتنفيذ "دليل عمل حالي" لكل خيط، عبر واصف(ات) ملفات يصونها التطبيق. (يمكن أيضًا الحصول على هذه الوظيفة من خلال حيل تعتمد على استخدام \fI/proc/self/fd/\fPdirfd، ولكن بكفاءة أقل). .P يمكن الحصول على الوسيط \fIdirfd\fP لواجهات برمجة التطبيقات هذه باستخدام \fBopen\fP() أو \fBopenat\fP() لفتح دليل (بإحدى الرايتين \fBO_RDONLY\fP أو \fBO_PATH\fP). بدلاً من ذلك، يمكن الحصول على واصف ملف كهذا بتطبيق \fBdirfd\fP(3) على دفق دليل أُنشئ باستخدام \fBopendir\fP(3). .P .\" .\" عندما تُعطى واجهات برمجة التطبيقات هذه الوسيط \fIdirfd\fP كـ \fBAT_FDCWD\fP أو يكون المسار المحدد مطلقاً، فإنها تتعامل مع وسيط المسار بنفس الطريقة التي تتعامل بها واجهات برمجة التطبيقات التقليدية المقابلة. ومع ذلك، في هذه الحالة، تملك العديد من واجهات برمجة التطبيقات وسيط \fIflags\fP يوفر وصولاً إلى وظائف غير متوفرة في الواجهات التقليدية المقابلة. .SS O_DIRECT قد تفرض الراية \fBO_DIRECT\fP قيود محاذاة على طول وعناوين مخازن مساحة المستخدم وإزاحة الملف للمدخلات/المخرجات. في لينكس تختلف قيود المحاذاة حسب نظام ملفات وإصدار \fBنواة\fP وقد تغيب تماماً. يختلف التعامل مع المدخلات/المخرجات \fBO_DIRECT\fP غير المحاذية أيضًا؛ فيمكن أن تفشل مع \fBEINVAL\fP أو تتراجع إلى المدخلات/المخرجات المخزنة (buffered). .P منذ لينكس 6.1، يمكن الاستعلام عن دعم \fBO_DIRECT\fP وقيود المحاذاة لملف باستخدام \fBstatx\fP(2)، وباستخدام الراية \fBSTATX_DIOALIGN\fP. يختلف دعم \fBSTATX_DIOALIGN\fP حسب نظام ملفات؛ انظر \fBstatx\fP(2). .P توفر بعض أنظمة الملفات واجهات خاصة بها للاستعلام عن قيود محاذاة \fBO_DIRECT\fP، على سبيل المثال عملية \fBXFS_IOC_DIOINFO\fP في \fBxfsctl\fP(3). يجب استخدام \fBSTATX_DIOALIGN\fP بدلاً منها عندما تكون متاحة. .P إذا لم يتوفر أي مما سبق، فلا يمكن افتراض دعم المدخلات/المخرجات المباشرة وقيود المحاذاة إلا من الخصائص المعروفة لـ نظام ملفات، والملف الفردي، وجهاز (أجهزة) التخزين الأساسية، وإصدار النواة. في لينكس 2.4، تتطلب معظم أنظمة الملفات القائمة على أجهزة كتلية أن تكون إزاحة الملف وطول وعنوان الذاكرة لجميع أجزاء المدخلات/المخرجات مضاعفات لحجم كتلة نظام ملفات (عادة 4096 بايت). في لينكس 2.6.0، خُفف هذا إلى حجم الكتلة المنطقية لـ \fBجهاز كتلي\fP (عادة 512 بايت). يمكن تحديد حجم الكتلة المنطقية لـ \fBجهاز كتلي\fP باستخدام عملية \fBioctl\fP(2) \fBBLKSSZGET\fP أو من \fBصدفة\fP باستخدام الأمر: .P .in +4n .EX blockdev \-\-getss .EE .in .P يجب عدم تشغيل مدخلات/مخرجات \fBO_DIRECT\fP بالتزامن مع استدعاء النظام \fBfork\fP(2)، إذا كان مخزن الذاكرة تخطيطاً خاصاً (أي أي تخطيط أُنشئ باستخدام راية \fBmmap\fP(2) \fBMAP_PRIVATE\fP؛ وهذا يشمل الذاكرة المخصصة على الكومة والمخازن المخصصة سكونياً). أي مدخلات/مخرجات كهذه، سواء أُرسلت عبر واجهة مدخلات/مخرجات غير متزامنة أو من خيط آخر في العملية، يجب أن تكتمل قبل استدعاء \fBfork\fP(2). الفشل في القيام بذلك قد يؤدي إلى تلف البيانات وسلوك غير محدد في العمليات الوالدة والابنة. لا ينطبق هذا القيد عندما يكون مخزن الذاكرة لـ مدخلات/مخرجات \fBO_DIRECT\fP قد أُنشئ باستخدام \fBshmat\fP(2) أو \fBmmap\fP(2) مع راية \fBMAP_SHARED\fP. ولا ينطبق هذا القيد أيضًا عندما يُنصح مخزن الذاكرة كـ \fBMADV_DONTFORK\fP باستخدام \fBmadvise\fP(2)، مما يضمن عدم توفره للابن بعد \fBfork\fP(2). .P قُدمت الراية \fBO_DIRECT\fP في SGI IRIX، حيث تملك قيود محاذاة مماثلة لقيود لينكس 2.4. تملك IRIX أيضًا استدعاء \fBfcntl\fP(2) للاستعلام عن المحاذات والأحجام المناسبة. قدم FreeBSD 4.x راية بنفس الاسم، ولكن بدون قيود محاذاة. .P أُضيف دعم \fBO_DIRECT\fP في لينكس 2.4.10. نوى لينكس الأقدم تتجاهل هذه الراية ببساطة. قد لا تنفذ بعض أنظمة الملفات هذه الراية، وفي هذه الحالة يفشل \fBopen\fP() مع الخطأ \fBEINVAL\fP إذا استُخدمت. .P يجب على التطبيقات تجنب خلط \fBO_DIRECT\fP والمدخلات/المخرجات العادية لنفس الملف، وخاصة لمناطق البايتات المتداخلة في نفس الملف. حتى عندما يتعامل نظام ملفات بشكل صحيح مع قضايا التماسك في هذه الحالة، فمن المرجح أن تكون الإنتاجية الإجمالية للمدخلات/المخرجات أبطأ من استخدام أي من الوضعين وحده. وبالمثل، يجب على التطبيقات تجنب خلط \fBmmap\fP(2) للملفات مع المدخلات/المخرجات المباشرة لنفس الملفات. .P سوف يختلف سلوك \fBO_DIRECT\fP مع NFS عن أنظمة الملفات المحلية. قد لا تدعم النوى الأقدم، أو النوى التي ضُبطت بطرق معينة، هذا المزيج. لا يدعم بروتوكول NFS تمرير الراية إلى الخادم، لذا ستتجاوز مدخلات/مخرجات \fBO_DIRECT\fP \fBخبيئة\fP الصفحة في العميل فقط؛ وقد يظل الخادم يخبئ المدخلات/المخرجات. يطلب العميل من الخادم جعل المدخلات/المخرجات متزامنة للحفاظ على الدلالات المتزامنة لـ \fBO_DIRECT\fP. ستعمل بعض الخوادم بشكل سيئ في هذه الظروف، خاصة إذا كان حجم المدخلات/المخرجات صغيراً. قد تُضبط بعض الخوادم أيضًا لتكذب على العملاء بشأن وصول المدخلات/المخرجات إلى وحدة التخزين المستقرة؛ سيؤدي ذلك إلى تجنب عقوبة الأداء مع وجود بعض المخاطر على سلامة البيانات في حالة انقطاع طاقة الخادم. لا يضع عميل Linux NFS أي قيود محاذاة على مدخلات/مخرجات \fBO_DIRECT\fP. .P باختصار، \fBO_DIRECT\fP هي أداة قوية محتملة يجب استخدامها بحذر. يوصى بأن تعامل التطبيقات استخدام \fBO_DIRECT\fP كخيار أداء يكون معطلاً بشكل \fBمبدئي\fP. .SH العلل .\" FIXME . Check bugzilla report on open(O_ASYNC) .\" See http://bugzilla.kernel.org/show_bug.cgi?id=5993 حالياً، لا يمكن تمكين المدخلات/المخرجات المدفوعة بالإشارة عبر تحديد \fBO_ASYNC\fP عند استدعاء \fBopen\fP()؛ استخدم \fBfcntl\fP(2) لتمكين هذه الراية. .P يجب التحقق من رمزي خطأ مختلفين، \fBEISDIR\fP و \fBENOENT\fP، عند محاولة تحديد ما إذا كانت النواة تدعم وظيفة \fBO_TMPFILE\fP. .SH "انظر أيضًا" \fBchmod\fP(2), \fBchown\fP(2), \fBclose\fP(2), \fBdup\fP(2), \fBfcntl\fP(2), \fBlink\fP(2), \fBlseek\fP(2), \fBmknod\fP(2), \fBmmap\fP(2), \fBmount\fP(2), \fBopen_by_handle_at\fP(2), \fBopenat2\fP(2), \fBread\fP(2), \fBsocket\fP(2), \fBstat\fP(2), \fBumask\fP(2), \fBunlink\fP(2), \fBwrite\fP(2), \fBfopen\fP(3), \fBacl\fP(5), \fBfifo\fP(7), \fBinode\fP(7), \fBpath_resolution\fP(7), \fBsymlink\fP(7) .PP .SH ترجمة تُرجمت هذه الصفحة من الدليل بواسطة زايد السعيدي . .PP هذه الترجمة هي وثيقة مجانية؛ راجع .UR https://www.gnu.org/licenses/gpl-3.0.html رخصة جنو العامة الإصدار 3 .UE أو ما بعده للاطلاع على شروط حقوق النشر. لا توجد أي ضمانات. .PP إذا وجدت أي أخطاء في ترجمة صفحة الدليل هذه، يرجى إرسال بريد إلكتروني إلى قائمة بريد المترجمين: .MT kde-l10n-ar@kde.org .ME .