Folder copy silently fails to copy children when folder name begins with a dot (“.”) and the destination resides in a shared folder

[pupSci]

Setup:
VB version 5.1.22 or 5.1.23 r115382
Host: macOS Sierra 10.12.5 or 10.12.4
Guest: Windows 10

Issue:
On Windows 10 guest copying a folder with a name beginning with a dot (“.”) to a shared folder results in an incomplete copy. For example a Visual Studio project folder with a “.vs” child folder. VBox seems to stop copying once it hits the .vs folder children. No error is displayed in File Explorer. Win 7 guest does not have this issue.

Steps to reproduce:

• Setup Win 10 guest.
• Install Guest additions.
• Create a shared folder on host and mount it in guest.
• Using a command prompt to create a folder with a name beginning with a dot (e.g. md “.test”).
• Create a file under .test such as “New Test Document.txt”.
• In File Explorer right-click .test and select copy.
• Right-click a destination folder on a shared folder, right-click and and paste.

Notice .test is created but “New Test Document.txt” is not present under it.
Also, using the command prompt to rename .test results in “The system cannot find the file specified”.

[Socratis]

Could not verify the issue. Folder ".hidden" containing empty file "New Text Document.txt" copied successfully in the read-write, temporary share "\\VBoxSvr\Misc". Both folder and file.

• Host: OSX 10.9.5
• Guest: Win10-32, 1511, b10586.753
• VirtualBox: 5.1.23 r115370 (Qt5.6.2)

[pupSci]

I should have been clearer on one additional point. The issue shows up when copying from and to an HFS+ share. So make the source folder ".hidden" containing the empty file "New Text Document.txt" on the shared folder drive and copy to another folder on the shared folder drive. If copying from an NTFS (or presumably any format with native hidden attribute) the copy will succeed.

[Socratis]

I'm afraid that even this is not clear enough. What do you mean "an HFS+ share"? Could you give a step-by-step example (you did), but include the complete paths and other characteristics of the source and the destination?

Also, I'd like to know why do you think that this is working in Win7 and not in Win10. What's different? Finally, instead of simply "Windows 10", could you specify the bits (32- vs. 64-bits) and the complete version?

[pupSci]

HFS+ is the primary file system of macOS so I was just trying to be specific that the shared folder can't be from a non-Mac formatted drive.

• Guest: Win10-64 bit, 10.0.15063

Steps to reproduce: 

• In Mac Finder create a folder named "Temp" under your user folder, e.g. "/Users/pupSci/Temp".
• In Win 10 guest with guest additions installed open the shared folder menu: Devices/Shared Folders/Shared Folder Settings.
• Click the "add new shared folder" button.
• From the drop down select "Other" navigate to the Temp folder "/Users/pupSci/Temp".
• Leave all the rest of the check-boxes unchecked, i.e. temp share and click OK, then Ok again to leave the shared folder settings window.
• Open File Explorer, navigate to "Network\VBOXSVR" "
  Vboxsvr\Temp", right click on the network address and map it as Z.
• Open a command prompt and change to the Z drive ("Z:").
• Create a folder with a name beginning with a dot (md “.hidden”).
• Create a file under .hidden (echo hello > ".hidden\new text document.txt").
• Create another folder called "Copy" (md "Copy").
• Back to File Explorer set the view options to see hidden files.
• In File Explorer click the Z: drive. You should see .hidden and Copy with .hidden dimmed.
• In File Explorer right-click .hidden and select copy.
• Double-click "Copy".
• Right-click on the blank background and select Paste.
• .hidden will be created but will be empty.

• Guest: Win 7-64 bit running on the same Macbook Pro and at the same time as the above Win 10 VM correctly copies the files following the same procedure as above.

• Guest: Win10-64 bit, 10.0.15063 running under vmware on the same Macbook Pro correctly copies the files following the same procedure as above. I know it's not an issue with having vmware installed as the VBox VM was it was dropping files before installing vmware. The vmware VM is actually a copy of the VBox VM.

Let me know if you need anything else.

[Socratis]

Nope. Followed the detailed steps (thank you) exactly to the "t". Still I'm getting a "Z:\Copy\.hidden\new text document.txt" with "hello" in it.

• I thought that the mapping to Z:\ may have something to do with it. No.
• I thought that the right-click copy/paste, vs. Drag'n'Drop may have something to do with it. No.
• I thought that the transient share may have something to do with it. No.

I strongly believe that there is something different in your guest's setup. Don't know exactly what, but it's the only logical conclusion. Since shared folders are based on the guest additions, and they're no different between Win7 and Win10 (AFAIK), I can't see the reason why it would work on one of your guests and not on the other, unless there was something improperly setup in the 'other'.

Detailed setup

• Host: OSX 10.9.5 (13f1911).
• Guest: Win10-64, 1607, 14393.0 (yes, I have both a 32- and a 64-bit installation. I will update it to the latest and greatest, to see if it makes a difference).
• !VirtualBox: 5.1.23 r115417 (Qt5.6.2) (yes, I updated it since my last trial).

[pupSci]

I finally got a chance to rebuild my Win 10 VM. I started with version 10240 and there wasn't any problems with copying. Applied updates and again copying was fine. Applied the "Creators Update" and the problem described in this ticked showed up. The "Creators Update" is Windows 10 Version: 1703 Build: 15063.296.

As far as I can tell the issue arises with VB and the Windows 10 Creator's Update. I also have VMware and using the same VM under VMware does not exhibit this issue.

[Socratis]

Did you update the GAs after you updated Win10?

[pupSci]

Yes, GA were updated and I even tried the latest VB build 115966 with GA 115966.

[Socratis]

I have to update my Win10 guest (tomorrow) to the CU version (yes, I keep it on purpose un-updated). I'll report back...

[Socratis]

<OffTopic>
From all the ways I've seen over the years to update an OS, Win10 has got to be the worst of them all, I swear it by the old gods and the new! This is not an update, it's a freaking re-installation of the OS, including a "Windows.old" dir, clocking at 13+ GB!!! Aaaaargh!!!!
</OffTopic>

Anyway, after it was done (hey, it only took what, 13? 16 hours?) I can reproduce the problem. I'm at Win10x64, version 1703, build 15063.332 (you can't always get what you want).

The problem seems to be limited (so far) to shared folders in OSX hosts, as I tried the same with a WinXP host and no problem. That's all the guests I tried BTW.

Now, here's another thing that I tried. I launched an OSX 10.9.5 VM. I connected to it from the Win10 VM via normal, networking shares. I followed the same recipe. The copy succeeded. There was a "Y:\Copy\.hidden\new text document.txt" with the content "hello". But, trying to open that file from the Win10 VM, gave me the error "The system cannot find the file specified". Copying it to the Win10 Desktop worked and opening the copied file from the Desktop worked.

I'll revert to the earlier Win10 (1607, 14393.0) and see if the same thing happens.

[Socratis]

So, I did revert to Win10, version 1607, build 14393.0 and repeated the experiment without the shared folders. In fact that basic snapshot that I have, doesn't even have the GAs installed at all. So some weird behavior was again noticed: I couldn't open the "Z:\Copy\.hidden\new text document.txt" (content "hello") with Notepad. Error message:

The system cannot find the file specified

But then I realized that it's Notepad's shortcoming, because I could open it just fine with WordPad. So it might have worked in the previous case, I simply didn't try WordPad.

In summary:

• Host: OSX. 10.9.5 (socratis), 10.12.4 and 10.12.5 (pupSci).
• Guest: Win10x64 build > 14393.x (at least), most probably Creators Update build 15063.x.
• VirtualBox: 5.1.22, 5.1.23 r115382, r115966.

• Issue: If the the OSX shared folder contains a hidden folder (folder starting with a dot), copying that folder to another location, skips all the folder's contents. This does not happen with "normal" named folders. This does not happen with SMB shares. This only happens after the guest's Win10 Creators Update.

Which is pretty much what "pupSci" described very accurately!

[pupSci]

No activity on this data loss ticket for 8 months. Issue still exists with latest V Box version 5.2.7 r120349 (Qt5.6.3) and latest Win 10 updates. Been burnt by this a number of times now and I even know about it. Can't move or copy folder structure with any folder having a name starting with a dot without data loss.

[Socratis]

Then I would suggest until it's fixed, use traditional networking SMB shares.

[bird]

Gut feeling here is that the windows guest gets confused when a directory it just created without the hidden attribute appears to have gotten it. On unixy host systems (linux, os x, solaris, ++) files and directories starting with '.' get the DOS file attribute hidden set when we emulate the DOS/Windows attributes. Given that the problem does not appear to surface with windows hosts, I assume it's is an artifact of this behavior.

This is great when you share your home directory with a VM and bring it up in explorer inside the VM, it will look like 'ls -l' displays it on the host. Need to reproduce and ponder if we can do something about this eventually...

[boxer01]

Replying to bird:

Sorry to inform you, but my ticket #17626 with probably same issue is based on the windows host and guest combination. I think that the problem is maybe some path encoding function which has some issues with the period as a part of some regular expression or something like this.

[boxer01]

Could somebody check this issue on the some current version, at least 6.0.8 / 6.0.9 or 5.2.30 / 5.2.31? It looks like it’s solved in my other ticket #17626.