Restic: أضف علامة "--files-from-raw" التي تعامل كل سطر حرفيًا ، وتعالج بهذا الترتيب بالضبط ، وبدون أي تعليقات أو خداع

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

rawtaz لم أستطع الاختلاف أكثر.

• لقد أغلقت رقم 3005 الذي غطى نفس الأرضية ولكن في محاولة خاسرة لتغيير ميزة موجودة. هذه هي ميزة جديدة.
• أحاول أن أكون واضحًا جدًا فيما يجب أن تفعله الميزة. لدي وظائف محددة للغاية في ذهني ، وعلى الرغم من أنني لا أعمل عليها ، ولا أمتلك الخبرة في Go للقيام بذلك ، الآن هو التغيير الوحيد لي للحصول على مدخلات في هذه العملية ، بدلاً من الشكوى منها بعد وقوعها.
• من نموذجك الذي يطرح أسئلة مفصلة ، يبدو كما لو كان يتم تقييمه على قضايا غامضة وغير مكتملة وسيئة البحث.
• كانت هذه على وجه التحديد مشكلة مستمرة مع ما لا يقل عن ستة من المشكلات ذات الصلة وتمتد لعدة أشهر - ولكن لم يقترح أي حل معين (بخلاف تغيير السلوك الحالي --files-from ). يبدو لي على الأقل أنه مصدر قلق مهم جدًا في المجتمع الذي يستحق حلاً مقترحًا مفصلاً ودقيقًا وصريحًا للغاية. وفي هذه الحالة ، بناءً على التعليقات التي قرأتها من مطوري restic في مشكلات أخرى ، إذا لم يتم تفصيلها بعناية فائقة في الطلب ، فمن المحتمل أن تنشر العديد من الشكاوى المحيطية نفسها التي رافقت أيضًا بشكل عرضي --files-from ( على سبيل المثال ، لا يوجد والد لقطة ، لا يتبع نفس الترتيب المدرج ، وما إلى ذلك). قد تكون هناك أسباب وجيهة تمامًا لذلك ، لكنني أشعر أنها على الأقل بحاجة إلى الإشارة إليها حتى يتم التفكير في قرارات القيام بذلك بشكل مختلف ، واتخاذ قرار بشأنها عن قصد ، بدلاً من تركها لترث بعض السلوك الحالي. (لقد كنت أيضًا مبرمجًا لأكثر من عقد. لقد فهمت ذلك).
• أنا مصمم منتجات كجزء من عملي. صدقني ، هذا _ قصير _ لمواصفات الميزات. ربما تكون على دراية بهذا أيضًا. إذا كنت تفضل ذلك ، يمكنني إرسال مواصفات فعلية. شيء ما يخبرني أنك ترغب في ذلك أقل.
• عندما علقت على وجه التحديد على --files-from ، يبدو أن الناس يأخذون الأمر على محمل شخصي ويرفضون الاقتراحات تمامًا ، أو ينحرفون عن قبضتهم غير ذات الصلة. (لكن عدم تغيير ميزة موجودة يعد أمرًا شرعيًا تمامًا. ومن ثم ميزة جديدة.) أحاول تجنب كل ذلك من خلال معالجة الاعتراضات في وقت مبكر. ربما تعمل بشكل أفضل مع نفس القدر من النص ولكن بتنسيق خلفي. لسوء الحظ شخصيًا ، ليس لدي الوقت الكافي لذلك على مدار اليوم ، فقط في كتل.
• أرغب في استخدام restic للأعمال التي توظفني ، ولمن أتخذ مثل هذه القرارات. حاليا لا أستطيع. هذه الميزة ، وكلما جعلها Prune speedup في إتقان ، ستكون The One. قد لا تهتم أنت وكثيرون غيرك ، لكنني أعتقد أن ذلك سيظل بمثابة فوز رمزي صغير لمجتمع الراحة. (وبالتأكيد سأرتاح أسهل.)

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

ربما يكون المنتدى مكانًا أفضل للمناقشة المتعمقة.

ProactiveServices

ربما يكون المنتدى مكانًا أفضل للمناقشة المتعمقة.

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

@ jim-collier لقد كتبت اقتراحًا لكيفية ظهور المنشور الأول في هذه المشكلة بدلاً من ذلك (انظر أدناه). إنها أقصر بكثير ولكني احتفظت بكل شيء تقريبًا من المنشور الذي بدا مناسبًا (بالنسبة لي بالطبع ، كل شيء فردي) ، وثق بي عندما أقول إنني قرأت كل ما كتبته حتى لا يفوتني أي جزء منه .

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

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

ما الذي يجب أن يفعله Restic بشكل مختلف؟ ما الوظيفة التي تعتقد أننا يجب أن نضيفها؟

يجب أن يقبل restic backup الخيار --files-from-raw <file> الذي يعمل مثل --files-from <file> الحالي ولكن بدلاً من إلقاء السطور في الملف المحدد ، يوزعها تمامًا كما هي مكتوبة ، حرفيًا.

ماذا تحاول أن تفعل؟ ما المشكلة التي يمكن أن يحلها هذا؟

من الشائع جدًا ، غالبًا كجزء من الإعدادات التلقائية / المبرمجة ، أن يكون لديك أدوات لإنشاء قائمة أولية من الملفات لنسخها احتياطيًا ، والتي يتم منحها بعد ذلك إلى restic backup باستخدام الخيار --files-from ، والذي ينطبق على globbing لكل سطر لحل اسم الملف لعمل نسخة احتياطية. عندما يحتوي اسم ملف واحد أو أكثر في هذه القائمة على أحرف لها معنى خاص في اللقطات المتحركة ، على سبيل المثال الأقواس أو علامات الدولار أو البداية / النهاية بمسافة ، فقد ينتهي الأمر بعدم تضمين هذه الملفات في النسخة الاحتياطية بسبب نتيجة عدم أطول يطابق اسم / مسار الملف الفعلي على القرص.

تم بالفعل ذكر هذه المشكلة أو مناقشتها في # 2276 و # 2448 و # 3005 و # 2944 (والتي ربما تكون الأقرب إلى المواصفات المقترحة إلى جانب هذه المشكلة). في حين أنه من الممكن إجراء معالجة مسبقة لقائمة الملفات التي سيتم تغذيتها بـ restic backup باستخدام --files-from ، فإن هذا عرضة للخطأ (يمكن بسهولة أن يفوت المرء بعض الحالات الجانبية) والعمل غير الضروري ، عندما يمكن أن يكون هناك خيار --files-from-raw يوزع قائمة الملفات حرفيًا.

نظرًا لأن تغيير السلوك الحالي لـ --files-from سيؤدي إلى كسر التوافق إلى الوراء ، أقترح بدلاً من ذلك إضافة الإصدار --files-from-raw ، مثل rclone فعلته بالفعل ومثل rsync 's --files-from العمل. يرجى الاطلاع على المواصفات المقترحة أدناه. بالنسبة لبيئاتي وحالات الاستخدام الخاصة بي ، ستكون هذه الميزة هي المفتاح لجعل restic الأداة المثالية لنسخ بياناتي احتياطيًا.

المواصفات المقترحة

أقترح أن يقوم --files-from-raw بقراءة وحل الأسطر في الملف المحدد بالطريقة التالية:

• كل سطر _مواصفات ملف 1: 1 دقيقة_ - لا خفقان.
• تعتبر المسافات البادئة والزائدة وعلامات التبويب وما إلى ذلك جزءًا من اسم الملف.
• تتم معالجة الملفات (نسخها احتياطيًا) تمامًا بالترتيب الذي تظهر به في <file> (هذا مهم جدًا ، حيث قد يكون الطلب مقصودًا للغاية ، على سبيل المثال تم فرزها بالفعل بواسطة المستخدم في التاريخ والحجم وما إلى ذلك).
• التعليقات أو الأسطر الفارغة غير "مسموح بها" - سيتم تفسير علامة تعليق مثل # كجزء من اسم الملف ، وسيتم تجاهل الأسطر الفارغة (ربما مع انبعاث تحذير).
• يتم تحديد مواصفات مسار الملف بالسطر الجديد - في حالة احتواء اسم الملف فعليًا على سطر جديد ، فهذا استثناء واحد لن يستوعبه --files-from-raw وسيتعين تصحيح اسم الملف على القرص أو تلك الملفات المضمنة بطرق أخرى.

بالإضافة إلى ذلك ، يجب أن يشير restic --files-from-raw افتراضيًا إلى اللقطة السابقة كأصل ، إذا لم يتم تحديد وسيطات أو علامات أخرى متعلقة باللقطات ، للسماح للمستخدم بالمساعدة في معرفة الملفات التي لا تحتاج إلى مسحها ضوئيًا تكرارا.

هل ساعدك ريستيك اليوم؟ هل جعلك سعيدا بأي شكل من الأشكال؟

أشعر وكأنني صديقة جيري ماجواير: ريستيك قريب جدًا من كونه قادرًا عليه! :-د

وفي كلتا الحالتين ، مطور رائع ومجتمع مستخدم. أتمنى فقط أن أحصل على هذه الميزة في restic حتى أتمكن من دمجها مع بيئتي.

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

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

rawtaz

لقد كتبت اقتراحًا لكيفية ظهور المنشور الأول في هذه المشكلة بدلاً من ذلك (انظر أدناه)

شكرا على الجهد البناء في تقديم مثال أفضل. أخذت النقطة.

عدم السماح بأسطر جديدة ليس اتفاقية عالمية. تم تجهيز بحث GNU و xargs بعلامات -print0 و -0 للتعامل مع الأسطر الجديدة في أسماء المسارات: يقومون بإنهاءها NUL ، مع العلم أن بايت NUL هو البايت الوحيد غير المسموح به في أسماء مسارات Unix. يسمح معيار POSIX القياسي xargs بأسماء المسارات المقتبسة في مدخلاته للسبب نفسه تقريبًا. يستخدم Git سلاسل منتهية بـ NUL بتنسيق الشجرة الخاص به.

إذا كان الغرض هو النسخ الاحتياطي من قائمة تم إنشاؤها بواسطة أداة ، فإن الحل الشامل لـ Unix سيكون قبول إخراج find -print0 .

إن إخبار المستخدم بتنظيف أسماء المسارات الخاصة به يفتقد إلى النقطة: تريد تشغيل نسخة احتياطية مسبقًا ، لأن التنظيف الآلي عرضة للخطأ.

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

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

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

إذا كان هذا شيئًا نريد دعمه ، فأنا أقترح أن نجعل ببساطة --files-from-raw نستخدم البايت NULL فقط كفاصل أسطر ، مما يجعله يتعامل بنسبة 100٪ مع الملف بأكمله الذي يتم تغذيته به حرفيًا وخامًا - ثم ليس هناك شك على الإطلاق حول ما يفعله ، وكيف يعالج السطور ، ولا توجد طريقة يمكن أن يفشل فيها في معالجة ملف التضمين المنسق بشكل صحيح. يجب أن يغطي هذا كل حالة استخدام محتملة أفترضها.

أقترح تقديم كل من --files-from-raw (فواصل الأسطر الجديدة) و --files-from-raw0 (فواصل البايت الفارغة). يجب أن يرضي هذا الجميع ، ويبدو مألوفًا لمستخدمي find ، وربما لن يكلف كثيرًا من حيث تعقيد الكود.

الخيار الآخر هنا هو إضافة إشارات ثانوية تؤثر على سلوك --files-from .

--files-from --from-noglob
--files-from --from-0

يحتوي rsync على ميزة مشابهة لأسماء الملفات التي تم إنهاؤها فارغة:

--from0, -0
       This tells rsync that the rules/filenames it reads from a file are ter‐
       minated by a null ('\0') character, not a NL, CR, or CR+LF.   This  af‐
       fects  --exclude-from,  --include-from,  --files-from,  and  any merged
       files specified in a --filter rule.  It does not  affect  --cvs-exclude
       (since all names read from a .cvsignore file are split on whitespace).

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

إذا كان هذا شيئًا نريد دعمه ، فأقترح أن نجعل --files-from-raw فقط نستخدم البايت NULL كفاصل أسطر

أنا لست من محبي هذه الفكرة. أوافق على بيانك السابق لـ

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

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

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

أنا أعمل على العلاقات العامة. هل يمكنني اقتراح وضع 0 في اسم العلم ليكون واضحًا تمامًا؟ - من-ملفات- raw0؟ - من ملفات 0؟

ليس من المنطقي وضع 0 في اسم الخيار للإشارة إلى أنه يستخدم NULL لفصل أسماء الملفات. يجب تسمية الخيار على اسم ما يفعله ، وليس طريقة عمله. في هذه الحالة ، تتعلق الميزة بقراءة الملفات بطريقة "خام" أو "حرفيًا" ، ولا تتعلق بقراءة أسماء الملفات التي تحتوي على حرف NULL كفاصل. هذا هو السبب في أن --files-from-raw (ما يفعله) أكثر ملاءمة من --files-from0 (كيف يتم ذلك). أقترح فقط إبقائه بسيطًا وتسمية الخيار كما تمت مناقشته من قبل. يعود الأمر إلى وصف الخيار والتوثيق للبرنامج لشرح كيفية قيامه بالأشياء.

هذه ليست تفاصيل التنفيذ. هذا هو تحديد تنسيق الملف الذي يجب على المستخدم توفيره. كما أنه يتماشى مع البحث ، و xargs ،rclone و rsync و Git (باستثناء ملفات git ls-files التي تهجئ صفر "-z").

ليس هناك حاجة. ما الذي يجعلك تعتقد أنه مطلوب؟ هل تعتقد أن أي شخص سيستخدم --files-from-raw دون أن يقرأ أولاً ما يفعله بالفعل (وفي ذلك لاحظ أن أسماء الملفات يجب فصلها بـ NULL)؟ إلى جانب ذلك ، من المؤكد أنه أحد تفاصيل التنفيذ ، خاصةً عند إزالة الجزء "الخام" والذي يمكن القول أنه جزء أكثر أهمية وأهم بكثير لوصف ما يفعله الخيار.

في سياق restic ، --files-from-raw أفضل من --files-from0 . نظرًا لأن الأخير يُنظر إليه على أنه تعديل --files-from "مع فاصل صفر بايت" ، بينما في الواقع سيكون وظيفة مختلفة بشكل كبير (أسماء الملفات الحرفية مقابل أنماط الكرة الأرضية) ، لذلك هناك حاجة إلى اختلاف أكثر وضوحًا في التسمية .

ثم مرة أخرى ، اقترحت بالفعل استخدام --files-from-raw0 ، والذي من شأنه أن يميز الخيار الجديد عن --files-from ، ويعطي تلميحًا عن فواصل البايت الفارغة. :)

pvgoran نقطة جيدة.

rawtaz أنا لا أقول أنه مطلوب. إنها تشبه إلى حد بعيد ما تفعله الأدوات الأخرى وهي توثق ذاتيًا ، بينما تقترح --files-from-raw نفس السلوك مثل rclone ، لكن rclone تريد أسطرًا جديدة. هل تعترض على الصفر أم على عدم تضمين القذف؟

هل تعترض على الصفر أم على عدم تضمين القذف؟

إذا كان هناك --files-from-raw واحدًا ، فأنا أعترض على إضافة 0 إليه ، لأن التفاصيل مثل كيفية إجراء الفصل في الملفات التي يتم تغذيتها من خلال هذا الخيار ليست شيئًا يجب وصفه من خلال تسمية الخيار . فيما يتعلق بعدم تضمين -raw ، فهذا ليس خيارًا حتى (لا يقصد التورية: P) للأسباب التي ذكرهاpvgoran.

لدينا بعض الأفكار حول كيفية المضي قدمًا في هذا ، ترقبوا ؛)

حسنًا ، اتفقنا أنا و @ fd0 و MichaelEischer على ما نعتقد أنه السبيل للمضي قدمًا في طلب الميزة هذا وتنفيذه. نود أن نفعل ما يلي:

• نفِّذ خيارًا جديدًا --files-from-raw <file> يقرأ مسارات الملفات حرفيًا بنسبة 100٪ ، دون أي تفكير أو تحليل ، من <file> . باستخدام هذا الخيار ، يجب فصل مسارات الملفات فقط بواسطة حرف سطر جديد عادي \n .

• نفِّذ خيارًا جديدًا --files-from-raw0 <file> يقرأ مسارات الملفات حرفيًا بنسبة 100٪ ، دون أي تفكير أو تحليل ، من <file> . باستخدام هذا الخيار ، يجب فصل مسارات الملفات فقط بمقدار \0 NULL بايت.

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

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

هل يعترض أحد على ذلك ، وإذا كان الأمر كذلك فما هو الأساس المنطقي؟ أيضًا ، إذا فاتني أي شيء في الوصف / المواصفات أعلاه ، فيرجى إبلاغي بذلك :)

greatroar هل يمكنك تحديث العلاقات العامة الخاصة بك لتتناسب مع النقطتين السابقتين؟ هناك بعض التعليقات بخصوص وصف هذه الخيارات التي سأقدمها عند الانتهاء من ذلك: +1:

rawtaz لدي نقطتان متبقيتان دقيقتان نوعًا ما.

أنت تسأل عن فواصل ، لكني قمت بتطبيق عوامل إنهاء. التمييز هو أنه بين "foo \ x00bar" (منفصل) و "foo \ x00bar \ x00" (منتهي). يحتوي الخيار الأخير على حالة زاوية أقل واحدة (مفقودة NUL النهائية) ، ويتطابق مع ما ينتج عن find -print0 ويسمح لنا بإعطاء رسالة خطأ واضحة عندما يمرر المستخدم الملف الخطأ ("foo \ nbar \ n" لا يفعل تحتوي على أي أحرف NUL). أعتقد أنه بالنسبة للخطوط الجديدة ، هذا أقل أهمية.

فيما يتعلق بالأسطر الجديدة ، هل نسمح أيضًا بـ "\ r \ n" لتوفير الراحة لمستخدمي Windows؟

فيما يتعلق بالأسطر الجديدة ، هل نسمح أيضًا بـ "\ r \ n" لتوفير الراحة لمستخدمي Windows؟

- استبعاد ملف و - ملفات - من سماح "\ r \ n" ولا أرى أي سبب لضرورة عمل --files-from-raw بشكل مختلف.

تقوم هذه الخيارات بالكثير من الأشياء بشكل مختلف عن الخيارات المقترحة. لكن TBH ، السبب الذي أطلبه هو أنه يتطلب المزيد من التعليمات البرمجية للتعامل مع CRLF.

لكن TBH ، السبب الذي أطلبه هو أنه يتطلب المزيد من التعليمات البرمجية للتعامل مع CRLF.

سيكون هذا الرمز مطابقًا لـ readLinesFromFile ، لكن بدون اقتطاع التعليق / المساحة.

فيما يتعلق بالأسطر الجديدة ، هل نسمح أيضًا بـ "\ r \ n" لتوفير الراحة لمستخدمي Windows؟

يستخدم رمز --files-from bufio.ScanLines هنا ، والذي يدعم \r\n بالإضافة إلى \n . يجب أن يكون هو نفسه بالنسبة إلى --files-from-raw الجديد. :)

التمييز هو أنه بين "foo \ x00bar" (منفصل) و "foo \ x00bar \ x00" (منتهي). يحتوي الخيار الأخير على حالة زاوية أقل واحدة (مفقودة NUL النهائية) ، ويتطابق مع ما ينتج عن find -print0 ويسمح لنا بإعطاء رسالة خطأ واضحة عندما يمرر المستخدم ملفًا خاطئًا ("foo \ nbar \ n" لا يحتوي على أي NUL الشخصيات). أعتقد أنه بالنسبة للخطوط الجديدة ، هذا أقل أهمية.

أرغب في إرجاع رسالة خطأ عند عدم وجود بايت فارغ ، لذلك سأختار طريقة "إنهاء" هنا.

هذا يعني أن -raw0 يتطلب نهاية \ 0 في السطر الأخير ، بينما -raw لا يتطلب سطرًا جديدًا للنهاية في السطر الأخير. هذا غير متسق.

إنه غير متسق فقط لأنك قررت اعتبار الأسطر غير المنتهية خطأ.
يستخدم rclone نفس الوظيفة البسيطة لكل من --files-from-raw و --files-from .
حتى أن rsync يستخدم نفس الكود ( if (eol_nulls? !ch : (ch == '\n' || ch == '\r')) ) لجميع أنواع نهاية السطر.

إنه غير متسق فقط لأنك قررت اعتبار الأسطر غير المنتهية خطأ.

يعتبر POSIX أيضًا هذا خطأ: https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html#tag_03_206

لقد قمت الآن بتنفيذ نهايات CR / LF ولكن لم يتم التحقق من السطر الجديد النهائي في # 3017. إضافة هذا الشيك لن يكون صعبًا ولا يهمني في كلتا الحالتين ، لذا يرجى تحديد :)

التمييز هو أنه بين "foo \ x00bar" (منفصل) و "foo \ x00bar \ x00" (منتهي). يحتوي الخيار الأخير على حالة زاوية أقل (تفتقد NUL النهائي) ، ويتطابق مع ما ينتج عن find -print0

يمكن تعديلها لمطابقة ذلك ، لكننا لسنا بحاجة إلى ذلك ، لأنه إذا كان -raw0 يستخدم فواصل بدلاً من فواصل ، وتم تغذيته بملف من إنتاج -print0 ، وبالتالي تكون البيانات على سبيل المثال foo\x00bar\x00 ، ثم -raw0 $ سيشاهد ثلاث "إدخالات" ، وهي foo و bar و ` . We should obviously silently ignore empty (zero length) entries, so the last one which is due to the terminating \0 from -print0 , will just be ignored. Hence there's no need or value in matching the type of output - print0` ، نظرًا لعدم وجود تأثير سلبي لعدم القيام بذلك.

ويسمح لنا بإعطاء رسالة خطأ واضحة عندما يمرر المستخدم الملف الخطأ ("foo \ nbar \ n" لا يحتوي على أي أحرف NUL). أعتقد أنه بالنسبة للخطوط الجديدة ، هذا أقل أهمية.

أرغب في إرجاع رسالة خطأ عند عدم وجود بايت فارغ ، لذلك سأختار طريقة "إنهاء" هنا.

فقط لأكون واضحا؛ إذا جعلنا -raw0 يتطلب إنهاء ، فهل سيعطي رسالة خطأ عند تلقيم ملف مثل foo\x00bar\x00star ؟ أيضًا ، هل ستظهر رسالة خطأ عند تغذية شيء مثل foo ؟

هل ستظهر رسالة خطأ عند تغذيتها بملف مثل foo\x00bar\x00star ؟ أيضًا ، هل ستظهر رسالة خطأ عند تغذية شيء مثل foo ؟

نعم ، في كلا الأمرين. والأهم من ذلك ، أنه يعطي رسالة خطأ foo\nbar\n ، لذلك يمكنه التقاط ملف بتنسيق -raw مبكرًا. يتم التعامل مع أسماء الملفات الفارغة ( \x00\x00 ) كخطأ أيضًا ، لأنه لا يوجد نظام يسمح بها وقد تشير إلى أخطاء في البرنامج النصي الذي أنشأ الأسماء. والعكس صحيح ، --files-from-raw عمليات التحقق من صفر بايت وإصدار رسائل خطأ تشير إلى -files-from-raw0.

ما لا يعجبني في هذا (- يتطلب الرسم فواصل فقط ولكن -raw0 يتطلب إنهاء) هو أن السبب العملي / الاستخدام الوحيد له هو إعطاء رسالة خطأ أفضل مما قد يحصل عليه المستخدم إذا قام بتغذية سطر جديد- ملف منفصل إلى -raw0 (حيث يخبرهم restic أنه لا يمكن العثور على اسم ملف طويل). هذا حقًا هو السبب الوحيد لإدخال عدم الاتساق في الخيارات ، وأعتقد أنه لن يلاحظ أحد أبدًا أن ملفاته لا يتم نسخها احتياطيًا بشكل صحيح عندما يعطون ملفًا عن طريق الخطأ -raw0 بدلاً من -raw. لذلك أعتقد أن هذا يعد استخدامًا عمليًا محدودًا للغاية ، وبالتالي لا أشعر أنه يستحق تكلفة CLI غير المتسق.

لكنني أعتقد أنه ما هو عليه وعلينا أن نفعله على أي حال. وأيضًا @ fd0 و @ michaelEischer يعتقدان أنه مطلوب. سيتعين علينا فقط تعيين الإصدار -raw0 كخيار للبيانات المنسقة / المُنشأة بشكل خاص للغاية ، في حين أن -raw هو أكثر سماحًا ومن المحتمل أن تكون صناعة يدوية قذرة.

هل الكود الخاص بك لـ -raw يتجاهل بصمت الإدخالات الفارغة (على سبيل المثال من foo\n\nbar ) أم أنه يعطي خطأ ويرفض ذلك؟ أعتقد أنه إذا أردنا أن يكون هذا الخيار هو نوع السماح ، فيجب أن نتجاهله بصمت ، أليس كذلك؟

- أخطاء السحب أيضًا عند رؤية سطر فارغ في العلاقات العامة.

لا أرى الهدف من ذلك ، هل أفتقد سببًا وجيهًا لذلك؟ يعد عدم تجاهل الأسطر / الإدخالات الفارغة في -raw0 أمرًا واحدًا لأنه من المتوقع أن يكون مثاليًا بنسبة 100٪ كما تم إنشاؤه بواسطة برنامج نصي أو ما شابه ، ولكن نظرًا لأننا نعلم أن السلسلة الفارغة لن تكون اسم ملف صالحًا ، فلماذا لا تتجاهلها فقط الالتزام بالصف.

الاتساق ، لكنني أعتقد أن هذه الحجة خارج النافذة: ابتسم:

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

greatroar سنذهب مع --files-from-raw بصمت مع تجاهل الأسطر الفارغة / العناصر الفارغة (على سبيل المثال ، foo\n\nbar لن يشتكي من أي شيء). شكرا.

موافق! لقد قمت بتحديث # 3017 ، يرجى المراجعة هناك.