Open ameya-jain opened 2 years ago
Is there a workaround for this?
Is there a workaround for this?
I usually use VS Code and is connected to my WSL. Instead of directly downloading the files from the browser to WSL, I download to windows, open the WSL folder in VS Code and then drag and drop the files from windows to VS Code. This seems to not bring the Zone.Identifier files.
I download to windows, open the WSL folder in VS Code and then drag and drop the files from windows to VS Code.
That's another step though, I think deleting the zone identifier file is less work since you only have to delete it at the end of your work, not every time you download. You can technically even keep it and just add it to .gitignore but it would be cool if you could disable generating the file completely, or just not generate it if it's empty anyway
I can confirm this issue still exists on Windows 11, even though it was supposed to be fixed. Steps to reproduce are
<download-file-name>:Zone.Identifier
I'm also still seeing this in Windows 11, any time I download a file and copy it over to WSL via File Explorer, along comes a :Zone.Identifier
.
As the filer of the original issue, I can confirm this is still not fixed for either Windows 10 or Windows 11. Exact same reproduction steps I outlined here still work:
- Navigate to an image url.
- Right click and Save Image As
- Choose location on my Windows NTFS C: Drive, such as
C:\Users\zekai\Desktop
- Drag (Click and hold) or copy/paste (CTRL+C & CTRL+V) PNG file to a WSL filespace, such as
\\wsl$\Ubuntu\home\cassini\github
- Nothing appears at first, but click the refresh button on explorer.exe in the top right.
- Notice new Zone.Identifier file.
Problem arised for me when I went from my Windows 10 Pro N to a clean install of Windows 11 Pro N. I thought the issue was me switching my daily driving wsl distro from Ubuntu to Manjaro but after installing Ubuntu, the problem is also there. So the culprit must be my new Win11 install.
I could spin up my old Win10 to see what were my config (I'm pretty sure Windows Defender was deactivated). I had to activate TPM for Win11, other than that my hardware stayed the same.
Let me know if replugging my Win10 drive to test and gather the config differences is something that could help.
Side note: ZoneIdentifier files are also created when copying from Manjaro to Ubuntu via explorer.exe.
Having this problem in Windows 10 Pro. Copied a file from one File Explorer window to another, where the first one was my Downloads directory on the Windows side and the second one was a WSL 2 directory.
I was able to delete the file via VS Code's GUI after I closed all my File Explorer windows (before closing them, it said "this file is in use" etc). I wasn't able to delete the file from the WSL 2 terminal. It was as if the WSL 2 terminal couldn't target the file using the rm
command. And rm *Identifier
said an error like "not a file".
It's funny how the original issue was closed as "fixed" when the supposed fix never landed outside of insider/preview builds.
this issue still exists in windows 11. please fix this ASAP
Still happens here as well, on Windows 11
The Zone.Identifier file has host and referer urls, which can contain query string access tokens. While any decent web service should expire tokens, potentially having plaintext credentials lying around in files is... a little dodgy.
Would be nice for this to be resolved.
This issue also happens on my Win 10 build 19042 & WSL 2 running Ubuntu.
The issue still persists on Window 11 21H2.
Can confirm, happens on:
Edition Windows 11 Pro Version 21H2 OS build 22000.493 Experience Windows Feature Experience Pack 1000.22000.493.0
Downloading a file from Microsoft Edge directly to the WSL location or copying it from Downloads does the same thing for me.
Confirm. Happen to me with Windows 10 Pro and WSL2
Can confirm on
Only way I've found to move/copy files to WSL without getting Zone.Identifiers is my moving/copying from within WSL (cp
/mv
/etc).
Can confirm the issue on:
cat /proc/version
: Linux version 5.4.72-microsoft-standard-WSL2 (oe-user@oe-host) (gcc version 8.2.0 (GCC)) #1 SMP Wed Oct 28 23:40:43 UTC 2020
Can confirm the issue on:
Windows 11 Pro Version 21H1 (22000.527)
WSL Ubuntu release: 20.04 cat /proc/version: Linux version 5.10.16.3-microsoft-standard-WSL2 (oe-user@oe-host) (x86_64-msft-linux-gcc (GCC) 9.3.0, GNU ld (GNU Binutils) 2.34.0.20200220) #1 SMP Fri Apr 2 22:23:49 UTC 2021
Well, the same thing happened to me, saved in windows, cut and pasted in a linux folder, and out of curiosity I went to research what it was and ended up here, so.. it still happens
Windows 11 Home Single Language Version 21H2 Comp. 22000.556 Ubuntu 20.04
Present in Windows 10 21H1 with WSL2
Can confirm the issue on:
Linux version 5.10.60.1-microsoft-standard-WSL2 (oe-user@oe-host) (x86_64-msft-linux-gcc (GCC) 9.3.0, GNU ld (GNU Binutils) 2.34.0.20200220) #1 SMP Wed Aug 25 23:20:18 UTC 2021
@HakuOTR I would just give it some time. Hopefully they will fix it soon. We ended up going with the (M1 based, this year) Macbook Pro again. I could not even attempt to justify anything else, considering I have to support my developers. WSL is still proving to be far too immature. It is getting close, however. Maybe one day.
Please note that the majority of my folks would love to run Windows with a WSL2 dev environment, but it has to work, right now the list of bugs is long, and the patience is short. We still don't have systemd support, for example, and that isn't even remotely an issue that is a blocker for us. The blockers?
1) No ability to autostart background services unless Windows is involved in some oddball hack. 2) Unexpected filesystem changes that have to be filtered out 3) Enterprise support for WSL? Seems nonexistent? We spend well over 6 figures (like, exponentially, though I won't disclose figures thanks to NDA) with Microsoft, how is it that WSL/WSL2 has no support? Or did our team miss something?
I wish everyone the best of luck.
you can sudo find . -name "*:Zone.Identifier" -type f -delete worst workaround, but works.
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.
this issue causes files that if are uploaded by accident can cause builds to fail in CI/CD
Turning off "preserve zone information in file attachment" seems to have stopped the zone.Identifer files being created when I copy-paste into a WSL folder
Open gpedit.msc
Problem persists and seriously is disgusting this kind of bugs happening in WSL. Have to create an alias to delete fast those Zone.Identifier when I'm copying assents to my WSL, but its time workflow and most important is unnecesary work.
This needs to be fixed
Turning off "preserve zone information in file attachment" seems to have stopped the zone.Identifer files being created when I copy-paste into a WSL folder
Open gpedit.msc
- Open User Configuration>Administratives Templates>Windows Components>Attachment Manager.
- Double-click on "Do not preserve zone information in file attachment" and set it to enabled, then press ok
I've done this but WSL is still creating the Zone.Identifier
files.
Hello! I'd recommend that one of you who is subscribed to the Windows Insider Program to report the bug, either on Win10 or Win11. I'm enrolled to WIP but I don't use WSL.
I've done this but WSL is still creating the
Zone.Identifier
files.
In a work environment, managed pc don't always have access to these settings. So not really a workaround for me.
Same problem here 😢
Window 11 / WSL 2
Turning off "preserve zone information in file attachment" seems to have stopped the zone.Identifer files being created when I copy-paste into a WSL folder
Open gpedit.msc
- Open User Configuration>Administratives Templates>Windows Components>Attachment Manager.
- Double-click on "Do not preserve zone information in file attachment" and set it to enabled, then press ok
Original post from MS https://devblogs.microsoft.com/oldnewthing/20140311-00/?p=1543#:~:text=In%20the%20Group%20Policy%20editor,your%20computer%20even%20more%20dangerous.
I've done this but WSL is still creating the
Zone.Identifier
files.Turning off "preserve zone information in file attachment" seems to have stopped the zone.Identifer files being created when I copy-paste into a WSL folder Open gpedit.msc
- Open User Configuration>Administratives Templates>Windows Components>Attachment Manager.
- Double-click on "Do not preserve zone information in file attachment" and set it to enabled, then press ok
Original post from MS https://devblogs.microsoft.com/oldnewthing/20140311-00/?p=1543#:~:text=In%20the%20Group%20Policy%20editor,your%20computer%20even%20more%20dangerous.
That seems to work for me. Anyone know how to also prevent extended attribute (.attrs) files from also being created when copying to WSL2?
Exact same issue here still. Any updated workarounds/fixes?
+1
+1
It's still hapening on newest win11, when copying files from windows to wsl2 ubuntu, every file in ubuntu have .Identifier.
Turning off "preserve zone information in file attachment" seems to have stopped the zone.Identifer files being created when I copy-paste into a WSL folder Open gpedit.msc
- Open User Configuration>Administratives Templates>Windows Components>Attachment Manager.
- Double-click on "Do not preserve zone information in file attachment" and set it to enabled, then press ok
I've done this but WSL is still creating the
Zone.Identifier
files.
Hey, did you find a fix for this by chance? I've enabled it as well and my system still creates these Identifier files.
Found this thread after running into the same issue when using Windows 10's built-in NFS client support to access NFS shared from a separate Ubuntu box (no WSL involved at all). Interesting that it's been going on for a few years now.
What's needed is an optional Windows policy to prevent any attempt to create alternate data streams on filesystems that don't support them. I won't hold my breath that something like that actually gets added, though... :\
I am still experiencing this bug on Windows 10 Pro.
Turning off "preserve zone information in file attachment" seems to have stopped the zone.Identifer files being created when I copy-paste into a WSL folder
Open gpedit.msc
- Open User Configuration>Administratives Templates>Windows Components>Attachment Manager.
- Double-click on "Do not preserve zone information in file attachment" and set it to enabled, then press ok
I'm running windows 10 pro and this one worked for me.
Turning off "preserve zone information in file attachment" seems to have stopped the zone.Identifer files being created when I copy-paste into a WSL folder Open gpedit.msc
- Open User Configuration>Administratives Templates>Windows Components>Attachment Manager.
- Double-click on "Do not preserve zone information in file attachment" and set it to enabled, then press ok
I'm running windows 10 pro and this one worked for me.
Sadly, gpedit.msc
is not available on Windows Home (11 22H2 build 22621).
I still have no idea of why these Zone.Identifier files even exist in the first place but, I found two ways to stop them from get created every time you move something from windows explorer to wsl terminal. I hope this will help.
sudo apt-get install zip unzip
)Turning off "preserve zone information in file attachment" seems to have stopped the zone.Identifer files being created when I copy-paste into a WSL folder
Open gpedit.msc
* Open User Configuration>Administratives Templates>Windows Components>Attachment Manager. * Double-click on "Do not preserve zone information in file attachment" and set it to enabled, then press ok
This didn't prevent the Zone.Identifier files from being created in my case. Win 11 Pro 22621 and WSL 2 ("1.2.0").
Same issue here Windows 10 + Ubuntu 22.
wsl -v Versión de WSL: 1.2.0.0 Versión de kernel: 5.15.90.1 Versión de WSLg: 1.0.51 Versión de MSRDC: 1.2.3770 Versión de Direct3D: 1.608.2-61064218 Versión DXCore: 10.0.25131.1002-220531-1700.rs-onecore-base2-hyp Versión de Windows: 10.0.19044.2846
.rw-r--r-- 1.5k alvardav alvardav 28 Apr 10:24 check-downscaller.sh .rw-r--r-- 1.6k alvardav alvardav 28 Apr 10:24 check-downscaller.sh:Zone.Identifier
I saw a closed issue which was 3 years old the same as this one, I am curious, is Microsoft a government entity? It surely act like one. The efficiency for a bug fixing is textbook bureaucracy. To actually fix this issue, I'm guessing, will only take one engineer one day of labor and yet they continue to ignore their users. why? because they don't care.
copy a file to wsl file system using windows file explorer will generate a zone identifier file. is this a feature? or a bug? let's be clear about it first. what is the official explanation? I can't find it.
if it is a feature, why? and how to disable it? if it is a bug, why does it still exist? it's not a blocking issue granted, so it's not priority I understand that, but still, 3+ years?
I also have the same problem and when trying to delete with the command find . -name "*:Zone.Identifier" -type f -delete it gives me the error find: cannot delete ‘./file:Zone.Identifier’: Read-only file system Does anyone know of another way to delete the file?
It just happened to me after I dragged a few files using the Explorer pane:
When downloading a file from an online source lets say this image or a zip folder and directly saving it to the WSL file structure using the Microsoft Edge 'save as' option ( I have turned off the default download location so edge asks me every time where I should save something downloaded), when the download is complete I see these Zone Identifier files.
I read about a similar #4609 issue and from what I understand is that these files shouldn't be downloaded or should be removed after download.
My Ubuntu specifications :
My windows :