Windows ਅੰਦਰੂਨੀ ਹੋਸਟ ਨੂੰ ਬਿਨਾਂ ਕਿਸੇ ਸ਼ਿਕਾਇਤ ਦੇ ਹੱਲ ਕਰਦਾ ਹੈ, ਅਤੇ ਉਹੀ ਨਾਮ ਸੁਰੰਗ ਉੱਠਣ ਦੇ ਪਲ ਹੀ WSL ਅੰਦਰ ਫੇਲ੍ਹ ਹੋ ਜਾਂਦਾ ਹੈ। ਆਮ ਸੁਧਾਰ ਇਹ ਹੈ ਕਿ ਡਿਸਟਰੀਬਿਊਸ਼ਨ ਵਿੱਚ ਇੱਕ ਜਨਤਕ ਰਿਜ਼ੋਲਵਰ ਲਿਖ ਦਿੱਤਾ ਜਾਵੇ, ਜੋ ਆਮ ਬ੍ਰਾਊਜ਼ਿੰਗ ਵਾਪਸ ਲਿਆਉਂਦਾ ਹੈ ਅਤੇ ਕੰਮ ਦੇ ਹੋਸਟਨਾਮ ਨੂੰ ਹੱਲ ਨਾ ਹੋਣ ਯੋਗ ਬਣਾ ਦਿੰਦਾ ਹੈ। ਇਹ ਇੱਕ ਫੇਲ੍ਹਤਾ ਨੂੰ ਦੂਜੀ ਨਾਲ ਬਦਲ ਦਿੰਦਾ ਹੈ ਅਤੇ ਉਸ ਪਰਤ ਨੂੰ ਲੁਕਾ ਦਿੰਦਾ ਹੈ ਜੋ ਅਸਲ ਵਿੱਚ ਟੁੱਟੀ ਸੀ। ਕੋਈ ਵੀ ਰਿਜ਼ੋਲਵਰ ਲਾਈਨ ਜੋੜਨ ਜਾਂ ਹਟਾਉਣ ਤੋਂ ਪਹਿਲਾਂ ਨਿਰਧਾਰਤ ਕਰੋ ਕਿ ਤਿੰਨਾਂ ਵਿੱਚੋਂ ਕਿਹੜੀ ਪਰਤ ਫੇਲ੍ਹ ਹੋ ਰਹੀ ਹੈ।

ਪਹਿਲਾਂ ਰੂਟਿੰਗ ਫੇਲ੍ਹਤਾ ਨੂੰ ਬਾਹਰ ਰੱਖੋ

ਦੋਵੇਂ ਪਾਸਿਆਂ ’ਤੇ ਉਹੀ ਪੂਰੀ ਤਰ੍ਹਾਂ ਯੋਗ ਨਾਮ ਪੁੱਛੋ, ਇੱਕੋ ਜਿਹੇ ਦਿਖਦੇ ਦੋ ਨਾਮ ਨਹੀਂ। ਇੱਕੋ ਸਟ੍ਰਿੰਗ ਲਈ Windows ਵਿੱਚ ਸਫਲਤਾ ਅਤੇ WSL ਵਿੱਚ ਫੇਲ੍ਹਤਾ ਦੋ ਵੱਖਰੇ ਰਿਜ਼ੋਲਿਊਸ਼ਨ ਰਾਹਾਂ ਦਾ ਦਸਤਖ਼ਤ ਹੈ, ਅਤੇ ਇਹ ਨਮੂਨਾ ਇੰਨਾ ਸਾਫ਼ ਹੋਰ ਘੱਟ ਚੀਜ਼ਾਂ ਬਣਾਉਂਦੀਆਂ ਹਨ। ਜੇ WSL ਆਪਣੇ ਜਾਣੇ-ਪਛਾਣੇ ਸੰਖਿਆਤਮਕ ਪਤੇ ’ਤੇ ਵੀ ਸੇਵਾ ਤੱਕ ਨਹੀਂ ਪਹੁੰਚ ਸਕਦਾ, ਤਾਂ ਰੂਟਿੰਗ ਜਾਂ ਫਿਲਟਰਿੰਗ ਦੀ ਸਮੱਸਿਆ ਵੀ ਹੈ। ਉਸ ਸਥਿਤੀ ਵਿੱਚ DNS ਦਾ ਕੰਮ ਇਸ ਨੂੰ ਸਾਹਮਣੇ ਨਹੀਂ ਲਿਆਏਗਾ, ਅਤੇ ਦੁਪਹਿਰ ਗਲਤ ਪਰਤ ’ਤੇ ਚਲੀ ਜਾਵੇਗੀ।

ਤਿੰਨ ਲੱਛਣ ਇਹਨਾਂ ਵਿੱਚੋਂ ਜ਼ਿਆਦਾਤਰ ਮਾਮਲੇ ਕਵਰ ਕਰਦੇ ਹਨ, ਅਤੇ ਹਰ ਇੱਕ ਵੱਖਰੀ ਥਾਂ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦਾ ਹੈ। ਕਨਫਿਗਰੇਸ਼ਨ ਫਾਈਲ ਖੋਲ੍ਹਣ ਤੋਂ ਪਹਿਲਾਂ ਮੇਲ ਖਾਂਦੀ ਕਤਾਰ ਪੜ੍ਹੋ:

Symptom inside WSLLikely layerWhere to look
Private name fails while public browsing worksResolver pathTunneling mode and the Windows build
A name that worked yesterday fails todayStale overrideGenerated resolver file, immutable flag, shell profile
The name resolves but the service does notRouting or filteringThe resolved address and the path to it

ਵਿਚਕਾਰਲੀ ਕਤਾਰ ਉਹ ਹੈ ਜਿਸ ਨੂੰ ਲੋਕ ਗਲਤ ਪੜ੍ਹਦੇ ਹਨ, ਕਿਉਂਕਿ ਇਸ ਨੂੰ ਤੋੜਨ ਵਾਲਾ ਬਦਲਾਅ ਹਫ਼ਤੇ ਪਹਿਲਾਂ ਕੀਤਾ ਗਿਆ ਸੀ ਅਤੇ ਉਦੋਂ ਸਫਲ ਲੱਗਦਾ ਸੀ। ਤੀਜੀ ਕਤਾਰ ਉਹ ਹੈ ਜਿਸ ਦਾ ਲੋਕ ਗਲਤ ਨਿਦਾਨ ਕਰਦੇ ਹਨ, ਕਿਉਂਕਿ ਹੱਲ ਹੁੰਦਾ ਨਾਮ ਨੈੱਟਵਰਕ ਦੇ ਸਿਹਤਮੰਦ ਹੋਣ ਦਾ ਸਬੂਤ ਲੱਗਦਾ ਹੈ। ਦੋਵੇਂ ਕਤਾਰਾਂ ਤੁਹਾਨੂੰ ਹੇਠਾਂ ਵੱਖਰੇ ਭਾਗ ਵਿੱਚ ਭੇਜਦੀਆਂ ਹਨ।

DNS ਸੁਰੰਗ ਦੀ ਇੱਕ ਘੱਟੋ-ਘੱਟ ਸੰਸਕਰਣ ਸੀਮਾ ਹੈ

Microsoft WSL ਦਾ ਇੱਕ ਨੈੱਟਵਰਕਿੰਗ ਮੋਡ ਦਸਤਾਵੇਜ਼ ਕਰਦਾ ਹੈ ਜੋ ਵਰਚੁਅਲਾਈਜ਼ੇਸ਼ਨ ਚੈਨਲ ਰਾਹੀਂ DNS ਬੇਨਤੀਆਂ ਨੂੰ Windows ਰਿਜ਼ੋਲਵਰ ਤੱਕ ਸੁਰੰਗਦਾ ਹੈ। ਸਮਰਥਿਤ Windows 11 ਬਿਲਡਾਂ ’ਤੇ ਇਹ ਡਿਫ਼ਾਲਟ ਰੂਪ ਵਿੱਚ ਸਮਰੱਥ ਹੁੰਦਾ ਹੈ, ਇਸੇ ਲਈ ਇੱਕੋ ਕਾਰਪੋਰੇਟ ਨੈੱਟਵਰਕ ’ਤੇ ਦੋ ਮਸ਼ੀਨਾਂ ਵੱਖਰਾ ਵਿਵਹਾਰ ਕਰਦੀਆਂ ਹਨ। ਬਦਲਣ ਵਾਲੀ ਚੀਜ਼ ਬਿਲਡ ਨੰਬਰ ਹੈ, ਕਾਰਪੋਰੇਟ ਨੀਤੀ ਨਹੀਂ।

WSL ਨੈੱਟਵਰਕਿੰਗ ਗਾਈਡ ਉਸ ਮੋਡ ਅਤੇ ਇਸ ਦਾ ਸਮਰਥਨ ਕਰਨ ਵਾਲੇ ਸੰਸਕਰਣਾਂ ਦਾ ਵਰਣਨ ਕਰਦੀ ਹੈ। ਇਹ ਵਿਸ਼ੇਸ਼ਤਾ ਮਹੱਤਵਪੂਰਨ ਹੈ ਕਿਉਂਕਿ ਕਾਰਪੋਰੇਟ DNS ਨੀਤੀ ਆਮ ਤੌਰ ’ਤੇ Windows ਰਿਜ਼ੋਲਵਰ ਵਿੱਚ ਰਹਿੰਦੀ ਹੈ, ਅਤੇ Windows ਦਾ ਰਾਹ ਵਿਰਾਸਤ ਵਿੱਚ ਪਾਉਣ ਵਾਲੀ ਡਿਸਟਰੀਬਿਊਸ਼ਨ ਨੀਤੀ ਵੀ ਨਾਲ ਲੈਂਦੀ ਹੈ। ਜਨਤਕ ਰਿਜ਼ੋਲਵਰ ਨੂੰ ਪੁੱਛਣ ਵਾਲੀ ਡਿਸਟਰੀਬਿਊਸ਼ਨ ਕੋਲ ਨਿੱਜੀ ਨਾਮ ਤੱਕ ਕੋਈ ਰਾਹ ਨਹੀਂ ਹੁੰਦਾ, ਇਸ ਦੀ ਆਪਣੀ ਕਨਫਿਗਰੇਸ਼ਨ ਕਿੰਨੀ ਵੀ ਸਾਫ਼-ਸੁਥਰੀ ਦਿਖੇ। ਇਹੀ ਕਾਰਜਵਿਧੀ ਪੂਰੇ ਲੱਛਣ ਦੀ ਵਿਆਖਿਆ ਕਰਦੀ ਹੈ, ਅਤੇ ਇਹ ਵੀ ਦੱਸਦੀ ਹੈ ਕਿ ਜਨਤਕ-ਰਿਜ਼ੋਲਵਰ ਵਾਲਾ ਉਪਾਅ ਕਿਉਂ ਫੇਲ੍ਹ ਹੁੰਦਾ ਹੈ।

ਕੁਝ ਵੀ ਸੰਪਾਦਿਤ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਬਿਲਡ ਪੜ੍ਹੋ। ਨਵੀਂ ਇੰਸਟਾਲੇਸ਼ਨ ਤੋਂ ਕਾਪੀ ਕੀਤੀ ਸੈਟਿੰਗ ਇਸ ਗੱਲ ਦਾ ਸਬੂਤ ਨਹੀਂ ਕਿ ਪੁਰਾਣੀ ਇਸ ਨੂੰ ਲਾਗੂ ਕਰਦੀ ਹੈ। ਬਦਲਾਅ ਦੇ ਕੋਲ ਬਿਲਡ ਨੰਬਰ ਲਿਖੋ, ਕਿਉਂਕਿ ਦੋ ਮਸ਼ੀਨਾਂ ਵਿਚਕਾਰ ਫ਼ਰਕ ਲਗਭਗ ਹਮੇਸ਼ਾ ਸੰਸਕਰਣ ਹੁੰਦਾ ਹੈ, ਨੀਤੀ ਨਹੀਂ।

ਪੁਰਾਣੇ ਓਵਰਰਾਈਡ ਉਸ ਸਮੱਸਿਆ ਤੋਂ ਵੱਧ ਜੀਉਂਦੇ ਰਹਿੰਦੇ ਹਨ ਜਿਸ ਨੂੰ ਉਹਨਾਂ ਨੇ ਹੱਲ ਕੀਤਾ

ਪੁਰਾਣੇ ਤਰੀਕੇ ਬਣਾਈਆਂ ਗਈਆਂ ਰਿਜ਼ੋਲਵਰ ਫਾਈਲਾਂ ਨੂੰ ਅਸਮਰੱਥ ਕਰਦੇ ਸਨ, ਨੇਮਸਰਵਰ ਨੂੰ ਹਾਰਡਕੋਡ ਕਰਦੇ ਸਨ, ਜਾਂ ਫਾਈਲ ਨੂੰ ਅਟੱਲ ਗੁਣ ਨਾਲ ਲਾਕ ਕਰਦੇ ਸਨ। ਉਹ ਬਦਲਾਅ ਉਸ ਕਨੈਕਟੀਵਿਟੀ ਸਮੱਸਿਆ ਦੇ ਦੂਰ ਹੋਣ ਤੋਂ ਬਹੁਤ ਬਾਅਦ ਵੀ ਆਪਣੀ ਥਾਂ ’ਤੇ ਰਹਿੰਦੇ ਹਨ, ਅਤੇ ਆਮ ਤੌਰ ’ਤੇ ਇਹੀ ਕਾਰਨ ਹੁੰਦਾ ਹੈ ਕਿ ਨਵੀਂ ਸੈਟਿੰਗ ਕੁਝ ਨਾ ਕਰਦੀ ਦਿਖਦੀ ਹੈ। ਉਹ ਡਿਸਟਰੀਬਿਊਸ਼ਨ ਦੀ ਮੁੜ-ਸਥਾਪਨਾ ਤੋਂ ਬਾਅਦ ਵੀ shell ਪ੍ਰੋਫਾਈਲ ਦੇ ਰੂਪ ਵਿੱਚ ਟਿਕੇ ਰਹਿੰਦੇ ਹਨ, ਜੋ ਹਰ ਲੌਗਇਨ ’ਤੇ ਫਾਈਲ ਮੁੜ ਲਿਖਦੀ ਹੈ। ਆਖਰੀ ਵਾਲਾ ਲੱਭਣਾ ਸਭ ਤੋਂ ਔਖਾ ਹੈ, ਕਿਉਂਕਿ ਜਿਸ ਫਾਈਲ ਨੂੰ ਸਾਰੇ ਜਾਂਚਦੇ ਹਨ ਉਸ ਤੋਂ ਇਹ ਅਦਿੱਖ ਹੈ।

ਹੱਥ ਨਾਲ ਲਿਖੀ ਰਿਜ਼ੋਲਵਰ ਫਾਈਲ, ਉਸ ’ਤੇ ਅਟੱਲ ਗੁਣ, ਅਤੇ ਉਸ ਨੂੰ ਮੁੜ ਲਿਖਣ ਵਾਲੀ ਸਟਾਰਟਅੱਪ ਸਕ੍ਰਿਪਟ ਲੱਭੋ। ਸੰਪਾਦਨ ਤੋਂ ਪਹਿਲਾਂ ਅਟੱਲ ਫਲੈਗ ਜਾਂਚੋ, ਕਿਉਂਕਿ ਲਾਕ ਕੀਤੀ ਫਾਈਲ ਵਿੱਚ ਲਿਖਣਾ ਇਜਾਜ਼ਤ ਦੀ ਸਮੱਸਿਆ ਵਾਂਗ ਪੜ੍ਹੇ ਜਾਣ ਵਾਲੇ ਢੰਗ ਨਾਲ ਫੇਲ੍ਹ ਹੁੰਦਾ ਹੈ। ਫਿਰ shell ਪ੍ਰੋਫਾਈਲ ਜਾਂਚੋ, ਕਿਉਂਕਿ ਉੱਥੋਂ ਦੀ ਸਕ੍ਰਿਪਟ ਤੁਹਾਡੇ ਸੁਧਾਰ ਤੋਂ ਕੁਝ ਸਕਿੰਟਾਂ ਵਿੱਚ ਪੁਰਾਣੀ ਸਮੱਗਰੀ ਵਾਪਸ ਲਿਆਉਂਦੀ ਹੈ।

ਓਵਰਰਾਈਡ ਹਟਾਉਣ ਦੇ ਨਤੀਜੇ ਹੁੰਦੇ ਹਨ, ਇਸ ਲਈ ਲਿਖੋ ਕਿ ਤੁਸੀਂ ਕੀ ਹਟਾਇਆ ਅਤੇ ਕਿਉਂ। ਜਿਸ ਡਿਸਟਰੀਬਿਊਸ਼ਨ ਨੂੰ ਸੱਚਮੁੱਚ ਕਿਸੇ ਹੋਰ ਮਕਸਦ ਲਈ ਸਥਿਰ ਰਿਜ਼ੋਲਵਰ ਚਾਹੀਦਾ ਹੈ ਉਹ ਬਣਾਈ ਗਈ ਫਾਈਲ ਵਾਪਸ ਆਉਣ ’ਤੇ ਟੁੱਟ ਜਾਵੇਗੀ।

ਦੋ ਫਾਈਲਾਂ, ਦੋ ਵੱਖਰੀਆਂ ਭੂਮਿਕਾਵਾਂ

ਦੋਵੇਂ ਕਨਫਿਗਰੇਸ਼ਨ ਫਾਈਲਾਂ ਵੱਖਰੀਆਂ ਥਾਵਾਂ ’ਤੇ ਰਹਿੰਦੀਆਂ ਹਨ ਅਤੇ ਵੱਖਰੀਆਂ ਚੀਜ਼ਾਂ ਨਿਯੰਤਰਿਤ ਕਰਦੀਆਂ ਹਨ, ਅਤੇ ਇਹਨਾਂ ਨੂੰ ਮਿਲਾਉਣ ਨਾਲ ਗਲਤ ਪਰਤ ’ਤੇ ਲਾਗੂ ਹੋਣ ਵਾਲੇ ਸੰਪਾਦਨ ਬਣਦੇ ਹਨ। Windows ਪਾਸੇ ਦੀ ਫਾਈਲ ਵਰਚੁਅਲ ਮਸ਼ੀਨ ਦੇ ਗੁਣ ਸੈੱਟ ਕਰਦੀ ਹੈ, ਜਦਕਿ ਡਿਸਟਰੀਬਿਊਸ਼ਨ ਪਾਸੇ ਦੀ ਫਾਈਲ ਤੈਅ ਕਰਦੀ ਹੈ ਕਿ ਉਹ ਡਿਸਟਰੀਬਿਊਸ਼ਨ ਆਪਣੀ ਰਿਜ਼ੋਲਵਰ ਕਨਫਿਗਰੇਸ਼ਨ ਕਿਵੇਂ ਬਣਾਉਂਦੀ ਹੈ। ਕੋਈ ਵੀ ਦੂਜੀ ਨੂੰ ਓਵਰਰਾਈਡ ਨਹੀਂ ਕਰਦੀ, ਇਸ ਲਈ ਦੋਵਾਂ ਨੂੰ ਸਹਿਮਤ ਹੋਣਾ ਪੈਂਦਾ ਹੈ।

ਜਿਸ ਇੰਸਟਾਲੇਸ਼ਨ ਵਿੱਚ ਇਹ ਵਿਸ਼ੇਸ਼ਤਾ ਸਮਰਥਿਤ ਹੈ, ਉਸ ਲਈ Windows ਪਾਸੇ ਦਾ ਟੁਕੜਾ ਛੋਟਾ ਹੈ। ਉਸ ਪਾਸੇ ਦਾ ਪੂਰਾ ਬਦਲਾਅ ਇਹੀ ਹੈ:

[wsl2]
dnsTunneling=true

ਉਹ ਟੁਕੜਾ Windows ਵਰਤੋਂਕਾਰ ਪ੍ਰੋਫਾਈਲ ਵਿੱਚ ਜਾਂਦਾ ਹੈ ਅਤੇ ਇੱਕ ਡਿਸਟਰੀਬਿਊਸ਼ਨ ਦੀ ਥਾਂ ਵਰਚੁਅਲ ਮਸ਼ੀਨ ’ਤੇ ਲਾਗੂ ਹੁੰਦਾ ਹੈ। ਸੁਰੰਗ ਲਈ ਇਹ ਵੀ ਲੋੜੀਂਦਾ ਹੈ ਕਿ ਡਿਸਟਰੀਬਿਊਸ਼ਨ ਨੇ ਰਿਜ਼ੋਲਵਰ ਨਿਰਮਾਣ ਅਸਮਰੱਥ ਨਾ ਕੀਤਾ ਹੋਵੇ, ਇਸ ਲਈ ਡਿਸਟਰੀਬਿਊਸ਼ਨ ਪਾਸੇ ਦੀ ਫਾਈਲ ਨੇ ਇਸ ਵਿਵਹਾਰ ਨੂੰ ਆਪਣੀ ਥਾਂ ਰਹਿਣ ਦੇਣਾ ਚਾਹੀਦਾ ਹੈ। ਇੱਕ ਨੂੰ ਦੂਜੇ ਤੋਂ ਬਿਨਾਂ ਬਦਲੋ ਅਤੇ ਮੋਡ ਚੁੱਪਚਾਪ ਕੁਝ ਨਹੀਂ ਕਰਦਾ, ਅਤੇ ਇਹ ਸੁਧਾਰ ਟੁੱਟਿਆ ਹੋਇਆ ਦੱਸੇ ਜਾਣ ਦਾ ਸਭ ਤੋਂ ਆਮ ਢੰਗ ਇਹੀ ਹੈ। ਦੋਵੇਂ ਫਾਈਲਾਂ ਇੱਕੋ ਸੈਸ਼ਨ ਵਿੱਚ ਜਾਂਚੋ, ਕਿਉਂਕਿ ਹਫ਼ਤਿਆਂ ਦੇ ਅੰਤਰ ਨਾਲ ਕੀਤੇ ਦੋ ਸੰਪਾਦਨ ਅਜਿਹੇ ਦੋ ਸੰਪਾਦਨ ਹਨ ਜਿਨ੍ਹਾਂ ਦਾ ਕੋਈ ਜ਼ਿੰਮਾ ਨਹੀਂ ਲੈ ਸਕਦਾ।

ਮੁੜ ਸ਼ੁਰੂ ਕਰੋ, ਫਿਰ ਦੋਵੇਂ ਪਾਸਿਆਂ ਤੋਂ ਪੁੱਛੋ

ਇਹ ਸੈਟਿੰਗਾਂ ਵਾਤਾਵਰਣ ਸ਼ੁਰੂ ਹੋਣ ਵੇਲੇ ਪੜ੍ਹੀਆਂ ਜਾਂਦੀਆਂ ਹਨ, ਇਸ ਲਈ ਚੱਲ ਰਹੀ ਡਿਸਟਰੀਬਿਊਸ਼ਨ ਅੰਦਰ ਨਵਾਂ shell ਇਹਨਾਂ ਨੂੰ ਮੁੜ ਲੋਡ ਨਹੀਂ ਕਰੇਗਾ। shell ਮੁੜ ਸ਼ੁਰੂ ਕਰਨ ਦੀ ਥਾਂ ਵਾਤਾਵਰਣ ਬੰਦ ਕਰੋ, ਅਤੇ ਪਹਿਲਾਂ ਚੱਲ ਰਿਹਾ ਕੋਈ ਵੀ ਕੰਮ ਸੰਭਾਲੋ ਕਿਉਂਕਿ ਹਰ ਡਿਸਟਰੀਬਿਊਸ਼ਨ ਇਸ ਦੇ ਨਾਲ ਬੰਦ ਹੋ ਜਾਂਦੀ ਹੈ। ਸਿਰਫ਼ ਇਹ ਛੋਟ ਬਦਲਾਅ ਦਾ ਕੋਈ ਅਸਰ ਨਾ ਹੋਣ ਦੀਆਂ ਜ਼ਿਆਦਾਤਰ ਰਿਪੋਰਟਾਂ ਦੀ ਵਿਆਖਿਆ ਕਰਦੀ ਹੈ।

ਫਿਰ ਦੋਵੇਂ ਪਾਸਿਆਂ ਨੂੰ ਉਹੀ ਸਵਾਲ ਪੁੱਛੋ। ਆਉਟਪੁੱਟ ਇਹ ਵੀ ਦਿਖਾਉਂਦਾ ਹੈ ਕਿ ਡਿਸਟਰੀਬਿਊਸ਼ਨ ਆਖਿਰ ਕਿਹੜੇ ਰਿਜ਼ੋਲਵਰ ਨਾਲ ਰਹੀ:

wsl.exe --shutdown
wsl.exe -e sh -c 'cat /etc/resolv.conf'
wsl.exe -e sh -c 'getent hosts files.corp.example'
wsl.exe -e powershell -Command 'Resolve-DnsName files.corp.example'

ਪਹਿਲਾ ਕਮਾਂਡ ਵਾਤਾਵਰਣ ਖਤਮ ਕਰਦਾ ਹੈ, ਦੂਜਾ ਦਿਖਾਉਂਦਾ ਹੈ ਕਿ ਡਿਸਟਰੀਬਿਊਸ਼ਨ ਹੁਣ ਕਿਹੜਾ ਰਿਜ਼ੋਲਵਰ ਵਰਤਦੀ ਹੈ, ਅਤੇ ਆਖਰੀ ਦੋ ਹਰ ਪਾਸੇ ਨੂੰ ਉਹੀ ਸਵਾਲ ਪੁੱਛਦੇ ਹਨ। ਸੈਟਿੰਗ ਦੀ ਸਥਿਤੀ ਨਹੀਂ, ਜਵਾਬਾਂ ਦੀ ਤੁਲਨਾ ਕਰੋ। ਦੋਵੇਂ ਫਾਈਲਾਂ ਸਹੀ ਹੋਣ ’ਤੇ ਵੀ ਸਾਫ਼ ਮੁੜ-ਸ਼ੁਰੂਆਤ ਤੋਂ ਬਾਅਦ ਫੇਲ੍ਹ ਹੋਣ ਵਾਲੀ ਕਿਊਰੀ ਕਾਰਪੋਰੇਟ ਰਿਜ਼ੋਲਵਰ ਨੀਤੀ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦੀ ਹੈ, ਅਤੇ ਉਸ ਗੱਲਬਾਤ ਦਾ ਮਾਲਕ ਹੋਰ ਹੈ।

ਸੰਬੰਧਿਤ ਲੇਖ