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.

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.

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:Vista File I/O Like Swimming in Molasses

[martin]

the hibernate issue is well known and documented. There are several ways that MIGHT fix this, I'll leave this as an exercise to find the links ;-)

Re:Removing files in XP is very slow too

[TheThiefMaster]

This was likely because the uninstaller was removing each file one by one, or even verifying the contents of each file so it would only remove files that hadn't been changed. Just deleting the whole folder would have taken a lot less time.

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 [neowin.net]

"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.... )

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.

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?

It's just plain slow...period

[PenguinBoyDave]

My daughter got a new laptop with 1gb of memory and a sata drive. You'd think it had 256mb of memory with the time it takes to do darn near anything. The funny part is the the Linux partition on her laptop screams. Yup...that's enough to make me want to go out and buy Vista...

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: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: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: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: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: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!

[Vengeance]

I don't care about the mod points. My issues are certainly valid and to the point: An operating system should, first and foremost, allow one's system to operate. Anything that falls short of this goal is seriously deficient and *certainly* not worth my hard-earned money.

Skip the eye candy and it will be faster

[worldcitizen]

Part of the problem is that many users no longer realize what they are asking the machine to do. If you're copying a bunch of files and don't give a r4t$4$$ about watching the icons as they disappear, just minimize the window. It is not a Windows problem. On Linux when copying large amounts of files using a terminal window and displaying the names, I watch the first few seconds and then minimize the terminal window, same thing.

In my experience Vista is usually faster when copying files (because it uses larger chunks, search for an article from Mark Russinovich on the I/O changes in Vista for the details), what is slightly confusing is that the calculation of remaining time is quite slow. The copying is in progress anyway so once you get used to ignoring the "calculating...", everything is fine.

Re:Confirmed!

[zcsteele]

I have McAfee installed on my laptop (Win XP OS)- I was just experimenting with turning the on-access scanning on/off yesterday. It consumes about 10-15 MB of memory while active (pretty much an instantaneous jump when de/activated). Filesystem I/O runs noticeably faster, too, but I haven't bothered to gauge how much of a difference it makes.

Re:DOS can be faster

[MochaMan]

deltree: it's been years since I used NT, but if I remember right rd /s/q dirname should do what you're after.

Re:Confirmed!

[Gr8Apes]

Boot camp will supposedly let you play Windows games on an Intel C2D system. I'm about to find out - I installed Boot Camp on my MBP yesterday. I now have to slipstream SP2 into Windows XP, according to the docs, so that I can have 1 XP partition to run under both Boot Camp and Parallels. I'm also going to give OS/2, possibly Warp Server, a go in a Parallels partition just for nostalgia's sake.

DirectX will only work under Boot Camp, so that requires rebooting, which is a bummer but acceptable, considering that I probably will only play games on it as an exception rather than the rule. (I've gotten very used to the 1 s and ready to work with my Mac:)

You may be able to get an appropriately priced Mini or iMac off the refurbished list or ebay or craigslist, if you're really gung-ho. Or just wait until you need a new one. I'm sure your current system works nicely, my home desktop's about the same.

Re:Perhaps it's something with the NTFS system?

[gnud]

For really large files in fact (13GB or more!) deleting the file can take over a minute on most IDE based disks!

Bs.

[root:/]$ dd if=/dev/zero of=bigfile bs=1024 count=13631488
13631488+0 records in
13631488+0 records out
13958643712 bytes (14 GB) copied, 432.372 s, 32.3 MB/s
[root:/]$ ls -lh big*
-rw-r--r-- 1 root root 13G Mar 27 18:13 bigfile
[root:/]$ time rm bigfile

real 0m20.218s
user 0m0.000s
sys 0m1.952s
[root:/]$ uname -srvmpio
Linux 2.6.20-ARCH #1 SMP PREEMPT Sat Mar 24 10:51:35 CET 2007 i686 AMD Athlon(tm) XP 2400+ AuthenticAMD GNU/Linux

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.

Re:Confirmed!

[Achromatic1978]

What Linux distro are you using? I'm kinda curious, if only because I don't recall any that has no open bugs.

And no, I'm not trolling, but if you're going to describe a bug like this - which DOES affect me, and pisses me off - as being enough to classify Vista as "almost works", I really think it's only fair that you offer up something that has only bugs of lesser impact, right?

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.

Re:Confirmed!

[PitaBred]

Try Ubuntu. The 7.04 beta supposedly makes it nice, but with 6.10, it's as simple as going to www.beryl-project.org and following the instructions. It's hit yourself in the head easy with NVIDIA hardware. Haven't tried ATI, but it's only slightly more difficult from what I hear.

Re:Confirmed!

[swilver]

> man mount

Mount options for ext3

(....)

  commit=nrsec
                            Sync all data and metadata every nrsec seconds. The default
                            value is 5 seconds. Zero means default.