.\" -*- coding: UTF-8 -*- .\" Copyright 1992, Drew Eckhardt .\" Copyright 1993-1995, Ian Jackson .\" 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 rename 2 "8 فبراير 2026" "صفحات دليل لينكس 6.18" .SH الاسم rename, renameat, renameat2 \- تغيير اسم أو موقع ملف .SH المكتبة مكتبة سي المعيارية (\fIlibc\fP،\ \fI\-lc\fP) .SH موجز .nf \fB#include \fP .P \fBint rename(const char *\fP\fIoldpath\fP\fB, const char *\fP\fInewpath\fP\fB);\fP .P \fB#include \fP/* Definition of \fBAT_*\fP constants */ \fB#include \fP .P \fBint renameat(int \fP\fIolddirfd\fP\fB, const char *\fP\fIoldpath\fP\fB,\fP \fB int \fP\fInewdirfd\fP\fB, const char *\fP\fInewpath\fP\fB);\fP \fBint renameat2(int \fP\fIolddirfd\fP\fB, const char *\fP\fIoldpath\fP\fB,\fP \fB int \fP\fInewdirfd\fP\fB, const char *\fP\fInewpath\fP\fB, unsigned int \fP\fIflags\fP\fB);\fP .fi .P .RS -4 متطلبات ماكروات اختبار الميزات لـ glibc (انظر \fBfeature_test_macros\fP(7)): .RE .P .nf \fBrenameat\fP(): Since glibc 2.10: _POSIX_C_SOURCE >= 200809L Before glibc 2.10: _ATFILE_SOURCE .P \fBrenameat2\fP(): _GNU_SOURCE .fi .SH الوصف \fBrename\fP() يعيد تسمية ملف، وينقله بين الدلائل إذا لزم الأمر. أي روابط صلبة أخرى للملف (كما أُنشئت باستخدام \fBlink\fP(2)) لا تتأثر. واصفات الملفات المفتوحة لـ \fIoldpath\fP لا تتأثر أيضًا. .P قيود مختلفة تحدد نجاح عملية إعادة التسمية من عدمه: انظر الأخطاء أدناه. .P إذا كان \fInewpath\fP موجودًا بالفعل، يُستبدل آليًا، بحيث لا توجد نقطة يجد فيها أي عملية أخرى تحاول الوصول إلى \fInewpath\fP أنه مفقود. ومع ذلك، سيكون هناك على الأرجح نافذة يشير فيها كل من \fIoldpath\fP و \fInewpath\fP إلى الملف الذي يُعاد تسميته. .P إذا كان \fIoldpath\fP و \fInewpath\fP رابطين صلبيين موجودين يشيران إلى نفس الملف، فإن \fBrename\fP() لا يفعل شيئًا، ويعيد حالة نجاح. .P إذا كان \fInewpath\fP موجودًا لكن العملية فشلت لسبب ما، يضمن \fBrename\fP() ترك نسخة من \fInewpath\fP في مكانها. .P يمكن أن يحدد \fIoldpath\fP دليلًا. في هذه الحالة، يجب أن يكون \fInewpath\fP إما غير موجود، أو يجب أن يحدد دليلًا فارغًا. .P إذا كان \fIoldpath\fP يشير إلى رابط رمزي، يُعاد تسمية الرابط؛ إذا كان \fInewpath\fP يشير إلى رابط رمزي، يُستبدل الرابط. .SS renameat() تعمل استدعاء النظام \fBrenameat\fP() بنفس طريقة \fBrename\fP()، باستثناء الاختلافات الموصوفة هنا. .P إذا كان اسم المسار المعطى في \fIoldpath\fP نسبيًا، فإنه يُفسر بالنسبة للدليل المشار إليه بواسطة واصف الملف \fIolddirfd\fP (بدلاً من كونه نسبيًا لدليل العمل الحالي للعملية المستدعية، كما يفعل \fBrename\fP() لاسم مسار نسبي). .P إذا كان \fIoldpath\fP نسبيًا و \fIolddirfd\fP هو القيمة الخاصة \fBAT_FDCWD\fP، فإن \fIoldpath\fP يُفسر بالنسبة لدليل العمل الحالي للعملية المستدعية (مثل \fBrename\fP()). .P إذا كان \fIoldpath\fP مطلقا، يُتجاهل \fIolddirfd\fP. .P تفسير \fInewpath\fP هو نفسه بالنسبة لـ \fIoldpath\fP، باستثناء أن مسار الملف النسبي يُفسر بالنسبة للدليل الذي يشير إليه واصف الملف \fInewdirfd\fP. .P انظر \fBopenat\fP(2) لشرح الحاجة إلى \fBrenameat\fP(). .SS renameat2() لدى \fBrenameat2\fP() وسيط \fIflags\fP إضافي. استدعاء \fBrenameat2\fP() مع وسيط \fIflags\fP صفري يعادل \fBrenameat\fP(). .P وسيط \fIflags\fP هو قناع بتات يتكون من صفر أو أكثر من الأعلام التالية: .TP \fBRENAME_EXCHANGE\fP يتبادل \fIoldpath\fP و \fInewpath\fP آليًا. يجب أن يكون كلا اسمي المسار موجودين لكن قد يكونان من أنواع مختلفة (مثلًا، قد يكون أحدهما دليلًا غير فارغ والآخر رابطًا رمزيًا). .TP \fBRENAME_NOREPLACE\fP لا يُستبدل \fInewpath\fP في إعادة التسمية. يُعيد خطأ إذا كان \fInewpath\fP موجودًا بالفعل. .IP لا يمكن استخدام \fBRENAME_NOREPLACE\fP مع \fBRENAME_EXCHANGE\fP. .IP يتطلب \fBRENAME_NOREPLACE\fP دعمًا من نظام الملفات الأساسي. أُضيف الدعم لأنظمة الملفات المختلفة كما يلي: .RS .IP \[bu] 3 .\" ext4: commit 0a7c3937a1f23f8cb5fc77ae01661e9968a51d0c ext4 (لينكس 3.15); .IP \[bu] btrfs, tmpfs, و cifs (لينكس 3.17); .IP \[bu] .\" btrfs: commit 80ace85c915d0f41016f82917218997b72431258 .\" tmpfs: commit 3b69ff51d087d265aa4af3a532fc4f20bf33e718 .\" cifs: commit 7c33d5972ce382bcc506d16235f1e9b7d22cbef8 .\" .\" gfs2 in Linux 4.2? xfs (لينكس 4.0)؛ .IP \[bu] .\" Also affs, bfs, exofs, hfs, hfsplus, jffs2, logfs, msdos, .\" nilfs2, omfs, sysvfs, ubifs, udf, ufs .\" hugetlbfs, ramfs .\" local filesystems: commit f03b8ad8d38634d13e802165cc15917481b47835 .\" libfs: commit e0e0be8a835520e2f7c89f214dfda570922a1b90 دعم العديد من أنظمة الملفات الأخرى أُضيف في لينكس 4.9، بما في ذلك ext2 و minix و reiserfs و jfs و vfat و bpf. .RE .TP \fBRENAME_WHITEOUT\fP (منذ لينكس 3.18) .\" commit 0d7a855526dd672e114aff2ac22b60fc6f155b08 .\" commit 787fb6bc9682ec7c05fb5d9561b57100fbc1cc41 هذه العملية منطقية فقط لتطبيقات أنظمة الملفات التراكبية/الاتحادية. .IP تحديد \fBRENAME_WHITEOUT\fP ينشئ كائن "whiteout" في مصدر إعادة التسمية في نفس وقت تنفيذ إعادة التسمية. العملية بأكملها ذرية، بحيث إذا نجحت إعادة التسمية فإن whiteout سيكون قد أُنشئ أيضًا. .IP "whiteout" هو كائن له معنى خاص في بنى أنظمة الملفات الاتحادية/التراكبية. في هذه البنى، توجد طبقات متعددة ويتم تعديل الطبقة العليا فقط. whiteout على طبقة عليا سيخفي فعليًا ملفًا مطابقًا في الطبقة السفلى، مما يجعله يبدو وكأن الملف غير موجود. .IP عند إعادة تسمية ملف موجود على الطبقة السفلى، يُنسخ الملف أولاً للأعلى (إذا لم يكن موجودًا بالفعل على الطبقة العليا) ثم يُعاد تسميته على الطبقة العليا القابلة للقراءة والكتابة. في نفس الوقت، يحتاج الملف المصدر إلى أن يكون "whiteouted" (بحيث تصبح نسخة الملف المصدر في الطبقة السفلى غير مرئية). العملية بأكملها تحتاج إلى أن تُنجز ذريًا. .IP .\" https://www.freebsd.org/cgi/man.cgi?query=mount_unionfs&manpath=FreeBSD+11.0-RELEASE عندما لا يكون جزءًا من اتحاد/تراكب، يظهر whiteout كجهاز حرفي برقم جهاز {0,0}. (لاحظ أن تطبيقات اتحاد/تراكب أخرى قد تستخدم طرقًا مختلفة لتخزين إدخالات whiteout؛ على وجه التحديد، يستخدم BSD union mount نوع inode منفصل، \fBDT_WHT\fP، والذي، على الرغم من دعمه من قبل بعض أنظمة الملفات المتاحة في لينكس، مثل CODA و XFS، يتم تجاهله بواسطة كود دعم whiteout للنواة، اعتبارًا من لينكس 4.19 على الأقل.) .IP \fBRENAME_WHITEOUT\fP يتطلب نفس الامتيازات مثل إنشاء عقدة جهاز (أي إمكانية \fBCAP_MKNOD\fP). .IP \fBRENAME_WHITEOUT\fP لا يمكن استخدامه مع \fBRENAME_EXCHANGE\fP. .IP .\" tmpfs: commit 46fdb794e3f52ef18b859ebc92f0a9d7db21c5df .\" ext4: commit cd808deced431b66b5fa4e5c193cb7ec0059eaff .\" XFS: commit 7dcf5c3e4527cfa2807567b00387cf2ed5e07f00 .\" f2fs: commit 7e01e7ad746bc8198a8b46163ddc73a1c7d22339 .\" btrfs: commit cdd1fedf8261cd7a73c0596298902ff4f0f04492 .\" ubifs: commit 9e0a1fff8db56eaaebb74b4a3ef65f86811c4798 \fBRENAME_WHITEOUT\fP يتطلب دعمًا من نظام الملفات الأساسي. من بين أنظمة الملفات التي تدعمه tmpfs (منذ لينكس 3.18)، و ext4 (منذ لينكس 3.18)، و XFS (منذ لينكس 4.1)، و f2fs (منذ لينكس 4.2)، و btrfs (منذ لينكس 4.7)، و ubifs (منذ لينكس 4.9). .SH "قيمة الإرجاع" عند النجاح، يُعاد الصفر. وعند حدوث خطأ، يُعاد الرقم \-1، ويُضبط \fIerrno\fP للإشارة إلى الخطأ. .SH الأخطاء .TP \fBEACCES\fP إذن الكتابة مرفوض للدليل الذي يحتوي على \fIoldpath\fP أو \fInewpath\fP، أو إذن البحث مرفوض لأحد الدلائل في بادئة المسار لـ \fIoldpath\fP أو \fInewpath\fP، أو \fIoldpath\fP هو دليل ولا يسمح بإذن الكتابة (مطلوب لتحديث الإدخال \fI..\fP). (انظر أيضًا \fBpath_resolution\fP(7).) .TP \fBEBUSY\fP إعادة التسمية تفشل لأن \fIoldpath\fP أو \fInewpath\fP هو دليل قيد الاستخدام من قبل عملية ما (ربما كدليل عمل حالي، أو كدليل جذر، أو لأنه كان مفتوحًا للقراءة) أو قيد الاستخدام من قبل النظام (على سبيل المثال كنقطة وصل)، بينما يعتبر النظام هذا خطأ. (لاحظ أنه لا يوجد شرط لإرجاع \fBEBUSY\fP في مثل هذه الحالات\[em]لا يوجد خطأ في القيام بإعادة التسمية على أي حال\[em]ولكن يُسمح بإرجاع \fBEBUSY\fP إذا لم يستطع النظام التعامل مع مثل هذه المواقف بطريقة أخرى.) .TP \fBEDQUOT\fP استُنفدت حصة المستخدم من كتل القرص على نظام الملفات. .TP \fBEFAULT\fP يشير \fIoldpath\fP أو \fInewpath\fP إلى خارج مساحة العناوين التي يمكن الوصول إليها. .TP \fBEINVAL\fP اسم المسار الجديد احتوى على بادئة مسار للقديم، أو، بشكل عام، تمت محاولة جعل دليل دليلاً فرعيًا لنفسه. .TP \fBEISDIR\fP \fInewpath\fP هو دليل موجود، لكن \fIoldpath\fP ليس دليلاً. .TP \fBELOOP\fP وُجهت روابط رمزية كثيرة جدًا عند حل \fIoldpath\fP أو \fInewpath\fP. .TP \fBEMLINK\fP \fIoldpath\fP لديه بالفعل الحد الأقصى لعدد الروابط إليه، أو كان دليلاً والدليل الذي يحتوي على \fInewpath\fP لديه الحد الأقصى لعدد الروابط. .TP \fBENAMETOOLONG\fP كان \fIoldpath\fP أو \fInewpath\fP طويلًا جدًا. .TP \fBENOENT\fP الرابط المسمى بـ \fIoldpath\fP غير موجود؛ أو، مكون دليل في \fInewpath\fP غير موجود؛ أو، \fIoldpath\fP أو \fInewpath\fP هو سلسلة فارغة. .TP \fBENOMEM\fP ذاكرة النواة المتوفرة غير كافية. .TP \fBENOSPC\fP الجهاز الذي يحتوي على الملف ليس به مساحة لمدخل الدليل الجديد. .TP \fBENOTDIR\fP مكون يُستخدم كدليل في \fIoldpath\fP أو \fInewpath\fP ليس في الواقع دليلاً. أو، \fIoldpath\fP هو دليل، و \fInewpath\fP موجود لكنه ليس دليلاً. .TP \fBENOTEMPTY\fP أو \fBEEXIST\fP \fInewpath\fP هو دليل غير فارغ، أي يحتوي على إدخالات غير "." و "..". .TP \fBEPERM\fP أو \fBEACCES\fP الدليل الذي يحتوي على \fIoldpath\fP لديه البت اللاصق (\fBS_ISVTX\fP) مضبوطًا ومعرف المستخدم الفعال للعملية ليس معرف المستخدم للملف المراد حذفه ولا معرف المستخدم للدليل الذي يحتويه، والعملية ليست مميزة (لينكس: لا تملك إمكانية \fBCAP_FOWNER\fP)؛ أو \fInewpath\fP هو ملف موجود والدليل الذي يحتويه لديه البت اللاصق مضبوطًا ومعرف المستخدم الفعال للعملية ليس معرف المستخدم للملف المراد استبداله ولا معرف المستخدم للدليل الذي يحتويه، والعملية ليست مميزة (لينكس: لا تملك إمكانية \fBCAP_FOWNER\fP)؛ أو نظام الملفات الذي يحتوي على \fIoldpath\fP لا يدعم إعادة التسمية من النوع المطلوب. .TP \fBEROFS\fP الملف موجود في نظام ملفات للقراءة فقط. .TP \fBEXDEV\fP \fIoldpath\fP و \fInewpath\fP ليسا على نفس نظام الملفات المُوصَل. (لينكس يسمح لنظام ملفات بأن يُوصَل في نقاط متعددة، لكن \fBrename\fP() لا يعمل عبر نقاط وصل مختلفة، حتى لو كان نفس نظام الملفات موصلاً على كليهما.) .P الأخطاء الإضافية التالية يمكن أن تحدث لـ \fBrenameat\fP() و \fBrenameat2\fP(): .TP \fBEBADF\fP \fIoldpath\fP (\fInewpath\fP) نسبي لكن \fIolddirfd\fP (\fInewdirfd\fP) ليس واصف ملف صالحًا. .TP \fBENOTDIR\fP \fIoldpath\fP نسبي و \fIolddirfd\fP واصف ملف يشير إلى ملف غير الدليل؛ أو ما شابه ذلك لـ \fInewpath\fP و \fInewdirfd\fP .P الأخطاء الإضافية التالية يمكن أن تحدث لـ \fBrenameat2\fP(): .TP \fBEEXIST\fP \fIflags\fP يحتوي على \fBRENAME_NOREPLACE\fP و \fInewpath\fP موجود بالفعل. .TP \fBEINVAL\fP عَلَم غير صالح حُدد في \fIflags\fP. .TP \fBEINVAL\fP كل من \fBRENAME_NOREPLACE\fP و \fBRENAME_EXCHANGE\fP حُددا في \fIflags\fP. .TP \fBEINVAL\fP كل من \fBRENAME_WHITEOUT\fP و \fBRENAME_EXCHANGE\fP حُددا في \fIflags\fP. .TP \fBEINVAL\fP نظام الملفات لا يدعم أحد الأعلام في \fIflags\fP. .TP \fBENOENT\fP يحتوي \fIflags\fP على \fBRENAME_EXCHANGE\fP و \fInewpath\fP غير موجود. .TP \fBEPERM\fP تم تحديد \fBRENAME_WHITEOUT\fP في \fIflags\fP، لكن المتصل لا يملك صلاحية \fBCAP_MKNOD\fP. .SH المعايير .TP \fBrename\fP() C11، ‏POSIX.1\-2024. .TP \fBrenameat\fP() POSIX.1\-2024. .TP \fBrenameat2\fP() لينكس. .SH التاريخ .TP \fBrename\fP() C89، POSIX.1\-2001، 4.3BSD. .TP \fBrenameat\fP() POSIX.1\-2008. لينكس 2.6.16،‏ glibc 2.4. .TP \fBrenameat2\fP() لينكس 3.15، glibc 2.28. .SS "ملاحظات glibc" على النوى الأقدم حيث \fBrenameat\fP() غير متوفرة، ترجع دالة الغلاف glibc إلى استخدام \fBrename\fP(). عندما يكون \fIoldpath\fP و \fInewpath\fP مسارات نسبية، تبني glibc المسارات بناءً على الروابط الرمزية في \fI/proc/self/fd\fP التي تتوافق مع وسيطات \fIolddirfd\fP و \fInewdirfd\fP. .SH العلل على أنظمة ملفات NFS، لا يمكنك افتراض أنه إذا فشلت العملية، لم يتم إعادة تسمية الملف. إذا قام الخادم بعملية إعادة التسمية ثم تعطل، فإن RPC المعاد إرساله والذي سيعالج عند عودة الخادم يسبب فشلاً. يُتوقع من التطبيق التعامل مع هذا. انظر \fBlink\fP(2) لمشكلة مماثلة. .SH "انظر أيضًا" \fBmv\fP(1)، \fBrename\fP(1)، \fBchmod\fP(2)، \fBlink\fP(2)، \fBsymlink\fP(2)، \fBunlink\fP(2)، \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 .