قفل مجلد بروفايل المتصفح: ماذا يحدث إذا فتحه تطبيقان في الوقت نفسه؟

مشكلة تظهر عندما يعمل تطبيقان على بيانات واحدة

قد يفتح المستخدم بروفايل المتصفح من تطبيقين مختلفين، أو من نسختين من التطبيق نفسه، ويظن أن كل نافذة مستقلة. لكن إذا أشارت العمليتان إلى user-data-dir نفسه، فقد تتنافسان على قواعد بيانات الكوكيز وملفات LevelDB والذاكرة المؤقتة وسجلات الجلسات. بعض المحركات ترفض التشغيل بقفل، وبعضها يعيد استخدام عملية قائمة، وقد ينتج سلوك مختلف حسب النظام والإصدار. لا تحكم من شكل النافذتين؛ افحص مسارات التخزين والعمليات التي تملك الملفات.

ابدأ بتحديد طبقات العزل

هناك فرق بين فصل التبويبات داخل عملية واحدة، وفصل جلسات التخزين، وفصل مجلدات البروفايلات، وفصل مستخدمي نظام التشغيل. قد تشترك نافذتان في العملية الرئيسية لكن تستخدمان جلسات مستقلة، وقد تعمل عمليتان منفصلتان على الدليل نفسه خطأ. ارسم خريطة تربط window_id و session_partition و profile_id و storage_path و process_id. هذه الخريطة أهم من عدد النوافذ المفتوحة؛ لأنها تكشف ما إذا كانت هوية البيانات منفصلة فعلًا أو مجرد تسمية مختلفة في الواجهة.

اعرف معنى القفل قبل محاولة تجاوزه

تستخدم تطبيقات Chromium آليات لمنع تشغيل أكثر من مثيل على دليل بيانات مستخدم واحد، وقد تختلف تفاصيلها بين الأنظمة والإصدارات. وجود ملف يحمل اسم SingletonLock أو آلية مشابهة لا يعني أن حذفه آمن؛ ربما تحمي قاعدة بيانات مفتوحة بالفعل. لا تنصح بحذف ملفات القفل أثناء التشغيل كحل عام. تحقق أولًا من وجود عملية حية تملك الدليل، ثم افحص مسارها وأمر تشغيلها. إذا كانت العملية متوقفة، استخدم إجراء استعادة موثقًا يميز القفل القديم من القفل النشط.

صمم سجل ملكية للمسار

قبل فتح بروفايل، اربط مسار التخزين المطلق بمعرف عملية ووقت بدء ومالك منطقي. يجب أن يكون حجز المسار ذريًا قدر الإمكان، وألا يعتمد فقط على فحص ثم كتابة منفصلين، لأن عمليتين قد تجتازان الفحص في اللحظة نفسها. عند الإغلاق حرر الحجز بعد تأكيد توقف الكتابة. إذا انهارت العملية، لا تفترض أن الحجز ما زال صحيحًا إلى الأبد؛ تحقق من حياة العملية ومعرف التشغيل قبل السماح باستعادة المسار. سجل سبب رفض الفتح للمستخدم بلغة مفهومة.

المسارات المتشابهة قد تكون المسار نفسه

قد تشير صياغتان مختلفتان إلى الدليل نفسه بسبب الروابط الرمزية أو اختلاف حالة الأحرف أو المسارات النسبية أو أقراص الشبكة. طبّع المسار وفق نظام الملفات قبل المقارنة، لكن لا تفترض أن قواعد Windows و Linux متطابقة. انتبه كذلك إلى حروف Unicode المركبة وأسماء المجلدات العربية. عند استخدام روابط رمزية، تحقق من الهدف النهائي وصلاحياته، ولا تعتمد على مقارنة نصية بسيطة. اختبر مسارين يبدوان مختلفين لكنهما يصلان إلى الملفات نفسها؛ يجب أن يرفض النظام الكتابة المتزامنة.

اختبر سيناريو فتح متزامن

جهز بروفايلًا تجريبيًا، ثم أرسل أمر فتح من تطبيقين في اللحظة نفسها. النتيجة المقبولة إما إعادة توجيه الطلب إلى المثيل المالك وفق سياسة معلنة، أو فتح نسخة مستقلة ببيانات منسوخة صراحة، أو رفض واضح للطلب الثاني. النتيجة غير المقبولة هي أن يكتب التطبيقان إلى قاعدة البيانات نفسها دون تنسيق. كرر الاختبار عشرات المرات، لأن سباقات التوقيت قد لا تظهر في أول محاولة. سجل العملية الفائزة والعملية المرفوضة وحالة الملفات بعد الإغلاق.

لا تنس حالات الإغلاق غير النظيف

اقطع العملية التجريبية أثناء تحديث بيانات محلية، ثم حاول فتح البروفايل مرة أخرى. هل يميز التطبيق بين قفل نشط وبقايا تشغيل سابق؟ هل يستطيع استعادة الحالة دون حذف ملفات أساسية؟ اختبر أيضًا إعادة تشغيل النظام وانقطاع الكهرباء في بيئة تجريبية إذا كانت الأدوات تسمح. احتفظ بنسخة من البيانات قبل هذه التجارب. يجب أن يتضمن التقرير حالة قواعد البيانات عند إعادة الفتح، لا مجرد نجاح ظهور النافذة، لأن الفساد قد يظهر عند قراءة سجل معين لاحقًا.

قارن نسخ الملفات بنقل الملكية

نسخ مجلد بروفايل مغلق إلى مسار جديد ينتج نسخة مستقلة من نقطة زمنية معينة، لكنه لا يزامن التغييرات بين النسختين. أما نقل الملكية من تطبيق إلى آخر فيفترض إغلاق الكاتب الأول قبل فتح الثاني. لا تخلط بين الحالتين في الواجهة. إذا عرض التطبيق زر «فتح في تطبيق آخر»، فوضح هل ينقل الملكية أم ينشئ نسخة. كذلك قد لا تنتقل مفاتيح التشفير المرتبطة بالجهاز، لذلك لا تعد باستمرار جميع جلسات تسجيل الدخول بعد النسخ.

اختبر اختلاف إصدارات المحرك

قد يغيّر إصدار Chromium أو Electron مخطط ملفات التخزين أو آلية الترقية. فتح دليل مستخدم بإصدار أحدث ثم الرجوع إلى إصدار أقدم قد يكون غير مدعوم. سجّل الإصدار الذي أنشأ الدليل والإصدار الذي يحاول فتحه، واختبر سيناريوهات الترقية على نسخة منفصلة. لا تعتمد على أن تطبيقين يستخدمان Chromium لتفترض توافقهما الكامل. قد تختلف الأعلام وسياسات الكوكيز والامتدادات وقواعد البيانات. ضع رسالة رفض واضحة إذا كان المسار غير متوافق بدل محاولة إصلاح صامتة.

تأكد من فصل التخزين عبر الاختبار

أنشئ في البروفايل الأول كوكيز تجريبية وبيانات Local Storage و IndexedDB على أصل اختبار محلي، ثم افتح بروفايلًا ثانيًا مستقلًا وتحقق من عدم ظهورها. كرر مع أذونات الموقع وسجل التنزيلات والإضافات إن كان المنتج يدعمها. هذا اختبار سلوك، لا مجرد مقارنة أسماء مجلدات. إذا ظهرت البيانات في الاثنين، افحص session partition ومسارات التخزين الفعلية قبل اتهام الموقع بأنه شاركها. استخدم نطاق اختبار تملكه بدل حسابات شخصية حقيقية.

مراقبة الأقفال في التشغيل اليومي

اعرض حالة البروفايل: متاح، قيد التشغيل، مملوك لعملية أخرى، يحتاج استعادة، أو نسخة غير متوافقة. احتفظ بمعلومات وقت بدء العملية والنسخة والمسار، دون كشف مسارات حساسة لجميع المستخدمين. إذا أُغلق التطبيق فجأة، نفذ تحققًا من حياة العملية قبل إزالة الحجز. راقب عدد حالات الرفض بسبب التنافس وعدد محاولات الاستعادة الناجحة. تكرار الرفض قد يشير إلى خطأ في إدارة دورة الحياة وليس إلى مشكلة في المستخدم نفسه.

جدول قرار سريع

إذا كان الدليل مملوكًا لعملية حية، امنع الكاتب الثاني أو وجّهه للمثيل الأول. إذا كان القفل قديمًا ولا توجد عملية مالكة، نفذ مسار استعادة موثقًا. إذا اختلف إصدار التخزين، اختبر نسخة معزولة قبل أي ترقية. إذا أراد المستخدم نسختين مستقلتين، أنشئ مسارين منفصلين وأوضح أن التغييرات لن تتزامن تلقائيًا. إذا كان الدليل على مشاركة شبكة، افحص دعم القفل والموثوقية قبل استخدامه؛ ليس كل نظام ملفات شبكي مناسبًا لقواعد بيانات متصفح حية.

كيف توثق فشلًا متقطعًا؟

عند ظهور تلف متقطع لا يكفي قول «التطبيق تعطل». احفظ وقت الفتح وإصداري التطبيقين ومعرفات العمليات والمسارات المطبعة ونتيجة فحص القفل ورسائل قواعد البيانات. كرر السيناريو بتزامن مضبوط ثم قارن السجلات. إذا لم تستطع إعادة الفشل، اذكر ذلك بوضوح بدل إعلان حل غير مثبت. قد يكون السبب في قرص ممتلئ أو برنامج مزامنة ملفات أو أذونات غير صحيحة، وليس بالضرورة تنافس عمليتين. فصل الاحتمالات يوفر وقت التصحيح.

خطة قبول قبل الإطلاق

نفذ اختبار فتح متزامن، واختبار انهيار أثناء الكتابة، واختبار اختلاف مسار رمزي، واختبار نسخ مغلق، واختبار اختلاف إصدار. يجب أن تبقى بيانات البروفايل الأصلي قابلة للقراءة، وأن لا يعمل كاتبان على الدليل نفسه دون تنسيق، وأن تظهر رسالة واضحة للمستخدم عند الرفض. قس كذلك زمن استعادة البروفايل بعد انهيار العملية. لا تجعل نجاح تشغيل عشر نوافذ دليلًا على العزل إذا كانت كلها تستخدم المسار نفسه. التحقق من الأثر أهم من عدد النوافذ.

المراجع والقراءة المتصلة

راجع وثائق Chromium حول بيانات المستخدم https://chromium.googlesource.com/chromium/src/+/main/docs/user_data_dir.md، ووثائق Electron عن Sessions https://www.electronjs.org/docs/latest/api/session، وتوثيق SQLite عن القفل والمعاملات https://www.sqlite.org/lockingv3.html. وللاختبارات القريبة اقرأ مقال إيجي تاج «ستة فحوص تأسيسية لعزل البروفايلات» عبر https://egytag.com/ar/articles/profile-isolation-tests-hazem-alaa-2026-10-03. تختلف التفاصيل حسب الإصدار ونظام التشغيل؛ اختبر نسختك الفعلية ولا تعمم سلوكًا من تجربة واحدة.