Vista Slow To Copy, Delete Files

Bruce Schneier has said that trying to make digital files uncopyable is like trying to make water not wet. With Vista, Microsoft seems to have done a pretty good job of making premium content files not copyable. Now a few readers have tipped us to a new wrinkle: Vista also makes it very, very slow to copy, rename, or delete ordinary files. Here is a Microsoft TechNet thread on the problem. The Reg reports that Microsoft has a hotfix for what sounds like a subset of the more general problem complained about on TechNet; but they will only give it to customers who ask nicely. And a hotfix is fussier to install than a proper patch.

Comments

Confirmed!

[yoyhed]

I can confirm this. Copying a 10MB file from one directory to another on the same partition, on a fast 7200rpm 16mb cache SATA 1.5gb/s hard drive, can take 5-10 seconds, whereas it's instant on XP for me.

Re:Confirmed!

[whathappenedtomonday]

5-10 seconds? That's really fast! Try this on a dual boot system with 2 partitions, XP on C and Vista on D: double click a ZIP file on your XP partition from inside Vista and copy the files inside the ZIP to your Vista D partition (which shows up as C anyway). I got a whopping 8-30 bytes per second that way recently and waited about 10 minutes for a few images to crawl from the XP partition ZIP temp folder to the Vista partition. I didn't try if copying the zip to the Vista partition first would speed things up, but I guess it would have helped a little.

Bottom line: file operations in Vista suck, even if your HD is fast and you have lots of RAM.

Re:Confirmed!

[databyss]

I have this problem on Vista and it's not so much that it's unusual... it's more mind boggling.

I confuses me deeply... I hadn't thought to associate it with content protection. Now it's simply aggravating.

Copying a few files, no matter what the size, pops up a "Calculating transfer time" window... I'm talking files where the total sum is 10MB even. It's unnecessary.

The transfer itself will often go faster then the calculation. Apparently the calculation is doing more than just figuring out file transfer size.

Re:Confirmed!

[Gr8Apes]

But how do you miss a fundamental core process? That's like hmm, should we see if IE7 connects to the internet? Naah, no need, of course it does.

I've noticed issues with Explorer deleting/copying/moving files (since the IE switchover). This is in XP btw, not Vista, so I'm not so sure that it's due to rebuilding anything. It's bad enough that I drop to the command line when I have a particularly large directory tree of files to delete or copy (we're talking a few 10s of thousands of files here in a heavily treed directory structure). Takes almost no time from the command line. Whatever explorer does adds eons (in computing time) to the process.

Isn't the big "secret" of Vista that they actually didn't rebuild so much of it, but took the 2003 server codebase to start from and yet again slapped "pretty" on it?

Re:Confirmed!

[yeremein]

Copying a few files, no matter what the size, pops up a "Calculating transfer time" window... I'm talking files where the total sum is 10MB even.

Do you see that with few larger files, or lots of smaller files?

I just did a few tests on Vista Ultimate x64 on an Athlon X2 3800+ machine with 2GB of RAM:

10 files totaling 10MB = instant
675 files totaling 5MB = about 15 seconds

The latter window popped up a "calculating remaining time" window, but I could see in the folder view that it was copying files the entire time. So it's not that it spent more time calculating than copying per se--it was calculating while it was copying, and didn't get a time estimate until it was almost done.

Re:Confirmed!

[Splab]

You should keep care to know that the copy operation hasn't completed necessarily under Linux. A good example is ext 3, where it can take as much as 5 seconds before it even thinks of writing the log to the disc.

Try doing a sync after you have made a copy of a file - the operation isn't over until sync completes.

Vista File I/O Like Swimming in Molasses

[N8F8]

I used to get frustrated waiting for large file copies in XP but Vista is horrible. I can't get it to un-sleep properly either. I'll drop the lid and open it later and hit a few keys. 2 minutes later the screen is still black so I'll try to shut it down or start it up and I wind up holding the start button for 10 seconds to get anything to work. It's also annoying that 90% of the time the battery is still drained when I shut the lid.

Not XP's fault

[yoyhed]

That's not XP's fault, that's the fault of the software's uninstaller - it was one of those that manually checks for each file it installed being there, then deletes it, then goes to the next. Those are so annoying! I wish they'd at least give the option to just delete the whole install directory (which XP would do pretty much instantly, even with thousands of files).

Re:Not XP's fault

[_xeno_]

That's a very dangerous option to offer. There were stories about how Mozilla's uninstaller would delete your entire harddrive based due to exactly that option.

What would happen is that people would install Mozilla to "C:\" and later uninstall Mozilla. The uninstaller would give them the option to delete the original install directory, and then: presto, massive file delete. (Of course, you have to wonder why anyone would install to "C:\" but apparently enough people did.)

In short, it's always best to check each and every file you installed to make sure it hasn't been modified since install prior to deleting it. Otherwise you risk accidentally deleting files the user doesn't want deleted.

Re:Whah?

[leuk_he]

No that guy is just keeping the low level of bug reporting that all are doing in that technet thread.

If you did google for the "bug" you might have come accross this

"Start >> Control Panel >> Programs and Features," Turn windows features on or off" ,Uncheck "Remote Differential Compression"

I think that is only for the network problems, not for the generic copy or delete problems (not sure, reports are not good)

I have seen also reports about vista that is has problems with large sparse files, but i haven't taken the time to reproduce. (will do later, but every 30 days it seems i have to evaluate windows vista again.... )

Insightful?!

[jimicus]

How can this be insightful? This is a reworking of an old troll, which originally went like this:


I don't want to start a holy war here, but what is the deal with you Mac fanatics? I've been sitting here at my freelance gig in front of a Mac (a 8600/300 w/64 Megs of RAM) for about 20 minutes now while it attempts to copy a 17 Meg file from one folder on the hard drive to another folder. 20 minutes. At home, on my Pentium Pro 200 running NT 4, which by all standards should be a lot slower than this Mac, the same operation would take about 2 minutes. If that.

In addition, during this file transfer, Netscape will not work. And everything else has ground to a halt. Even BBEdit Lite is straining to keep up as I type this.

I won't bore you with the laundry list of other problems that I've encountered while working on various Macs, but suffice it to say there have been many, not the least of which is I've never seen a Mac that has run faster than its Wintel counterpart, despite the Macs' faster chip architecture. My 486/66 with 8 megs of ram runs faster than this 300 mhz machine at times. From a productivity standpoint, I don't get how people can claim that the Macintosh is a superior machine.

Mac addicts, flame me if you'd like, but I'd rather hear some intelligent reasons why anyone would choose to use a Mac over other faster, cheaper, more stable systems.

Its an old TROLL post...(funny not interesting)

[acomj]

Its an old mac bahing troll post that used to appear in every mac story, and was completely inaccurate. the author just switched some of the names.....

What I find a little scary is now its moded interesting...

Hotfix versus patch?

[kiwimate]

The Reg reports that Microsoft has a hotfix for what sounds like a subset of the more general problem complained about on TechNet; but they will only give it to customers who ask nicely.

That means it's not available on the general download site; you have to ring up and ask for it. That's all. Unless you have premier support, in which case it's available on the premier site.

And a hotfix is fussier to install than a proper patch.

?

How so?

I've had this issue

[The Mysterious X]

But, after a week or 2, it suddenly cleared up.

I never did track down the cause of it, but disabling volume shadow copy and indexing did mitigate the problem a little.

Once it cleared up, re-enabling them did not cause any problems.

My simple results

[DnemoniX]

I run Vista Business Edition on an AMD64 X2 4200 with 2 Gigs of ram. Performance wise I haven't had any real issues with this exception. I read several posts, flamers and fan boys aside here are my results. I used a folder containing 51 files for a grand total of 142 megs. When I copied this folder from one hard drive to another on my box (both are WD Raptor 10k rpm sata drives) and viewing the "More Details" on the copy dialog Vista reported a speed of 22Mb/sec. When I copied the same folder from my desktop to one of my network shares the dialog reported a top speed of 441kb/sec and said it would finish in 7 minutes. When I ftp the folder to one of my servers it averaged out to 7,997.3kb/sec and took 24.63 seconds. Seems to me something is a bit off...

Re:I just tried

[Barny]

For those unwilling to read the forums (or who block all MS sites at their router), the problem relates to Vista making thumbnails of files, and trying to continue making them even when you have told it to delete a file, its not a transfer speed problem, and can be VERY easily stop gapped by disabling thumbnail views in the folder view settings :)

The thing I personally have a problem with in vista is folder browsing, I have not spent money on a good raid array (and made sure it had vista drivers) and lots of HDD just to have a half second pause when I double click ANY folder.

Re:DOS can be faster

[evilgrug]

deltree functionality was sensibly incorporated in the rd/rmdir command a while back -- rd /s is the same as the old deltree.

Re:I just tried

[drinkypoo]

In Linux, when you delete a file, it gets deleted. I don't know exactly how this works under the covers... maybe Linux pretends to delete it until everyone lets go and then deletes it for real, the difference is, you don't have sit around and struggle to tell the computer you want to delete a flippin' file, or give up and come back later.

The way in which it is handled in Unix in general is that the link count is decremented. When the link count is decremented to 0, the file can no longer be accessed, as in new requests. However, the system keeps the file open and the blocks marked as in use until the last application with the file open lets go of it. Then the blocks are marked free. If the system goes down while a process is still holding the file open, and thus the blocks are marked as being in use, you will need to fsck to free those blocks for use. Journaling filesystems worth using will figure it out for themselves.