Closed Kai-Richardson closed 3 years ago
Can't repro here.
This is on 19002; whether the small version bump makes a difference I doubt. Zone.Identifier does get a quick search hit. Said functionality is news to me.
On a lark, from your WSL2 bash prompt, what is the output of:
$ powershell.exe "Get-CimInstance -Namespace root/SecurityCenter2 -ClassName AntivirusProduct" | grep displayName
I can reproduce with both WSL1 and WSL2 at 19002. Zone.Identifier may not exist for various reasons, such as the "Do not save zone information in attachments" policy or deleted by Windows Smart Screen when opening a file.
@therealkenc For the output of your powershell grep: displayName : Windows Defender
Also, I've been experiencing this for many versions/months, so it's not something that was introduced as of recent.
@0xbadfca11 Regarding your link to the azure windows documentation, I have no Attachments key in HKCU\Software\Microsoft\Windows\CurrentVersion\Policies\Attachments
. Therefore, if the documentation is correct, If you do not configure this policy setting, Windows marks file attachments with their zone information.
If you do not configure this policy setting, Windows marks file attachments with their zone information.
I didn't configure anything "special" in my policy (almost never do as a rule) but copying the file didn't produce the artifact. It does for you and 0xbadfca11.
I suppose the experiment to try is drag a file out of Downloads and onto some Windows share on some other computer on your local network (or a VM). If that Zone.Identifier file also appears in a "normal" network share scenario then this smells by-design-Windows.
I think (?) the variable here might be in your step (1) "Download a file from an online resource into a windows folder". You didn't say how. I used Chrome, but it could have been curl
. The fact that file came from https://i.imgur.com/
was long lost to the wind by the time my drag-and-drop happened.
@therealkenc Here's the steps I take exactly, using Firefox (reproduced on Chrome):
C:\Users\zekai\Desktop
\\wsl$\Ubuntu\home\cassini\github
Here's my output from df -Th
, to list filesystem/partition information.
df -Th
Filesystem Type Size Used Avail Use% Mounted on
/dev/sdb ext4 251G 9.0G 230G 4% /
tools 9p 477G 303G 174G 64% /init
none devtmpfs 7.3G 0 7.3G 0% /dev
none tmpfs 7.3G 8.0K 7.3G 1% /run
none tmpfs 7.3G 0 7.3G 0% /run/lock
none tmpfs 7.3G 0 7.3G 0% /run/shm
none tmpfs 7.3G 0 7.3G 0% /run/user
tmpfs tmpfs 7.3G 0 7.3G 0% /sys/fs/cgroup
C:\ 9p 477G 303G 174G 64% /mnt/c
D:\ 9p 932G 531G 402G 57% /mnt/d
Notice new Zone.Identifier file.
Thanks for the detailed steps. Caught it; same repro,
Below seems to be a hint. "This file came from another computer and might be blocked to help protect this computer."
Clicking that "unblock" button cures. Which puts this (rather unfortunately) in by-design territory, and worse, out-of-scope WSL territory.
@therealkenc
Clicking that "unblock" button cures. Which puts this (rather unfortunately) in by-design territory, and worse, out-of-scope WSL territory.
I would argue that having extraneous files pop into existence every time something downloaded is copied over to the WSL filesystem should be classified as a bug and not by-design.
Since these .Identifiers are quite useless once they get moved WSL, why not simply ignore the NTFS alternate file stream data during the copy process between file systems. This issue definitely has caused me a bit of pain when I download zipped directories and bring them over to WSL, leading to a proliferation of dozens of .Identifier files.
This command (PowerShell) lists all files with an associated Identifier stream in a directory:
Get-ChildItem -Recurse | Get-Item -Stream Zone.Identifier -ErrorAction SilentlyContinue | Select-Object FileName
This is how you remove them with PowerShell:
Remove-Item .\example.exe -Stream Zone.Identifier
If PowerShell has the tools to remove these stream identifiers, why can't WSL remove them upon file copy over?
why not simply ignore the NTFS alternate file stream data during the copy process between file systems
Likely because WSL doesn't have the faintest idea whether (scare quote) "those files" should be copied or not. Also because axiom that if the word "simply" is evoked, the premise is near always incorrect.
I would argue that having extraneous files pop into existence every time something downloaded is copied over to the WSL filesystem should be classified as a bug and not by-design.
Me too; although someone on the some team somewhere at MSFT thought "This file came from another computer and might be blocked" was a good idea.
This all said, I did the experiment of copying the untrused (?) file onto a local share, and there isn't any "•Zone.Identifier" shenanigans.
This issues hasn't been closed by-design. Someone over my pay grade would need to do that. If it were, you'd already know.
Explorer is attempting to set the NTFS ADS and WSL is not handling this correctly. The 0x003A (colon) getting altered to 0xF03A (dot) sounds like text encoding or path sanitation gone awry.
If this magic WSL$ share isn't going to support storing ADS, then it needs to drop the ADS requests altogether. Dumping files in the share is terrible UX, could affect disk space (Zone Identifiers are not the only items stored in ADS), and is useless busywork as neither Windows or Linux support this ·Zone.Identifier
loose file.
Stack from a CreateFile
on \\wsl$\Ubuntu\tmp\my.png:Zone.Identifier
, Windows 10 18363.418
:
1 FLTMGR.SYS FltpPassThroughInternal + 0x90 0xfffff802213e35a0 C:\WINDOWS\System32\drivers\FLTMGR.SYS
2 FLTMGR.SYS FltpCreate + 0x2f3 0xfffff8022141bd13 C:\WINDOWS\System32\drivers\FLTMGR.SYS
3 ntoskrnl.exe IofCallDriver + 0x59 0xfffff80223831f39 C:\WINDOWS\system32\ntoskrnl.exe
4 ntoskrnl.exe IoCallDriverWithTracing + 0x34 0xfffff80223830fe4 C:\WINDOWS\system32\ntoskrnl.exe
5 ntoskrnl.exe IopParseDevice + 0x62b 0xfffff80223de5ffb C:\WINDOWS\system32\ntoskrnl.exe
6 ntoskrnl.exe IopParseFile + 0xc7 0xfffff80223ebccc7 C:\WINDOWS\system32\ntoskrnl.exe
7 ntoskrnl.exe ObpLookupObjectName + 0x78f 0xfffff80223decfcf C:\WINDOWS\system32\ntoskrnl.exe
8 ntoskrnl.exe ObOpenObjectByNameEx + 0x201 0xfffff80223deb431 C:\WINDOWS\system32\ntoskrnl.exe
9 ntoskrnl.exe IopCreateFile + 0x820 0xfffff80223e30300 C:\WINDOWS\system32\ntoskrnl.exe
10 ntoskrnl.exe IoCreateFileEx + 0x11d 0xfffff80223e2f9ad C:\WINDOWS\system32\ntoskrnl.exe
11 LXCORE.SYS LxpUtilOpenFileEx + 0x356 0xfffff80226752d6a C:\WINDOWS\system32\drivers\LXCORE.SYS
12 LXCORE.SYS LxpUtilOpenFile + 0x45 0xfffff80226752a09 C:\WINDOWS\system32\drivers\LXCORE.SYS
13 LXCORE.SYS LxVolFsInodeOpen + 0xa0 0xfffff802267739e0 C:\WINDOWS\system32\drivers\LXCORE.SYS
14 LXCORE.SYS VfsInodeOpen + 0x176 0xfffff8022675f9ae C:\WINDOWS\system32\drivers\LXCORE.SYS
15 LXCORE.SYS VfsOpenInodeEx + 0x1bc 0xfffff8022676493c C:\WINDOWS\system32\drivers\LXCORE.SYS
16 LXCORE.SYS VfsOpenFile + 0xa3 0xfffff80226764723 C:\WINDOWS\system32\drivers\LXCORE.SYS
17 LXCORE.SYS LxpUtilOpenUserPathAt + 0xab 0xfffff80226752ec3 C:\WINDOWS\system32\drivers\LXCORE.SYS
18 LXCORE.SYS LxpOpenHelper + 0x90 0xfffff80226738528 C:\WINDOWS\system32\drivers\LXCORE.SYS
19 LXCORE.SYS LxpSyscall_OPENAT + 0x9 0xfffff8022673faa9 C:\WINDOWS\system32\drivers\LXCORE.SYS
20 LXCORE.SYS LxpSysDispatch + 0x114 0xfffff80226739944 C:\WINDOWS\system32\drivers\LXCORE.SYS
21 LXCORE.SYS PicoSystemCallDispatch + 0x11 0xfffff80226756df1 C:\WINDOWS\system32\drivers\LXCORE.SYS
22 ntoskrnl.exe PsPicoSystemCallDispatch + 0x1f 0xfffff802240cbb5f C:\WINDOWS\system32\ntoskrnl.exe
23 ntoskrnl.exe KiSystemServiceUser + 0x76 0xfffff802239d28f8 C:\WINDOWS\system32\ntoskrnl.exe
@therealkenc I've been getting this for months too, and I think I know why you are not getting any Zone Identifier file. If I copy and paste to a WSL2 folder, I won't see the identifier file yet. But if I go a folder up, then go back again to the original folder, I now see the identifier file.
here's the video of what I'm seeing.
I also want to add that I copied from a Downloads
folder of Windows to a folder of my \\wsl$\ubuntu...\home\username\.local\_temp
I'm using WSL2, and here's my build number. Microsoft Windows [Version 10.0.19037.1]
Yeah this is happening here as well, pretty annoying.
I hope this gets fixed soon as it's really annoying when, like mentioned already, you copy a extracted zip file to the WSL directory
@therealkenc hey there, 👋🏻. I was wondering if you are now seeing this a bug after I posted details on how to reproduce it to give you more context?
If you can reproduce it, any chance we can label this as a bug?
@therealkenc Please label as bug.
I was wondering if you are now seeing this a bug after I posted
I reproduced it in October, quoth "Thanks for the detailed steps. Caught it; same repro",
Please label as bug.
Precedent (for better or worse) is the dev responsible makes that call. My # 1529 was opened Dec 2016 and I only took the rare liberty of marking it as a bug in May 2018 (a regretful precedent). A personal favorite # 2779 managed to make it from Dec 2017 to fixedinisiders Sept 2019 with no bug tag at all (noting # 2779 was also a terrible UX).
But in the interest of popular demand, sure. Noting the significance of the already-existing open status (and lack of by-design tag) on this issue is probably being underestimated, and the significance of the newly minted bug tag is probably being overestimated.
@therealkenc Thanks! It helps externals a lot when it comes to badgering the folks responsible and shows up in quantitative reporting.
Hey, @therealkenc thanks for adding the label. 👋🏻 I'm actually more interested if it's reproducible in your end, that way, everyone in this thread would be in agreement it is happening. It somehow giving a mixed signal that the bug is inconsistent. If it's consistent then it is going to be easier to debug. However, I would like to add by simply searching the label:bug
, it seems it was mostly fixed or someone from MS does jump in the thread,
Judging from the screenshot it seems tagging it as a bug, seems to work 😉
@thisguychris they reproduced it in this reply: https://github.com/microsoft/WSL/issues/4609#issuecomment-546577426. Also said in their last reply.
@Kai-Richardson my bad, I totally missed that, 🙏🏻 sorry about that @therealkenc
A Workaround is to run cd ~ && find . -name "*:Zone.Identifier" -type f -delete
I will not say this is a simple solution. It is a workaround for somthing we should not have in our linux files.
An XML file got this identifier file:
[ZoneTransfer]
ZoneId=3
niklas@Fractal:~$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 18.04.4 LTS
Release: 18.04
Codename: bionic
niklas@Fractal:~$ uname -a
Linux Fractal 4.19.104-microsoft-standard #1 SMP Wed Feb 19 06:37:35 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
Still a bug in Version 2004 GA, 19041.264.
Having the same issue here. Help is welcome
Can't repro here.
This is on 19002; whether the small version bump makes a difference I doubt. Zone.Identifier does get a quick search hit. Said functionality is news to me.
On a lark, from your WSL2 bash prompt, what is the output of:
$ powershell.exe "Get-CimInstance -Namespace root/SecurityCenter2 -ClassName AntivirusProduct" | grep displayName
It's likely you just don't see them in file explorer, because they will only display when you have file explorer set to show hidden files.
@drewstaylor It's already been confirmed as reproducible, you're responding to an old post.
@SvenGroot - Can you please take a look? Looks like we should be handling these alternate data streams differently.
Any update on this? This is very annoying.
Seeing this on 19041.508 GA, WSL2, Ubuntu. VScode running from WSL shows the files as they turn up and I can remove them from there but it's still irritating. Repro steps:
Same "bug" on my two computers with WSL2 and the last Ubuntu version. Exactly the same steps (follow the tutorial on the website, and copy a file from Windows to \wsl$\Ubuntu\home...
Same bug here, it's really annoying and wrong.
I also get :com.dropbox.attrs
as well as :Zone.Identifer
files everwhere. Plays havoc with git repos when I copy those into Ubuntu!!
Extended attrbiutes / alternate ntfs file streams or whatever they are should NOT get copied.
the cause of Zone.Identifier
is Windows marks file attachments with information about their zone of origin
get-item .\smile.png -stream *
PSChildName : smile.png:Zone.Identifier
FileName : C:\workspace\programming--windows\smile.png
Stream : Zone.Identifier
Length : 153
disable Zone.Identifier
the cause of
Zone.Identifier
isWindows marks file attachments with information about their zone of origin
We've known the actual cause for almost a year now. See riverar's comment.
Explorer is attempting to set the NTFS ADS and WSL is not handling this correctly. The 0x003A (colon) getting altered to 0xF03A (dot) sounds like text encoding or path sanitation gone awry. https://github.com/microsoft/WSL/issues/4609#issuecomment-549271706
@therealkenc Hey Ken, can you help drum up internal noise about this year long issue now?
cc: @SvenGroot @crutkas @bitcrazed
I just got this bug.
I saved an email attachment from Outlook directly to WSL via \wsl on explorer and got the Zone.Identifier file.
Windows version 2004 and WSL2
Got this bug too.
All these little strange behaviours from Microsoft in WSL make it really hard to fully embrace it! As mentioned - this issue is continuously playing havoc with git repos and general file management.
Hey @MattGarnettWelsh - appreciate the feedback.
Alas, our team is currently swamped with high-pri work, but are aware of the issue and will respond as soon as they come up for air.
To make sure we're not missing anything unexpected, are there other issues you're seeing? If so, please be sure to find/file issues accordingly.
Thanks for your patience.
I get this issue with js files created locally, nothing to do with downloading anything.
Hey @Neutrino-Sunset - could you share a repro?
@bitcrazed There's quite a few repros in this thread, come on.
It happens every time I copy a file in, it shouldn't be too hard.
Get Outlook for Androidhttps://aka.ms/ghei36
How can I provide a repo? I installed the Ubuntu distro, set it to WSL 2, whenever I copy a file into Ubuntu/home in the WSL filesystem using Windows Explorer it creates Zone.Identifier files. Not sure how I can create a repo of my file system.
@riverar - So you can create a JavaScript file locally in Windows, and copy it to a WSL folder via \wsl$... and you see ghost files?
@bitcrazed The file needs an NTFS alternate data stream. The user is probably unaware their file contains NTFS ADS of some sort.
Example 1:
"[ZoneTransfer]`nZoneId=3" | Set-Content -Path test.js -Stream Zone.Identifier
Example 2:
"hello world" | Set-Content -Path test2.js -Stream BleepBloop
This is effectively equivalent to the repro steps provided over a year ago.
Here's my repo that I shared at the top of this thread, over a year ago: https://github.com/microsoft/WSL/issues/4609#issuecomment-546574922 Here's it being successfully replicated: https://github.com/microsoft/WSL/issues/4609#issuecomment-546577426 Those were due to NTFS ADS.
According to this comment, this bug can also possibly be replicated with NTFS extended attributes.
This happens when you copy it using Windows explorer
Get Outlook for Androidhttps://aka.ms/ghei36
@riverar I am very well aware that the issue as described requires an ADS, which is why I was surprised when @Neutrino-Sunset stated that they "get this issue with js files created locally, nothing to do with downloading anything".
Such files should not contain any ADS' and thus should not exhibit the behavior being described elsewhere in this thread. Hence my request to them, for a repro/example of their issue.
As per my screenshot above, I have tried to repro the case of a locally created .js file which I copied into my Ubuntu distro's filesystem from Windows (I also tried doing so via File Explorer) ... but was unable to repro their case as described.
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/LinuxWhat you're doing and what's happening: This occurs when using Windows Explorer.
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:
Image: