Automatic delete metadata

[korda]

Host: Kubuntu 22.04.2 LTS
Guest: Windows 10 pro 22H2

Every time I move/copy a PDF file from the guest storage to the host shared folder, and additional plain-text metadata file will be created onto the destination. E.g.: if I copy afile.pdf an additional afile.pdf:Zone.Identifier:$DATA will be created.

How can I automatically delete it after the file has been transferred?

[scottgus1]

I have never heard of this, had to web-search it to know what it was, and still don't understand it.

But can you please confirm that the "shared folder" you're using is a Virtualbox Shared Folder, set up in the VM's settings, and not a real shared folder made by the host or VM OS?

FWIW in my brief and meager web-searching, I found that this ":Zone.Identifier:$DATA" thingy is made by Windows apps, at least. Could be something the Windows OS or app is doing, and you may have to get the Windows OS/app to stop doing it.

[korda]

But can you please confirm that the "shared folder" you're using is a Virtualbox Shared Folder, set up in the VM's settings, and not a real shared folder made by the host or VM OS?

I confirm that the shared folder maps to a real specific path of the host SSD storage (aka /home/korda/vbox/shared/)

FWIW in my brief and meager web-searching, I found that this ":Zone.Identifier:$DATA" thingy is made by Windows apps, at least. Could be something the Windows OS or app is doing, and you may have to get the Windows OS/app to stop doing it.

No used any "Windows app" (if you mean app installed from MS store and/or trough winget): moreover such file doesn't exist in the source, neither as hidden file.

Last time that has been occurred I have downloaded a pdf attachment from Gmail (loaded onto Chrome Browser of the guest machine). Metadata stored in such file, indeed, show that the pdf file was available as attachment of Gmail at a specific url.

Nevertheless such behaviour appeared also with resident file (on guest machine) that haven't been downloade before (ie a pdf generated from a virtual printer)

[mpack]

I have never heard of this, had to web-search it to know what it was, and still don't understand it.

It's pretty straightforward. NTFS and certain other filesystems support the concept of forked files, i.e. filenames with more than one data stream attached.

If you copy a forked file onto a filesystem that doesn't support forks, e.g. FAT, or a shared folder, then you either only get the first stream, or you get multiple files. The choice would be up to whatever code did the copying, presumably it was code inside the guest OS.

And no, VirtualBox has no control over this.

[korda]

I have never heard of this, had to web-search it to know what it was, and still don't understand it.

It's pretty straightforward. NTFS and certain other filesystems support the concept of forked files, i.e. filenames with more than one data stream attached.

If you copy a forked file onto a filesystem that doesn't support forks, e.g. FAT, or a shared folder, then you either only get the first stream, or you get multiple files. The choice would be up to whatever code did the copying, presumably it was code inside the guest OS.

And no, VirtualBox has no control over this.

Ok, understood: I will look for a workaround. Thx for your patience.

FYI, the destination filesystem (the host shared folder) is Btrfs.

[mpack]

FYI, the destination filesystem (the host shared folder) is Btrfs.

I don't believe that matters - shared folders are covered by their own standards. Remember that a shared folder is a software API, not a veneer on top of any filesystem, regardless of how it may appear to a layman.

[fth0]

FWIW, on NTFS file systems those forks are also known under the term ADS (Alternate Data Streams). The concept exists at least since the early Apple Macintosh computers, where files had a data fork and a resource fork.