VPN ਫਾਈਲ ਸ਼ੇਅਰਾਂ ਲਈ BranchCache: ਕਦੋਂ ਮਦਦ ਕਰਦਾ ਹੈ, ਕਦੋਂ ਨਹੀਂ

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

ਉਹੀ ਸ਼ੇਅਰ, ਤਿੰਨ ਵੱਖਰੀਆਂ ਸ਼ਿਕਾਇਤਾਂ

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

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

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

ਵੰਡਿਆ ਕੈਸ਼: VPN ਪੂਲ ਬ੍ਰਾਂਚ LAN ਨਹੀਂ ਹੈ

ਵੰਡੇ ਮੋਡ ਵਿੱਚ, ਕਲਾਇੰਟ ਕੰਪਿਊਟਰ ਕੈਸ਼ ਕੀਤੀ ਸਮੱਗਰੀ ਆਪਸ ਵਿੱਚ ਸਾਂਝੀ ਕਰਦੇ ਹਨ, ਅਤੇ Microsoft ਉਸ ਮੋਡ ਨੂੰ ਇੱਕ ਸਬਨੈੱਟ ਅੰਦਰ ਕੰਮ ਕਰਨ ਵਜੋਂ ਦਰਜ ਕਰਦਾ ਹੈ। VPN ਕਲਾਇੰਟ ਪੂਲ ਉਸ ਅਰਥ ਵਿੱਚ ਸਬਨੈੱਟ ਨਹੀਂ ਹੈ, ਭਾਵੇਂ ਸਾਰੇ ਪਤੇ ਲਗਾਤਾਰ ਦਿਸਦੇ ਹੋਣ: ਪੀਅਰ ਖੋਜ, ਕਲਾਇੰਟ-ਤੋਂ-ਕਲਾਇੰਟ ਪਹੁੰਚਯੋਗਤਾ ਅਤੇ ਕੈਸ਼ ਡੇਟਾ ਬਦਲਣ ਦੀ ਇਜਾਜ਼ਤ ਵੱਖਰੇ ਸਵਾਲ ਹਨ, ਅਤੇ ਆਮ ਰਿਮੋਟ-ਐਕਸੈਸ ਡਿਜ਼ਾਈਨ ਤਿੰਨਾਂ ਨੂੰ ਨਹੀਂ ਕਹਿੰਦਾ।

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

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

ਹੋਸਟਿਡ ਕੈਸ਼: ਪਲੇਸਮੈਂਟ ਤੈਅ ਕਰਦੀ ਹੈ ਕਿ ਮਦਦ ਕਰੇਗੀ ਜਾਂ ਨਹੀਂ

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

ਇਸ ਨੂੰ ਪਾਠਕਾਂ ਦੇ ਨੇੜੇ ਰੱਖੋ, ਇਸ ਨੂੰ ਮਾਲਕ ਦਿਓ, ਅਤੇ ਇਸ ਦੀ ਡਿਸਕ ਪੂਰੀ ਸ਼ੇਅਰ ਲਈ ਨਹੀਂ, ਕੰਮਕਾਜੀ ਸੈੱਟ ਲਈ ਮਾਪੋ। Microsoft BranchCache ਸੰਖੇਪ ਦੋਵੇਂ ਮੋਡ ਅਤੇ ਕਲਾਇੰਟ ਵਿਵਹਾਰ ਦੱਸਦਾ ਹੈ, ਉਹ ਹਿੱਸਾ ਵੀ ਜੋ ਲੋਕ ਭੁੱਲ ਜਾਂਦੇ ਹਨ: ਕੈਸ਼ ਕੀਤਾ ਡੇਟਾ ਵਰਤਣ ਤੋਂ ਪਹਿਲਾਂ ਕਲਾਇੰਟ ਅਜੇ ਵੀ ਅਧਿਕਾਰਤਾ ਅਤੇ ਸਮੱਗਰੀ ਜਾਣਕਾਰੀ ਲਈ ਸਰੋਤ ਨਾਲ ਸੰਪਰਕ ਕਰਦੇ ਹਨ।

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

Enable-BCHostedServer -RegisterSCP
Get-BCStatus | Select-Object BranchCacheIsEnabled, ClientMode, HostedCacheServerList

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

Enable-BCHostedClient -ServerNames cache1.corp.example -UseSCP
Get-BCStatus | Select-Object BranchCacheIsEnabled, ClientMode

ਅਜੇ ਵੀ ਸਰੋਤ ਤੱਕ ਕੀ ਪਹੁੰਚਦਾ ਹੈ

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

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

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

ਦੋ ਪ੍ਰਾਪਤੀਆਂ ਅਤੇ ਇੱਕ ਅੱਪਲੋਡ ਨਾਲ ਇਸ ਨੂੰ ਸਵੀਕਾਰ ਕਰੋ

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

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

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