Copia di un file da una condivisione di rete (Windows server) ad un'altra (Samba server).

Il file non viene copiato, nella cartella destinazione viene creato un file con il nome corretto, ma dimensione zero.

La prima evidenza del problema è il seguente messaggio di avviso; Windows segnala che il file che si intende copiare potrebbe essere dannoso (in inglese il messaggio dovrebbe essere “This file came from another computer and might be blocked to help protect this computer”):

Se l'utente comunque accetta di effettuare l'operazione, si ottiene un errore successivo. In questo caso l'errore è abbastanza incomprensibile in quanto la cartella destinazione NON conteneva alcun file con lo stesso nome prima dell'operazione di copia:

Non importa quale opzione sceglie l'utente, è impossibile procedere con l'operazione di copia. In qualche circostanza è possibile che appaia anche un terzo messaggio di errore che fa riferimento ad una non meglio precisata autorizzazione necessaria:

Anche in questo caso ogni opzione fornita all'utente è destinata a fallire. Al termine del tentativo nella cartella destinazione troviamo il file, ma con lunghezza zero.

Sembra proprio che la causa del problema è la creazione di un Alternate Data Stream aggiuntivo al file origine, il nome assegnato a tale stream è Zone.Identifier. È possibile evidenziare questo comportamento copiando il file dalla medesima origine, share Windows server, sul disco locale. Negli esempi che seguono il file di prova è un documento PDF con nome ze1.pdf.

Conviene eseguire una PowerShell invece di un semplice prompt dei comanid cmd per ispezionare e manipolare il file. Con il comando Get-Item è possibile verificare che il file copiato ha un Alternate Data Stream:

PS C:\Users\user\Desktop\prova> Get-Item ze1.pdf -stream *

PSPath        : Microsoft.PowerShell.Core\FileSystem::C:\Users\user\Desktop\prova\ze1.pdf::$DATA
PSParentPath  : Microsoft.PowerShell.Core\FileSystem::C:\Users\user\Desktop\prova
PSChildName   : ze1.pdf::$DATA
PSDrive       : C
PSProvider    : Microsoft.PowerShell.Core\FileSystem
PSIsContainer : False
FileName      : C:\Users\user\Desktop\prova\ze1.pdf
Stream        : :$DATA
Length        : 207401

PSPath        : Microsoft.PowerShell.Core\FileSystem::C:\Users\user\Desktop\prova\ze1.pdf:Zone.Identifier
PSParentPath  : Microsoft.PowerShell.Core\FileSystem::C:\Users\user\Desktop\prova
PSChildName   : ze1.pdf:Zone.Identifier
PSDrive       : C
PSProvider    : Microsoft.PowerShell.Core\FileSystem
PSIsContainer : False
FileName      : C:\Users\user\Desktop\prova\ze1.pdf
Stream        : Zone.Identifier
Length        : 26

Il data stream Zone.Identifier è un semplice file di testo, con Notepad è possibile ispezionarne il contenuto:

notepad ze1.pdf:Zone.Identifier

Questo è il contenuto che risulta nel nostro caso:

[ZoneTransfer]
ZoneId=3

Questo evidenzia la probabile causa primara dell'anomalia: il server Windows da cui è stato copiato il file risiede nella medesima rete locale del client Windows utilizzato per i test, il codice 3 invece sta ad indicare la rete Internet non sicura:

Se si tratta di copiare un singolo o pochi file. è possibile aggirare il problema in questo modo:

1. Copiare il file dalla condivisione Windows al disco locale.
2. Rimuovere l'ADS utilizzando la PowerShell.
3. Copiare il file nella destinazione Samba.

Molte pagine internet (e in particolare questo articolo Microsoft) indicano come soluzione al problema il cambio di una policy di gruppo. Si esegue il programma Editor Criteri di gruppo locali e si individua la sequente policy:

• Editor Criteri di gruppo locali
  • Configurazione utente
    • Modelli amministrativi
      • Componenti di Windows
        • Gestione allegati
          • Non mantenere informazioni sull'area nei file allegati

L'impostazione predefinita per tale policy è Non configurato, è possibile modificare il valore in Abilitato.

Putroppo nel nostro caso non si è risolto il problema; probabilmente l'azione da inibire non è il mantenere le informazioni sull'area di origine del file, ma proprio la creazione di tale informazione.

Un'altra soluzione spesso indicata su Internet è la modifica di una chiave del Registry. Si esegue RegEdit e si naviga fino al percorso:

Computer\HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Policies\Attachments

quindi si crea/modifica la chiave DWORD 32-bit SaveZoneInformation e la si imposta a 1.

Putroppo anche in questo caso la soluzione non ha funzionato. Si è provato anche a impostare la chiave al valore zero, ma il risultato non è cambiato. Probabilmente la copia di un file dalla condivisione Windows non rientra nelle policy di attachments.

Vediamo cosa succede se si copia un file che abbia un ADS dal disco locale allo share Samba. Creiamo un file di testo prova-con-ads.txt, quindi dalla riga di comando associamo ad esso un ADS:

echo "Questo è un ADS" > prova-con-ads.txt:invisibile.txt

Quando si tenta di copiare il file sulla condivisione Samba un messaggio di avviso segnala che alcune proprietà non saranno copiate nella cartella destinazione:

È possibile procedere con la copia, ma l'ADS non verrà copiato.

• [Fix] ‘This File came from Another Computer and might Blocked’
• Alternate Data Streams: i file invisibili di Windows
• Can't copy *some* files with alternate data streams from Windows to Samba 4.7.6
• Remove alternative data stream using powershell
• Why Is Windows 10 Blocking Downloads?
• Information about the Attachment Manager in Microsoft Windows
• Security: This file came from another computer and might be blocked to help protect this computer.