Ninja: يتم التعامل مع الملفات التي تحتوي على صفر mtime على أنها غير موجودة

تم إنشاؤها على ٢٥ مارس ٢٠١٦ · 14تعليقات · مصدر: ninja-build/ninja

في نظام CentOS 7:

$ tar xf ome-cmake-superbuild-0.1.0.tar.xz
tar: ome-cmake-superbuild-0.1.0/cmake/GitVersion.cmake: implausibly old time stamp 1970-01-01 01:00:00
$ ls -l ome-cmake-superbuild-0.1.0/cmake/GitVersion.cmake
-rw-r--r-- 1 rleigh lsd 236 Jan  1  1970 ome-cmake-superbuild-0.1.0/cmake/GitVersion.cmake

تمت تعبئة أرشيف المصدر هذا بشكل غير صحيح ، وملف واحد به mtime من الصفر (أي بداية عصر Unix).

$ mkdir build
$ cd build
$ cmake -G Ninja ../ome-cmake-superbuild-0.1.0
$ ninja
[1/1] Re-running CMake...
[cmake re-run repeated 100 times]
ninja: error: manifest 'build.ninja' still dirty after 100 tries

القضية:

$ ninja -d explain
ninja explain: output /tmp/ome-cmake-superbuild-0.1.0/cmake/GitVersion.cmake of phony edge with no inputs doesn't exist

من الواضح أن الملف موجود. إذا أنا touch /tmp/ome-cmake-superbuild-0.1.0/cmake/GitVersion.cmake لتحديث الطابع الزمني إلى الوقت الحالي، ثم ninja يعمل تماما. يبدو أن Ninja يتعامل مع الملفات التي تحتوي على صفر mtime على أنها غير موجودة ، وهو ما يبدو غير صحيح. من فضلك هل يمكنك التفكير في تغيير هذا السلوك؟ في حين أن هذه حالة زاوية غير عادية - لا ينبغي أن تحتوي الملفات على طابع زمني قديم - يمكن أن يحدث هذا لأسباب مختلفة ، وسيكون من الجيد أن يعمل Ninja بشكل صحيح في ظل هذه الظروف.

أطيب التحيات،
حاضر

مصدر

ghost

التعليق الأكثر فائدة

أرى شيئًا مشابهًا هنا عند البناء داخل صندوق رمل مسطح ، بشكل أساسي جميع الملفات التي يتم التعامل معها بواسطة ostree ، مما يعني أن ملفات "النظام" لها mtime = 0 (لست متأكدًا من سبب قيامهم بذلك ، لكنني أعتقد أنه مرتبط بالملف de -مضاعفة sytstem). لا تعتبر ملفات النظام هذه غير موجودة ولكنها "قذرة" ، ويتم تشغيل إعادة البناء الكاملة في كل مرة أقوم فيها بتشغيل النينجا في تلك البيئة.

عند إعادة البناء باستخدام ninja -d explain يظهر أن الملفات متسخة على سبيل المثال:

ninja explain: /usr/include/glib-2.0/gio/gtcpwrapperconnection.h is dirty

thiblahute في ٥ أغسطس ٢٠١٦

👍3

ال 14 كومينتر

bool Cleaner::FileExists(const string& path) {
  string err;
  TimeStamp mtime = disk_interface_->Stat(path, &err);
  if (mtime == -1)
    Error("%s", err.c_str());
  return mtime > 0;  // Treat Stat() errors as "file does not exist".
        ^^^^^^^^^
}

يبدو أنه مرشح محتمل. و

  void MarkMissing() {
    mtime_ = 0;
  }

أيضًا RealDiskInterface::Stat و DiskInterface::MakeDirs . في الأساس ، أنت تستخدم mtime كطابع زمني _ و_ رمز خطأ ، وهذا ببساطة غير ممكن نظرًا لأن جميع قيم mtime الصالحة هي أيضًا طوابع زمنية صالحة (حتى تلك السالبة). تم ذكر هذا الافتراض حتى في src / disk_interface.h:

  /// stat() a file, returning the mtime, or 0 if missing and -1 on
  /// other errors.

من المفترض في أماكن أخرى قليلة أيضًا. لا أعتقد أن استراتيجيتك الحالية آمنة ، خاصةً عندما يكون الصفر هو الخيار الافتراضي غالبًا عند عدم تحديده في تنسيقات الأرشيف على سبيل المثال. ضع في اعتبارك أن syscall stat (2) يُرجع ENOENT عندما لا يكون إدخال الدليل موجودًا ، بشكل مستقل عن st_mtime. ربما يمكنك استخدام بنية Stat تحتوي على علامة valid أو تعداد (-1 و 0 حالة) بالإضافة إلى mtime . يمكن أن يوفر operator< للمقارنة mtime و operator(bool) أو operator! لفحص الصلاحية ، مما سيوفر كلتا الميزتين بشكل لا لبس فيه ويزيل السلوك الإشكالي الملاحظ هنا.

ghost في ٢٥ مارس ٢٠١٦

هذه خدعة # 795. اقترح شخص ما السماح لـ mtime بقيمة 1 بدلاً من 0 يعني أن "الملف غير موجود" :-)

في # 795 ، كانت آخر حالة هي أنه أصبح من السهل الآن طباعة رسالة مثل "لا يمكن لـ ninja التعامل مع الملفات باستخدام mtime من 0" بدلاً من وضع علامة عليها بشكل مربك وصامت على أنها متسخة. هل هذا جيد بما فيه الكفاية بالنسبة لك؟

لماذا الملف mtime 0 على نظامك؟

nico في ٦ أبريل ٢٠١٦

mtime من 1 هو اختراق ذكي! يمكن أيضًا إضافة واحد إلى جميع mtimes ، إلى
إتاحة 0. (نحن لا نهتم بالقيمة المحددة للـ mtimes ،
إنها مجرد ملف تعريف ارتباط سحري يتغير عندما يتغير الملف. على نظام Windows
إنها قيمة عشوائية أخرى ، وليست عداد ثوانٍ للعصر.)

في الثلاثاء ، 5 أبريل 2016 ، الساعة 6:36 مساءً ، كتب نيكو ويبر [email protected] :

هذه خدعة # 795 https://github.com/ninja-build/ninja/issues/795.
اقترح شخص ما السماح ل mtime من 1 بدلاً من 0 يعني "الملف لا
يوجد" :-)
في # 795 https://github.com/ninja-build/ninja/issues/795 ، الأحدث
الحالة هي أنه أصبح من السهل الآن طباعة رسالة مثل "لا يستطيع النينجا التعامل معها
الملفات التي تحتوي على mtime من 0 "بدلاً من وضع علامة عليها بصمت على أنها
متسخ. هل هذا جيد بما فيه الكفاية بالنسبة لك؟
لماذا الملف mtime 0 على نظامك؟
-
أنت تتلقى هذا لأنك مشترك في هذا الموضوع.
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub
https://github.com/ninja-build/ninja/issues/1120#issuecomment -206067067

evmar في ٦ أبريل ٢٠١٦

سبب كون mtime صفرًا في هذه الحالة المحددة هو استخدام وحدة Python tarfile بدون تعيين mtime بشكل صريح على الكائنات TarInfo التي يتم حفظها في ملف tar-- يتم تعيينه افتراضيًا إلى الصفر ما لم يتم تعيينه يدويًا. هذا يختلف عن سلوك الواجهة المماثلة في الوحدة النمطية zipfile ، والتي يتم تعيينها افتراضيًا على وقت النظام الحالي (كما هو متوقع عند إنشاء ملف جديد). لكنني رأيت أيضًا أدوات أخرى تقوم بأشياء مماثلة - غالبًا ما يكون الصفر هو الإعداد الافتراضي في الهياكل وهذا يؤدي حتمًا إلى إنشاء ملفات بدون mtime في ظل ظروف مختلفة.

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

شكرا لمتابعة هذا الأمر ،
حاضر

ghost في ٧ أبريل ٢٠١٦

لكن 0 دقيقة ليست مقصودة ، أليس كذلك؟ يبدو أن الخطأ قد يكون أفضل طريقة للمضي قدمًا هنا.

nico في ٨ أبريل ٢٠١٦

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

ghost في ٨ أبريل ٢٠١٦

رمز Windows لتحويل الطابع الزمني لتمثيل نظام الملفات إلى ملف
نوع Ninja TimeStamp هنا:
https://github.com/ninja-build/ninja/blob/master/src/disk_interface.cc#L60

أقترح تغيير هذا الرمز:

https://github.com/ninja-build/ninja/blob/master/src/disk_interface.cc#L193
للعودة st.st_mtime + 1 ؛

أعتقد أنه سيحل كل شيء على حساب عدم معالجتنا بشكل صحيح
الملفات ذات تاريخ الحقبة القصوى (ولكن سيكون لدينا جميع أنواع y2k38
في تلك المنطقة بمجرد اقترابنا من ذلك).

يوم الجمعة 8 أبريل 2016 الساعة 7:56 صباحًا ، روجر لي إخطارات github.com
كتب:

هذا ليس مقصودًا ، لا. لكنه _هو_ شيء يحدث نسبيًا
عادة عن طريق الصدفة. لا أعتقد أن الخطأ سيكون مناسبًا ؛ لو
أي شخص يقوم أبدًا بإصدار مصدر بطابع زمني غير محدد ، وهذا أمر واقعي
غير قابل للبناء مع النينجا. سيكون تعيينه على 1 استراتيجية أفضل بكثير.
-
أنت تتلقى هذا لأنك علقت.
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub
https://github.com/ninja-build/ninja/issues/1120#issuecomment -207466847

evmar في ٨ أبريل ٢٠١٦

عند إعادة البناء باستخدام ninja -d explain يظهر أن الملفات متسخة على سبيل المثال:

ninja explain: /usr/include/glib-2.0/gio/gtcpwrapperconnection.h is dirty

thiblahute في ٥ أغسطس ٢٠١٦

👍3

بالنسبة إلى flatpak ، سأضيف التصحيح في https://github.com/flatpak/flatpak/issues/607#issuecomment -287952697 إلى بنية النينجا الخاصة بنا حتى يتم اكتشاف ذلك.

alexlarsson في ٢٧ مارس ٢٠١٧

أعتقد أن لدي إصلاحًا أكثر شمولاً في # 1293

gtristan في ١٨ يونيو ٢٠١٧

فقط أشير أيضًا إلى أنني قدمت أيضًا ملف تصحيح Patrick Griffis المستخدم في Flatpak كطلب سحب رقم 1292 ، وهو حل بديل جيد للمشكلة ، والذي نعلم أنه تم اختباره جيدًا (تم اختبار الإنشاءات بانتظام مع ذلك المطبق على الأقل).

لكنني بذلت بعض الجهد للقيام بذلك بدقة في # 1293 بحيث يتم تغيير الدلالي وأي وقت يكون صالحًا ، بما في ذلك 0 و mtimes السالبة التي يجب أن تكون صالحة أيضًا (لست متأكدًا من كيفية وقوف قاعدة الكود إلى mtimes السلبية ، على الرغم من ). على الرغم من أنني أعتقد أن رقم 1293 هو الإصلاح الصحيح ، إلا أنه بالطبع يعد تغييرًا جائرًا وسيكون من الجيد مراجعة ذلك (لم ينتهي بي الأمر بتعديل deps_log. [cc، h] ، لست متأكدًا مما إذا كان التغيير مطلوب هناك للتمييز بين وجود الملف و mtimes). ومع ذلك ، فقد قمت ببناء الكثير من وحدات جنوم باستخدام الفرع 1293 بدون مشكلة.

بغض النظر عن المسار الذي يتم اتخاذه ، سيكون من الجيد أن يكون لديك بعض الإصلاح في النينجا المنبع لهذا الغرض.

gtristan في ١٩ يونيو ٢٠١٧

شكرًا ، لقد قمت بدمج # 1292 الخاص بك. كما قيل في مكان آخر ، يبدو هذا وكأنه الإصلاح الأفضل بالنسبة لي ، لذلك سأتجاهل # 1293 في الوقت الحالي إذا كان هذا مناسبًا لك.

nico في ١٩ يونيو ٢٠١٧

وشكرا جزيلا على الإصلاح!

nico في ١٩ يونيو ٢٠١٧

شكرًا ، لقد قمت بدمج # 1292 الخاص بك. كما قيل في مكان آخر ، يبدو هذا وكأنه الإصلاح الأفضل بالنسبة لي ، لذلك سأتجاهل # 1293 في الوقت الحالي إذا كان هذا مناسبًا لك.

لا تقلق ، أنا سعيد لأنني لست بحاجة إلى تصحيح المصب :)

ربما يمكنك أيضًا إغلاق # 795

gtristan في ٢٠ يونيو ٢٠١٧

هل كانت هذه الصفحة مفيدة؟

0 / 5 - 0 التقييمات