Zone.Identifier Files when copying from Windows to WSL filestructure

[Kai-Richardson]

• Windows build number: Microsoft Windows [Version 10.0.18990.1]

uname -a produces: Linux 4.19.67-microsoft-standard #1 SMP Sun Aug 18 13:37:54 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

• What you're doing and what's happening: This occurs when using Windows Explorer.

  1. Download a file from an online resource into a windows folder. For example, this image downloaded into your Downloads folder.
  2. Drag/Copy/Move said file into a WSL directory.
  3. Notice the file that is also created, named like "movedfile•Zone.Identifier", but instead of a bullet it is the character 0xF03A (Unicode: U+F03A). It does render like a bullet in Windows Explorer though.

• What's wrong / what should be happening instead: The filename•Zone.Identifier NFTS files should not be created.

Contents of the Zone Identifier file are as to be expected, my sample having the contents:

[ZoneTransfer]
ZoneId=3
ReferrerUrl=https://i.imgur.com/7uEP6ds.png
HostUrl=https://i.imgur.com/7uEP6ds.png

Image:

[riverar]

@bitcrazed Ok.

[TasinAhmed]

Any update on this? This is the only issue holding me back from going back to WSL2

[riverar]

@TasinAhmed Is it really holding you back though?

[bitcrazed]

@Kai-Richardson @TasinAhmed et al:

The team are exploring this issue.

However, there is a work around for this issue: Unblock files downloaded download from the public internet to your PC to remove the mark of the web, before trying to copy said files into WSL.

⚠ WARNING: ONLY UNBLOCK FILES THAT YOU HAVE VERIFIED AND CAN BE TRUSTED! ⚠

Below, for example, is a screenshot of two File Explorers (top) and two terminal panes (bottom). On the left is Windows, on the right is Ubuntu in WSL.

I locally created a simple image using Paint.net and saved it as test.jpg & test.png.

I also downloaded an image from the public internet which, as can be seen in the PowerShell Terminal-pane (bottom left) is the only file in the folder which is branded with the 'mark of the web' ADS stream. I then copied this file, opened it's file properties and clicked the checkbox at the bottom of the file properties dialog to "unblock" the file. This removes the 'mark of the web' ADS stream from the copied file (but not the original).

I copied these four files to my Ubuntu home folder by copying and pasting via File Explorer.

As you can see, only the original image file downloaded from the public internet branded with 'the mark of the web' ADS stream is accompanied by an offending ...Zone.Identifier file.

HTH.

[GavinRay97]

Not to be tiresome because I know this thread has been open a while and you folks are looking into it, but this phenomenon is a bit unpleasant

Would there be any possibility of a WSL config option for "automatically delete ZoneIdentifier files when copying between hosts"? This is kind of a duct-tape fix, but at least wouldn't be an issue anymore.

Thank you =)

[omarbadran]

I think this might have been resolved with the latest update. I copied some files today and did not encounter the problem, which I used to every time I copied any file from Windows to WSL. I'm on the insider preview version so I'm not sure if this has reached the mainline version yet.

[therealkenc]

Thanks Omar. I'll second, based on the repro from October. /fixed 20279 (or thereabouts)

[ghost]

This bug or feature request originally submitted has been addressed in whole or in part. Related or ongoing bug or feature gaps should be opened as a new issue submission if one does not already exist.

Thank you!

[GavinRay97]

I think this might have been resolved with the latest update. I copied some files today and did not encounter the problem, which I used to every time I copied any file from Windows to WSL. I'm on the insider preview version so I'm not sure if this has reached the mainline version yet.

Ahh okay @omarbadran. I'm on Insiders, though maybe I need to update

[wespiard]

I have this problem when moving files from Windows to WSL via Windows Explorer GUI. If I use the "mv" command from within my Ubuntu shell, e.g., mv /mnt/c/<path_to_windows_file> /<path_to_WSL_directory> then I don't get the ZoneIdentifier files.

By doing this, I don't have to change security options.

Not sure if this helps or not, but thought I'd mention it.

[shyney7]

Im still getting this issue. Im on Windows: Edition Windows 10 Education Version 20H2 Installiert am ‎28.‎05.‎2020 Betriebssystembuild 19042.804 Windows Feature Experience Pack 120.2212.551.0 My Ubuntu Linux Kernel is: Linux 5.4.72-microsoft-standard-WSL2

Edit: ok it seems I need Windows Insider Edition that I cant get since my Windows is managed by my company... :(

[ertomas]

It just happened to me again yesterday. I saved an Outlook attachtment directly to  \\wsl$\distro and got the zone identifier file. Windows 20H2/Ubuntu 20.04  De: MarcelEnviado: jueves, 25 de febrero de 2021 10:07 a. m.Para: microsoft/WSLCC: ertomas; CommentAsunto: Re: [microsoft/WSL] Zone.Identifier Files when copying from Windows to WSL filestructure (#4609) Im still getting this issue.Im on Windows:Edition Windows 10 EducationVersion 20H2Installiert am ‎28.‎05.‎2020Betriebssystembuild 19042.804Windows Feature Experience Pack 120.2212.551.0My Ubuntu Linux Kernel is: Linux 5.4.72-microsoft-standard-WSL2—You are receiving this because you commented.Reply to this email directly, view it on GitHub, or unsubscribe. 

[TasinAhmed]

I still have this issue. I am running:

[j0nnybrav079]

I can reproduce this error, too. But not every time, if I try it about 5-10 times, it will write at least one Zone.Identifier file

[MatthewABrantley]

Still happening for me

Win 10 OS Build 19041.867 & WSL 2

[NiklasBr]

@therealkenc this still happens in beta builds, it appears the closing of this bug was premature.

[domainfun]

I've just learned about these undesired "...:Zone.Identifier" files when copying/moving files from C:\> to Linux on WSL2 (such as to \\wsl$\...). Could this issue please be resolved, as this is actually a security issue for us.

It's all too easy to disclose the URL where we may have downloaded a file from. All it needs is an rsync from WSL to some other (backup) location and these "...:Zone.Identifier" files quickly show up in unexpected places.

Many thanks.

[sanderkooger]

You could use ssh to copy files as workarround

[AnthonyCost]

I've still had this issue for months, I've been searching everywhere for a solution but hopefully they can patch this soon.

[Asterovim]

same problem. Please help us.

[therealkenc]

same problem. Please help us.

If anyone is still experiencing the Zone.Identifier problem on 20279 or better, please post the repro steps and screencap similar to above including cmd.exe /c ver. 20xxx did not roll in 21h1.

[phpguru]

@therealkenc

still experiencing on 20279 or better

20279 is a version number of what? And where do I find mine?

[NiklasBr]

20279 is a version number of what? And where do I find mine?

It's a Windows Preview build version.

You can find your build version in Settings: System: About

[therealkenc]

You can find your build version in Settings: System: About

....or cmd.exe /c ver

[StarpTech]

Issue still exists:

Repro:

1. Download https://github.com/ogham/exa/releases/download/v0.10.1/exa-linux-x86_64-v0.10.1.zip
2. Open explorer and navigate to ~ on the WSL host.
3. Extract the /bin/exa file to a new directory in ~.
4. exa and exaZone.Identifier are created.

Version: Microsoft Windows [Version 10.0.19042.985]

[riverar]

@StarpTech As @therealkenc implies above, this appears to be fixed in 20279+ (i.e. Insider builds).

[FizzBuzz791]

Seems to have broken again, I'm seeing this in version: Microsoft Windows [Version 10.0.22471.1000]

[Asterovim]

same problem with windows 11 and lastest WSL2.

[synapp009]

I'm getting this problem when I use Visual Studio Code and want to curl a file to my (linux) server to convert filetypes and print the new file again back to the filesystem. It seems like the original file gets replaced by the zone.identifier file and another weirt 1kb empty file with original filetype.

I'm on Windows 11, WSL 2

[NiklasBr]

It's exactly two years since this issue was first reported, since then Windows 11 has been released, and even though it was allegedly fixed in December 2020 it still persists.

[aravindvnair99]

I think starting a new issue is better as I don't think closed issues are being monitored.

[mateusrachid]

7456

[rehanhaider]

Can confirm this issues still exists on Windows 11 while downloading a file using browser directly onto WSL.

[NiklasBr]

@rehanhaider Microsoft (@therealkenc) closed this issue as apparently fixed in Dec 2020, please also add your voice to #7456 which is the follow-up issue.

[SheepReaper]

7456 is the new version of this issue. Please go there and upvote the OP.

[Kryuko]

Issue still exists with latest w10 and wsl2 build. Edit: In the Group Policy editor, go to User Configuration, Administrative Templates, Windows Components, Attachment Manager, and enable Do not preserve zone information in file attachments.

[equiman]

I've enabled the Do not preserve zone information in file attachments but it is still creating these annoying *:ZoneIdentifier files. While this can be solved. I've created an alias to run after copying files.

alias rzi="rm -rf **/*Zone.Identifier"

Also, I always add **/*Zone.Identifier to .gitignore files on my project.

[NiklasBr]

@equiman see #7456

This issue was closed despite it not being fixed.

[JoshuaJarman]

2022-05-25 Win11 Pro Insiders 25120rs_prerelease.220513-1246

Problem still persists. 😢 such a pita to have to delete 2 files for every 1 file copied.

[FossPrime]

@equiman see #7456

This issue was closed despite it not being fixed.

Very much so in the latest Windows 11 with a brand new high-end laptop. This issue caused me to send a customer a corrupt zip file that did not validate in their system as the bullet point separator is an invalid character with their file system and the zip fails to extract. This is a huge critical regression grade bug.

The group policy workaround does not work for everyone as that tool is missing from Home Editions and Corporately managed windows, it's also a PITA to remember to do that every time you wipe windows, which for travelers can be weekly.

One solution is to add a toggle to disable directory corruption in the new Windows 11 "Developer settings", ie Privacy & security > For developers. Another solution could be to add a check to disable transfer of these files as the file system effectively doesn't support them....

P.S. This type of thing is what drove the exodus of developers from Windows to MacOS/Linux in the early 2010's.

Update: changing the zone info group policy does not stop the files from being generated and causes even more problems than are described in this thread. Best workaround for now is to use GUI linux apps instead of windows ones. This issue is expediting my switch to Linux despite a dozen compatibility issues with my hardware.

[OliverKK]

Helped me to get rid of the files: find . -name "*:Zone.Identifier" -type f -delete

[rafaelgildin]

Helped me to get rid of the files: find . -name "*:Zone.Identifier" -type f -delete That worked for me. Thanks @OliverKK

[bmlyon]

This is still happening. It would be nice to get this fixed so we don't have to remember to do the workarounds every time before we commit in Git.

[BarsMonster]

Still happens in Windows 11 (10.0.22621.674), and WSL2 kernel 5.15.68.1

[rafaelgildin]

Still happens in Windows 11 (10.0.22621.674), and WSL2 kernel 5.15.68.1

@BarsMonster Try to update windows 11. It disappeared to me. If it doesn't work try running this : find . -name "*:Zone.Identifier" -type f -delete

[NiklasBr]

We have now celebrated the third birthday of this issue and it still happens! 🥳 🎊

[SheepReaper]

I'm not convinced that this is a bug. This is the expected behavior of the ADS when downloading to a Windows share where the filesystem isn't ntfs. You're interacting with the share if you're using windows explorer to download to a wsl path. You don't see this if for example you perform file operations from within wsl or curl, but that's also expected. If you really hate the existence of those files, don't drag and drop through explorer or copy into the share. Alternatively disable the preservation of zone data via local policy. I really don't see M$ making an exception for a "magic" share. The policy you want is User Configuration\Policies\Administrative Templates\Windows Components\Attachment Manager\Do not preserve zone information in file attachments (set it to enabled)

[riverar]

@SheepReaper As mentioned in 2019, neither Windows or Linux support ·Zone.Identifier (or any other ADS) so seems pointless to generate. This was fixed in an Insider build but appears to have regressed.

@bitcrazed Can you re-open and assist here?

@therealkenc Can you re-open this?

[SheepReaper]

Ntfs supports Alternate Data Streams. https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-fscc/6e3f7352-d11c-4d76-8c39-2516a9df36e8 windows supports ADS. Explorer is sending all streams. The share fs (ext4) does not. Rather than losing information, the default behavior is to create the zone identifier file. Between wsl 1 and 2 the way to access your Linux file systems from windows was replaced with a normal Windows share. I don't know that this has ever worked the way you expect in wsl2. This is default behavior for ADS on windows...

[riverar]

@SheepReaper I understand NTFS ADS (see posts I linked to), but my point is that after being copied into \\WSL$, these · prefaced files are created. These files are not useful for any OS, so begs the question why they're created to begin with. It seems Microsoft agreed as they previously fixed the issue.