Why is Windows (apparently) less secure than other OSes? Also re: NTFS fragmentation.

Please do! I am eager to try this now when I get home. Hoping I didn't imagine it now :D

You may beat me to it, I don't have local access to the required machine here, I will this evening.

We should work out some methodology.

1) I'll make sure to turn off write cache so that I can ensure the full write has completed (in line with previous benchmarks)

2) I'll restart between tests

3) I'll test windows explorer, copy and robocopy.

4) I'll be copying from one location to another on the same drive (In line with previous benchmarks)

5) I'll probably copy something from my steam folder (many, many small files). If it is explorer it should be immediately obvious.
Anything I've missed?
 
Last edited:
Not as far as I can see. When I saw the biggest difference was when moving a folder full of ripped films on my SBS 2008 server to a different HDD on the same computer. If I had let explorer do it, it would have taken hours. Robocopy did it in much less time [couldn't say exactly, I didn't stare at it! :p]

Does anyone know if there is a way for Robocopy to display its transfer rate? Or at least ETA for the entire operation? The /ETA switch seems to only show ETA per file.
 
Oxy said:
I think Oxy meant devs don't appear to be in any hurry to embrace writing software the way MS wants them to.

This.

If you take a look at this paper here, User Account Control is being very successful and it is changing the way software developers are writing software.

Engineering Windows 7 said:
Impact on the software ecosystem:

UAC has resulted in a radical reduction in the number of applications that unnecessarily require admin privileges, which is something we think improves the overall quality of software and reduces the risks inherent in software on a machine which requires full administrative access to the system.

In the first several months after Vista was available for use, people were experiencing a UAC prompt in 50% of their “sessions” - a session is everything that happens from logon to logoff or within 24 hours. Furthermore, there were 775,312 unique applications (note: this shows the volume of unique software that Windows supports!) producing prompts (note that installers and the application itself are not counted as the same program.) This seems large, and it is since much of the software ecosystem unnecessarily required admin privileges to run. As the ecosystem has updated their software, far fewer applications are requiring admin privileges. Customer Experience Improvement Program data from August 2008 indicates the number of applications and tasks generating a prompt has declined from 775,312 to 168,149.

Picture-1.png


Figure 2. Number of unique applications and tasks creating UAC prompts.

This reduction means more programs work well for Standard Users without prompting every time they run or accidentally changing an administrative or system setting. In addition, we also expect that as people use their machines longer they are installing new software or configuring Windows settings less frequently, which results in fewer prompts, or conversely when a machine is new that is when there is unusually high activity with respect to administrative needs. Customer Experience Improvement Program data indicates that the number of sessions with one or more UAC prompts has declined from 50% to 33% of sessions with Vista SP1.

Picture-1-1.png


Figure 3. Percentage of sessions with prompts over time.
 
OK so I have been playing around with copying a 16GB Steam folder and, rather annoyingly, the transfer using Explorer and Robocopy a virtually identical. I am not sure why this would be since I know I have seen Robocopy work faster in the past.

I did the same test on my SBS 2008 server, this time copying 10GB worth of movies. Again, Robocopy and Explorer seemed comparable.

I am wondering if my past experiences were a fluke or under a different set of conditions.
 
For the tl;dr crowd, I've included a chart at the bottom.

Methodology

1) Write cache was disabled

2) I copied the Sam & Max Episode 1-5 and Season 2 Episode 1-5 folders from my "steamapps" folder onto a separate data drive (to be sure no other reads or writes were taking place).

3) I copied from one location to another on the same drive (In line with previous benchmarks).

4) I did not restart between attempts, I opted instead to copy a large number of unrelated files which I did not use for the test in between attempts.


The drive I used for the test was:

Maxtor DiamondMax 10 (6V320F0)
- 320GB
- 16MB cache
- SATA/300 interface with native command queuing
- Average seek time: <9.0
- Rotational speed: 7200 RPM

Results:

Robocopy

robocopyt.png


Xcopy (I started the transfer at 01:19:00)

xcopy.png


Explorer (~2 seconds after starting the transfer)

explorerbefore.png


Explorer (About to finish)

explorerduring.png


Explorer (Immediately after transfer ended disappeared)

explorerafter.png



Summary:


chartc.png

Lower is better

Conclusion:
Contrary to popular belief there is nothing wrong with (at least) the local transfer speed of copy actions with Windows 7 explorer (x64 in this case). This appears to be a more fundamental issue; the data rate is abysmal across the board.
 
Last edited:

To ensure the full write had completed. Otherwise you could not as accurately determine the duration. This was also in line with the third party benchmarks I sourced earlier.

I certainly do not recall small files ever being such an issue that it frustrated me with XP or 2003 and the earlier benchmarks seem to confirm this was also not the case in Vista.

I find it difficult to believe it to be a bug as this was apparently the also case in the beta in February 2009 (see third party benchmarks in my previous post). I would be shocked if something like that went unnoticed for this long (especially considering just how solid the Windows 7 beta / RCs were). Regardless, it will be interesting to see if SP1 has any effect on this.
 
Last edited:
Check the linked source at the bottom of that article "Source: Tuxradar"
It goes to the article I linked earlier.

No idea what they meant by this whilst discussing file copy performance: "Obviously Windows does have to worry about some things that Linux doesn't, namely DRM checks, but these figures show a drastic performance difference between the two." (!!)
Yeah, I can't see the relevance of "drm checks" when discussing file copy performance either.
 
http://www.engadget.com/2010/03/19/charlie-miller-to-reveal-20-zero-day-security-holes-in-mac-os-x/

Just saw this posted on engadget and made me think of this thread. I particularly enjoy this quote:

"He also goes on to reemphasize something he's been screaming for years: "Mac OS X is like living in a farmhouse in the country with no locks, and Windows is living in a house with bars on the windows in the bad part of town." In other words, Apple users are "safer" (due to the lack of work that goes into hacking them), "but less secure." "
 
It appears to be the same option just with a better name in Windows 7.

What the new name suggests to me is that it disables (or more likely just very seriously relaxes) the frequency of the lazy writer flush interval. Instead in order for a true flush to occur it would require the system cache to get filled to a point where it can not feasibly store any more without causing memory pressure for the rest of the system. Or until the software program explicitly requests a flush.

The default frequency of the lazy writer is in the order of just a few seconds, I believe. It varies depending on licensed edition and, of course, these various options in Control Panel.

I might have to hook up my APC UPS serial cable so my PC auto-shuts down in a power outage. Then I can safely have a play with this option... ;)

That option actually just enables an old bug that used to be present in Windows.

http://technet.microsoft.com/en-us/magazine/2007.04.windowsconfidential.aspx
 
So, does OSX's HFS+ filesystem need defragging then? I've never seen a defrag program for it....

HFS+ defrags itself whilst in operation. At the cost of performance.

http://support.apple.com/kb/HT1375?viewlocale=en_US

- Hard disk capacity is generally much greater now than a few years ago. With more free space available, the file system doesn't need to fill up every "nook and cranny." Mac OS Extended formatting (HFS Plus) avoids reusing space from deleted files as much as possible, to avoid prematurely filling small areas of recently-freed space.

- Mac OS X 10.2 and later includes delayed allocation for Mac OS X Extended-formatted volumes. This allows a number of small allocations to be combined into a single large allocation in one area of the disk.

- Fragmentation was often caused by continually appending data to existing files, especially with resource forks. With faster hard drives and better caching, as well as the new application packaging format, many applications simply rewrite the entire file each time. Mac OS X 10.3 Panther can also automatically defragment such slow-growing files. This process is sometimes known as "Hot-File-Adaptive-Clustering."

- Aggressive read-ahead and write-behind caching means that minor fragmentation has less effect on perceived system performance.

As far as I can see, #1, #2 and #4 apply to Windows/NTFS as well. #3 can be said to apply to Vista/W7 as they auto defrag themselves based on a set schedule. Although it should be noted that #3 on OSX only seems to work for files less than 20MB. It appears to be a feature solely catered for the "ever growing log file" problem.

What is most surprising though is they state that OSX has "aggressive" write caching. Given the likelihood of a Macintosh to suffer a power cut is about on par with say a Windows desktop PC...
 
That option actually just enables an old bug that used to be present in Windows.

http://technet.microsoft.com/en-us/magazine/2007.04.windowsconfidential.aspx

I did see that but it's no longer forced to be accurate. It started out as a bug fix but clearly, if they wanted, they could have removed it in a post-Server 2003 release. Given that they only included it in a Service Pack to maintain back-compat with Server 2003's device drivers of the day. But they kept it. Which suggests to me they have possibly fleshed it out into a full feature in its own right.
 
Back
Top Bottom