Mac OS Host, Windows guest, sees all files on host with spaces replaced by _

[tsp1965]

Hi all

I have Virtualbox 6 installed on several mac hosts with W10 guests. In all cases I use it to open, edit and re-save files held on the Mac OS host using a Windows app. On most installations, all the file names read fine, but on a couple the spaces in each file on the mac os host have been replaced with underscores _. So My File.docx would be My_File.docx when seen from the guest os. I don't understand why some installations do this and some don't.

Is there any way I can persuade my rogue guest OS' to play nicely and display spaces like they should, please?

It must just be a setting somewhere, but I can't find it!

Thanks in advance for any ideas.

Tim

[socratis]

It must just be a setting somewhere, but I can't find it!

No, there's no such setting, because it would affect everything. Since you can't even figure out the pattern reproducibly, how can we even begin to troubleshoot it? Maybe it's the application that's doing the file writing, like MSOffice?

I can tell you that it works fine here, plus I haven't heard of anything like that in the past...

[tsp1965]

Hi, thanks for the reply.

I don't think I have explained the problem very clearly. I see the issue in Windows explorer when reviewing certain types of file on Mac OS. To explain the context, I am normally a Mac user and my macs record broadcast TV using EyeTV software. This writes a file which MacOS treats as a single file but is actually a package. Opening the package in MacOS reveals an elementary stream mpeg, plus a tiff thumbnail and a couple of other files, all with random number file names. EyeTV does a great job of recording but a rubbish job of trimming out commercials, as its editor is not frame accurate. I can't find a decent MacOS frame-accurate mpeg editor which doesn't recode the whole file every time you edit, so I instead use VideoRedo in a Windows VM. This recodes only the join, which is quicker and doesn't reduce the quality of the unchanged stream.

So to open the correct file in Windows, you have to browse to the EyeTV recordings folder, which contains the packages. Each of them should have a name like My TV Programme E01.eyetv - Windows treats the EyeTV package as a folder with a . in the folder name. Open that folder up in Windows and you see the package contents. That's how many Macs see it, including my main mac Pro. Unfortunately when I'm recording several things at once I use my MacBook Pro, and this is the one which doesn't read the folder name right. Instead of My TV Programme E01.eyetv it sees My_TV_Programme_E01.eyetv. If I browse from within Windows on the laptop to the EyeTV folder on the Mac Pro, it reads everything correctly. But if I try to read the laptop's own EyeTV folder, it is wrong. The view settings within Windows for the EyeTV folders are identical, so the problem seems to be with what MacOS gives to Windows. The only difference I can see between the bad machine and the good is that the bad stores the recorded files on its internal SSD. The Mac Pro and its predecessors recorded onto an external Thunderbolt drive which is not an SSD. Perhaps the Windows/Mac interface handles SSD folders differently.

As a problem, I accept it's not the end of the world. It slows down the process of saving, and I'd prefer to fix it, but if I can't, I can't.

The frustrating thing is that I know it is fixable, because several other Macs work fine.

[granada29]

I'm just wondering if the Mac volume that is giving you trouble is APFS formatted. If it is, then that might explain the difference between the Macs.

I've nver tried sharing an APFS drive with Windows so don't know if that even works at all.

[mpack]

I've nver tried sharing an APFS drive with Windows so don't know if that even works at all.

I don't see why it wouldn't work. For one thing it's impossible to "share a drive". A "shared folder" is just a file transfer protocol, like FTP. It isn't shared access to the underlying hardware, and the underlying filesystem should be irrelevant.

What may be relevant is if the underlying filesystem character set supports characters which a shared folder protocol does not (bear in mind the character set has to be compatable with other PCs on a network), in which case the file would be hidden or some kind of character replacement would occur. I assume that's what happens here. I'm guessing that the filename character that OS X renders as a space, is not really a space. I'd guess this has something to do with being command line friendly.

[tsp1965]

That's a good point - the SSD is indeed APFS and the external drive is Mac OS Extended. So it may well be that Windows can't cope with spaces in APFS in package files, although it does with other files and folders.

[socratis]

So it may well be that Windows can't cope with spaces in APFS in package files

Windows doesn't have a clue whether it's APFS, HFS+, exFAT or NTFS. They all look like shared folders, they all go through the same API.

Can you describe a little bit more the differences with the "good" and the "bad".

• We're talking two OSX hosts, hosting the same/similar VMs?
• With the same EyeTV program that records things into a shared folder?
• What's different between them is where the shared folder resides?