Windows Vista inaccurately reports insufficient space for large files

I’m still trying to move everything over from my old 1 TB Buffalo Linkstation to a new 3TB My Book Live that I purchased last week.

I started encountering problems copying two large files to a private share, one ~4GB and the other ~7GB. At first they’d copy just fine until the final several MB, then it would stall for a while and even though it would ultimately “complete” the transfer – but the new file wouldn’t be there. I then found this thread:

http://community.wdc.com/t5/My-Book-Live/MBL-2TB-can-t-copy-move-large-size-files-from-share-folder-to/m-p/342889/highlight/true#M8576

Sure enough, the private share that I was trying to copy to was connected via WEBDAV, not Windows Network. So I deleted the connection and reconnected to the private share as described in that thread.

Now, however, when I try to copy the files Windows Vista advises:

"There is not enough space on sharename (\mybooklive). You need an additional 201 MB to copy these files.

Space free: 4.10 GB

Total size: 453 GB"

That, however, is completely untrue. According to the MBL UI I’ve only used 787 GB of 3 TB. The old Linkstation is only a 1 TB drive anyway!

Advice? Assistance? Thanks in advance!

It sounds like your system is still connected via WebDAV instead of CIFS…

Are you sure that’s NOT the case?

Shoot, you’re right, Tony…I hadn’t noticed that. Every time I try to reconnect via the net use command, however, it prompts me for the username and password and then reconnects via Web Client Network. Is there a way to force the share to connect via the Windows Network?

FirstTracks wrote:

 Is there a way to force the share to connect via the Windows Network?

I wish I knew!   It’d fix a lot of folks’ problems…

Exactly what syntax are you using for the NET USE command?

TonyPh12345 wrote:

Exactly what syntax are you using for the NET USE command?

 

To disconnect:

net use x: /delete

To connect:

net use x: \mybooklive\sharename

Of interest, I find that it connects to Microsoft Windows Network if I make the share public and reboot the MBL. That of course will work as a temporary workaround in order to transfer the two problem files, as I can then subsequently turn the share back to private, but that leaves sensitive stuff exposed for a period of time and that leaves me uncomfortable. Clearly that’s not an optimal solution.

Try this.  Find a service in Vista named “WebClient”, stop it, and try reconnect.  Should now connect correctly.  Only thing is with what service turned of I think WD2Go is also affected.

I know where it is in Windows XP, not in Vista.  Try set the provider order so they are shown in this order . . .

Microsoft Windows Network

Microsoft Terminal Services

Web Client Network

Myron wrote:

Try this.  Find a service in Vista named “WebClient” and try reconnect. 

 

Myron, let’s make sure that I’m understanding you correctly. Yes, I go into Services and I see “WebClient” – it’s showing as Started, with Startup Type Automatic. Are you recommending that I disconnect that service, then try to reconnect to the share via Net Use?

 

Myron wrote:

Should not connect correctly. 

 

Are you saying that I should set it to not start up automatically?

 

 

Myron wrote:

I know where it is in Windows XP, not in Vista.  Try set the provider order so they are shown in this order . . .

 

Microsoft Windows Network

Microsoft Terminal Services

Web Client Network

I’m not readily seeing where to set the preference order.

I made a typo in my reply which I corrected.

Set the “WebClient”’ service startup to Manual as stop the service.

Disconnect any and all drive mappings and try reconnect.

If it still connects through WebDav then just see if WebClient has started.  If it has, stop it and set it to Disabled.

Disconnect any and all drive mappings and try reconnect.

These are troubleshooting steps.  To see if the WebClient service is responsible.

On Windows XP provider order I have “Web Client Network” at the bottom.  I’ve never had my computers connect to the MBL using WebDav.

Thanks, Myron. I’ll try that as soon as the current file transfers complete (and that’s going to be a while!).

In the meantime, where do you set the provider order in XP? I’ll look to see if it’s in the same place in Vista.

FYI, I found how to access the order in Vista:

  1. Start → Settings → Control Panel → Network Connections
  2. Press ALT to display the menu bar, and then on the Advanced menu, click Advanced Settings.
  3. If the User Account Control dialog box appears, confirm that the action it displays is what you want, and then click Continue.
  4. On the Provider Order tab, in the Network Providers list, select the provider that you want to move up or down in the list, and then click the up or down arrow buttons to rearrange the order.

I checked mine and they’re already in this order:

Microsoft Windows Network

Microsoft Terminal Server Network Provider

Web Client Network

So it seems that it should first attempt to connect via Microsoft Windows Network, but private shares are connecting via the Web Client Network instead.

I’m still waiting for the current file transfer operation to finish to try the troubleshooting method that Myron suggested.

I feel like I’m talking with myself here. :wink:

Myron, I went into services and made the WebClient service start manually. I rebooted and reset my drive mapping. Voila! The shares connected via Microsoft Windows Network. Thank you!

I’m puzzled, though, at why when the service was enabled it wouldn’t connect via Microsoft Windows Network when that was first in my provider order list.

My win 7 box has the same order, and I’ve never had to modify the service profile. 95% of the time it connects correctly. I can often force it to connect via WebDAV if I monkey around with the URI name, but I have yet to if d the magic combo.

Under Windows XP =

Start → Control Panel → Network Connections → Advanced → Advances Settings… → Provider Order

I don’t fully know why some connections persist via WebDAV.  I’ll make a guess.

The Windows OS is already authenticated to the Samba service either as a known user or as a guest.  The OS then tries to connect again but it can’t because it’s already authenticated so the Windows OS moves along the provider order list unless one of two things happens.

  1. A network provider connects to the desires resource
  2. No network providers can connect so an error message appears.

thew With WebFolders service disabled the Windows OS can’t connect to anything WebDAV(ish) so the OS only has two options.  Connect via. Samba or fail.

The only problem I can envisiage is that WD2Go uses WebDav and the WebFolders service so without that Windows OS service, WD2Go won’t work.

I don’t use WD2Go and don’t need anything that required wht WebFolders service so got that set to manual start-up. I’ve never had an unwantewd WebDAV connection. It’s only happened when I set-up my computer to allow it.

Myron wrote:

The only problem I can envisiage is that WD2Go uses WebDav and the WebFolders service so without that Windows OS service, WD2Go won’t work.

I just tried it and found that WD2Go still works on the machine where I’ve set WebClient Service to start only manually. However, it appears that logging into the share via WD2Go forced the WebClient Service to reset itself to automatic, for after trying WD2Go I just looked at my services in Windows and WebClient is now reset to start up automatically. I had left it as manual start.

So that’s why WD2Go still worked. Sure enough, running the net use command shows that virtual drive letter established via WD2Go connected via the Web Client Network, and all other shares that were connected locally using Microsoft Windows Network.

I’m still running file transfers so I can’t reboot the machine now, but it will be interesting to see how those private shares reconnect after reboot. I’m hopeful that because those shares are mapped to drive letters as persistent connections, they’ll reconnect via Microsoft Windows Network – but we shall see. If they don’t reconnect that way I guess that I’ll be forced to disable the WebClient Service as my next step in trying to resolve this.

Will be interesting to know what happens. Please do post your findings on this thread.