The Ed Bott Report

Ed Bott

What's the real story on the Windows Home Server data corruption bug?

By Ed Bott | December 27, 2007, 11:36am PST

Summary: Last week, an alarmingly terse Knowledge Base article got the undivided attention of Windows Home Server users with its warning that they risk data corruption if they edit files stored on a home server using a handful of popular programs. How widespread is this bug, really, and why wasn’t it caught during the long beta test cycle? I’ve got some inside information.

In the software industry, data-damaging bugs are every product manager’s nightmare. When a reproducible bug in this category is identified, sirens go off, vacations get canceled, engineers lose sleep, and product managers pop Maalox until it’s fixed.

That’s the context behind the alarmingly terse Knowledge Base article 946676, published last week. The entire article encompasses only a few sentences, but it got the attention of anyone using Windows Home Server:

When you use certain programs to edit files on a home computer that uses Windows Home Server, the files may become corrupted when you save them to the home server. Several people have reported issues after they have used the following programs to save files to their home servers:

Windows Vista Photo Gallery

Windows Live Photo Gallery

Microsoft Office OneNote 2007

Microsoft Office OneNote 2003

Microsoft Office Outlook 2007

Microsoft Money 2007

SyncToy 2.0 Beta

Additionally, there have been customer reports of issues with Torrent applications, with Intuit Quicken, and with QuickBooks program files. Our support team is currently trying to reproduce these issues in our labs.

I asked a senior member of the Windows Home Server team for more details yesterday. Here’s what I learned:

This is not an issue that affects every Windows Home Server installation, and the symptoms require several factors that are not mentioned in the KB article. The largest contributing factor is when a home server is under extreme load. If you’re doing a large, highly demanding file copy operation in the background and you’re using one of the listed applications to edit a file that’s stored on a shared folder on the home server, and you save the edited file to the server, then you might see this bug.

In fact, it took a long time to get a reproducible series of steps for this issue. A number of reports of data corruption that appeared to be related to this issue turned out instead to be traceable to faulty network cards, hard drive failures, or old routers with outdated firmware. It took some very detailed bug reports, accompanied by sample files and server logs, to create a consistently reproducible environment in the lab; that’s the missing piece that it takes isolate the root cause and develop a patch.

Meanwhile, backups stored on a Windows Home Server are completely safe, as are files copied to the server for safekeeping or streaming. This issue affects only files that are saved directly from one of the listed applications to a shared folder on a Windows Home Server.

No one I talked to at Microsoft is minimizing the impact of this bug. That bare-bones KB article was specifically designed to “get people to take it seriously,” I was told.

So why wasn’t this issue identified months ago, during the long beta test cycle for Windows Home Server? That’s the trouble with beta testing, as I know from firsthand experience. Last summer, after the Windows Home Server beta cycle had officially ended but before the software had been released to the public, I noticed that some program files stored on my custom-built Windows Home Server box were being mysteriously corrupted. Trying to open the file didn’t open a Windows installer, as expected; instead, a Command Prompt window opened for a split second and then closed without doing anything. The file icon was changed to a generic MS-DOS icon, and the file properties suggested that these Windows programs had mysteriously been transformed into MS-DOS programs. It didn’t affect every program, and the corruption seemed to be random.

In searching through bug reports, I found two or three other, similar reports, all of which had been closed as “not reproducible.” I filed a report anyway and heard back from an engineer who peppered me with questions. Over the course of the next few days, we narrowed down the scope of the bug and created a repro test case:

The files had to be fairly large, at least 2 or 3 megabytes in size.
They had to have been downloaded from the Internet on a Windows machine, which in turn adds an alternate data stream (ZoneIdentifier) that blocks execution of the file without user consent.
They had to have been uploaded to the Windows Home Server from a machine running Trend Micro antivirus software. Other AV and security programs didn’t trigger this bug.

That’s a fairly complex series of conditions, and it’s not surprising that it took some time and sleuthing to identify the exact sequence of conditions. But when the issue was documented in Knowledge Base article 943393, none of those additional details were mentioned.

That bug was patched within a few weeks after the KB article was published (the details are in KB article 941914), and the fix was pushed out in mid-November to any Windows Home Server box via Windows Update.

I fully expect the current bug to be patched fairly quickly now that a repro case is available. Meanwhile, it pays to be conservative and heed the advice of that KB article, even if the odds are relatively low that this particular bug will strike you.

Kick off your day with ZDNet's daily e-mail newsletter. It's the freshest tech news and opinion, served hot. Get it.

More from “The Ed Bott Report”

IE6 crashing? Here's the reason, and the fix

Who's choosing XP over Vista?

Topics

Article, Microsoft Windows Home Server, Server, Bug, File, KB, Microsoft Windows, Operating Systems, Servers, Software, Hardware, Ed Bott

Ed Bott is an award-winning technology writer with more than two decades' experience writing for mainstream media outlets and online publications.

Full Bio
Disclosure
Contact

Vendor HotSpot

The 360° Conversation around Cloud Computing

TECH VISUALIZER brings the social conversation to life... powered by Brocade

Learn More »

117

Comments

Add Your Opinion

Join the conversation!

Follow via:: RSS; Email Alert

Just In

Another Oops from Redmond…

Ole Man 4th Jan 2008

And more chutzpa..........

http://www.lockergnome.com/theoracle/2008/01/02/another-oops-from-redmond/

"With so little for Microsoft to celebrate
over the past year, after defeats in Europe
and Vista sales a depressing disappointment
worldwide, the news breaks that a small
bright spot, Windows Home Server, has some
serious troubles."

View in thread

Please Select
Please Select

0 Votes

+ -

apology accecpted (nt)

n0neXn0ne 27th Dec 2007

Reply
Flag

0 Votes

+ -

That's OK Ed...

D T Schmitz 27th Dec 2007

..it's not like WHS is even a BIG market anyhow.

Reply
Flag

0 Votes

+ -

Home users combing MS KB's?

Chad_z 27th Dec 2007

I can't really see most home users combing MS KB articles, can you? Most are lucky to be able to find the power switch.

When you pay for a software...at least when I pay for it...I expect it to be a solid product that adds value for the money. With MS products I find myself frequently going back to the KB articles to sort out the issue of the day.

I do the same thing on Linux, btw, only in the Ubuntu forums instead of MS KB's. The difference is I pay for one and the other is free. I don't have to justify the value proposition with Ubuntu. It's a functional, robust operating system fully loaded with a feast of productivity applications and hundreds more mere mouse clicks away. In exchange for that value I have to occasionally spend time in the Ubuntu forum figuring out a minor tech issue, though not nearly as often as I did with 7.04. Fair trade.

Not sure it's reasonable to expect home users to be patient with something like this or be able to figure out how to resolve it. And if you are, what's the advantage to giving MS your money? I see money changing hands but where's the value?

Reply
Flag

0 Votes

+ -

Contributr

Windows Update

Ed Bott 27th Dec 2007

When the fix is available. it will be delivered via Windows Update, automatically. You shouldn't need to comb any KB articles, and most people - the overwhelming majority - will never encounter this bug. There were more than 100,000 beta testers for WHS, and so far this issue has been reported by "several people."

The average user who buys WHS and uses it for its primary purpose of backing up home PCs and streaming music over the home network will certainly never see it. The fact that the issue is being jumped on quickly and has been documented in a KB article is a good thing, IMO.

Reply
Flag

0 Votes

+ -

But then again

Michael Kelly 27th Dec 2007

if there's a fix available in Ubuntu, you get automatically updated as well. So again, where's the added value?

I don't question that MS is jumping on this. I do question how this got by their beta testing. Was this error reproduced on the beta builds too (in other words, is it possible that only the RTM is affected)? If the error is on the bets builds too, then they have to seriously question their whole beta process. Out of 100,000 testers, this scenario should have popped up more than once.

0 Votes

+ -

If you see no value then don't buy it.

ye 27th Dec 2007

Yes, it really is that simple.

0 Votes

+ -

re: ... don't buy it? It comes preloaded! (nt)

n0neXn0ne 27th Dec 2007

x-(

0 Votes

+ -

re: don't buy it? It come preloaded

M.R. Kennedy 27th Dec 2007

n0neXn0ne:

Preloaded on what? An HP MediaSmart WHS box, for example?

If you don't want one, don't buy it. Sheesh!(tm)

0 Votes

+ -

too late now ... (nt)

n0neXn0ne 27th Dec 2007

x-(

0 Votes

+ -

Hah!

KTLA 27th Dec 2007

You bough a WHS box, only to be surprised that it came preloaded with WHS!

That's nice! Try looking before you buy next time...

(Man, that's rich stuff, there, always fun to tell coworkers of the C/ZDnet idiot move of the day!)

0 Votes

+ -

On what?

gadawg2 31st Dec 2007

I am interested in learning more about this....

0 Votes

+ -

No kidding

Michael Kelly 27th Dec 2007

But we were hoping that MS would provide some added on value. And having an engineering core that looks after little things like this on the customers' behalf usually is one of those added values that proprietary gives you over F/OSS.

I actually like the idea behind WHS. I think the features they offer do provide value. But file corruption takes away all the added value that those features provide. So I agree, if we're not going to get the added value we bargained for, we should not buy it. Though I'm sure MS has better business sense than you do and will try to address the problem rather than blow the customer off and say "if you don't like it, don't buy it."

0 Votes

+ -

So you're saying it doesn't add value because of a bug?

ye 27th Dec 2007

Seems pretty stupid if you ask me.

0 Votes

+ -

Now that's odd...

ego.sum.stig@... 27th Dec 2007

Because you seem to decry, shall we say any and all non-Microsoft products, if they have a bug or two.

Ah well...

0 Votes

+ -

Data corruption is a show stopper

voska1 28th Dec 2007

What the point of this server if it's going to corrupt you data?

0 Votes

+ -

Contributr

Show stopper, yes, but...

Ed Bott 28th Dec 2007

This particular bug doesn't affect backups. It doesn't affect music streaming, It doesn't affect file copying or moving. It doesn't affect opening, editing, or saving files with applications that are not on the list. The simple workaround is to avoid saving files directly from one of the applications listed here.

So yes, it's a show stopper bug as is any data-damaging bug, and it should be treated as a top priority. But its impact on the day-to-day use of a WHS box is very, very llimited.

0 Votes

+ -

I fully agree with what Ed is saying

Michael Kelly 28th Dec 2007

Yes, this is a major bug, and yes, this is being given top priority and will be fixed.

So moving forward, I hope that MS takes a long hard look at their beta process and figures out how something so debilitating and so commonly used could have slipped by. We shouldn't dwell on this, but they certainly should.

0 Votes

+ -

Contributr

That was the point of the second half of this post

Ed Bott 29th Dec 2007

"Out of 100,000 testers, this scenario should have popped up more than once."

It did. There were reports that were filed during beta testing, but they couldn't be reproduced. In fact, even after the issue was reported after RTM, it took a lot of work and cooperation between a test engineer and a beta tester who was willing to share logs and detailed steps to help find a repro case.

Look, file corruption bugs get reported all the time. Most often, they're related to problems with hardware or third-party apps. This particular bug is apparently quite hard to reproduce. So someone hits it once, files a bug report, it can't get repro'ed, the engineer asks for more details. The beta tester may try to repro it and not be able to do so because the particular set of circumstances that triggered it is no longer operative, or they're too busy, or they have rebuilt the test system, or they don't have the skills to do a really controlled test.

That's the problem with beta testing. There's a lot of noise to go along with the signal.

0 Votes

+ -

Big difference there

Chad_z 27th Dec 2007

When the fix is available. it will be delivered via Windows Update, automatically

Now there's a big difference. With Ubuntu you have to move your mouse pointer all the way up to the corner of the screen when the orange update button is visible. You have to click on that, look at the updates, click install and type in the administrator password.

Whew! Mercy me I have the vapors from all that work. wink

and most people - the overwhelming majority - will never encounter this bug.

Oookay. But the few that do will have corrupt files...potentially important files...that may be unrecoverable. That seems like a pretty big handicap for a backup device.

This may sound odd coming from me but I don't dislike MSFT or Windows. I used to hire former MS workers and they were super. Still are judging from your description of the reaction from the WHS team. And I support Windows and develop on that platform...although I think it's a clunky dev environment and I'm preparing to shift away from supporting MS. My issue with the company and their product line is value. Around ten years ago or so MS started coasting more than innovating. That trend has accelerated over the years. Now it seems as if MS is charging more and more while delivering less and less. Again, I'm speaking collectively, not individually.

Okay, most users won't have a problem. I can point to some nifty OSS systems that have network storage capability and the majority of people won't have any problems using them, either. Seems kind of samey-samey considering the cost difference.

0 Votes

+ -

Wrong difference

Patanjali 31st Dec 2007

I think the post was answering the reference to having to trawl through KBs. Compared to that either WU or the orange button is a trivial effort.

Given the number of ANDs to reproduce this bug and its target market, I think it is low risk. I doubt that there would be any significant software that would not have at least one of such convoluted bugs: they just haven't had the problem scenario occur for someone.

And what is the tie-in with Trend software? This 'bug' may be a result of several bugs in mutiple software. Finding it is one thing, fixing it is another (assuming the true cause is actually found).

0 Votes

+ -

The real story is...

bjbrock 27th Dec 2007

files are being corrupted on WHS. Trying to sugar coat the problem makes you look like an idiot.

Reply
Flagged

0 Votes

+ -

re: The real story is...

Badgered 27th Dec 2007

The real story is... files are being corrupted on WHS. Trying to sugar coat the problem makes you look like an idiot.

I wouldn't go calling someone an idiot over it, but I agree with your point. It's a serious bug. IMO it should not be minimized by saying, you'll probably never run into this problem. On the bright side the WHS Team at MS does seem to be taking it very seriously.

Reply
Flag

0 Votes

+ -

Perhaps the wording...

bjbrock 28th Dec 2007

was a bit strong. But minimizing issues like this is why there are so many issues to begin with.

Microsoft charges premium prices for their products and should be held to higher standards.

0 Votes

+ -

Contributr

No one is minimizing this issue

Ed Bott 28th Dec 2007

If anything, Microsoft has chosen to overemphasize it by not calling out any of the mitigating factors in its KB article. If they were minimizing it, they would have written a much more detailed article that described the conditions under which this bug occurs.

I'm not minimizing it either. Any data-damaging bug should be treated as a top priority and fixed as soon as possible.

So I'm not sure I understand your point.

0 Votes

+ -

Perhaps I misinterpret ...

bjbrock 28th Dec 2007

your article. But as I reread it, it sounds as though you are minimizing its seriousness. Perhaps because you stress how unlikely it is that a user will be affected.

This is how your article reads to me anyway.

I'm tired of patching software month after month of its ENTIRE life cycle. No matter who writes it. No other product in the world has such track record as software.

0 Votes

+ -

Contributr

Sorry you read it that way

Ed Bott 28th Dec 2007

I found the original article alarming because it was so brief, implying that this bug could hit anyone at any time. That's why I gathered more facts and shared them here. I thought I made it pretty clear, like in the first paragraph, that data-damaging bugs have to be patched as quickly as is humanly possible. It's also important that users understand all the issues involved.

I don't currently use any of these programs to edit files stored directly on my home server,and I won't until this bug is fixed.

0 Votes

+ -

Too many variables and unknown interactions

Patanjali 31st Dec 2007

Very few objects besides software have so many interactions, within themselves or with other objects. Then add that they are often competing for resources with the software with which they are interacting and with all the other services running at the same time. Practically every high level language instruction involves a myriad of interactions, even without multiple threads. Sometimes I'm amazed that it even works beyond a few seconds!

The only similar scenario is that of automotive engineering and we have seen what happens when something does not work as expected: huge recalls! But that is mainly because the huge variations of temperature and vibration that occur during actual use have not been adequately engineered for.

0 Votes

+ -

... people have poor work practices

aep528 27th Dec 2007

Sorry, but I would NEVER edit a file stored on another machine. I've seen too much
data lost at work due to people editing files on a server. I don't care what OS the
remote machine is running - there are too many variables. Any
network/power/software issue in the path to the remote machine can occur
without warning.

Edit local copies, back up to the server. It's very, very simple.

Reply
Flag

0 Votes

+ -

re: people have poor work practices

spam@... 27th Dec 2007

That approach is certainly an option but without tools to syncronize files it can be a very expensive practice if you use more than one computer at your company (you did mention WORK0. I know I use several at work, use the web for remote file access, and work at home via vpn which means I might touch 6-8 computers in a given day. In your scenario I'd better make sure I sync every time I move from machine to machine or I run the risk of overwriting data. If you use the server approach you benefit from RAID/SAN, centralized backup, file recovery, anywhere availability, UPS, generators, etc.. It is much more likely that you will lose or not be able to get at data when it is stored on a client computer versus stored on a cluster of servers.

Now if you are talking about server in the context of this article rather than enterprise grade servers at a WORK place and not at HOME then you have a point as demonstrated by this knowledge base article.

0 Votes

+ -

Files stored on WHS as archved

M.R. Kennedy 27th Dec 2007

spam:

As I explained to a fool in another forum here (Jason Perlow's guest blog entry under Mary Jo Foley's byline), if you're stupid enough to edit your archival files (photos, music, documents, whatever) on the server itself, you deserve whatever data loss or corruption you get from doing it.

The smart thing to do is to copy the file to be worked on to the client system, fold, spindle, mutilate as needed, rename the file, then copy it back to the server. That way, you still have the original, as well as the modified file.

This is a "best practices" operation for anyone using a server, whether it be WHS, a Linux distro, or any other small server package at home. Note that I said at home, and not at work.

The fool's response? It would be just too much trouble, and if he had to do as I'd suggested, what would be the reason for having a centralized home server on which to store his files? Why, it would simply be a waste of his time and money!

Please...

As Ed pointed out in his blog, it will take one or more specific hardware/software combinations (and rare ones at that) to reproduce the data corruption problems that WHS has had with certain applications. And, Microsoft is working to correct those problems. That in itself is a Good Thing, and shows that they're being both responsive and responsible.

0 Votes

+ -

Perhaps...

NetArch. 28th Dec 2007

Perhaps Microsoft (and other software vendors with products that run on MS operating systems) should warn the user that editing a file on a remote computer could possibly result in corruption?

While we all may cringe when we see people do "stupid" things on computers - it's generally out of ignorance, not stupidity.

Remember for years in the Unix workstation environment that users' home directories were typically remotely mounted via NFS off a centralized server. Perhaps smart application developers would have their applications cache temporary file saves to a local directory, and only do a final commit to the server when the user actually closed the application.

The ultimate goal of pervasive computing is that the software gets smarter, and the user just doesn't have to think about such low-level things. It's time we actually start demanding that software be more bullet-proof, rather than accept the standard "use at your own risk". Would you fly a modern fly-by-wire commercial airliner if Boeing's or Airbus' software developers adhered to the same standards as Microsoft, or, god-forbid, "Joe's Neighborhood Software Development Shop for Windows"?

0 Votes

+ -

I actually agree with this...

BitTwiddler 27th Dec 2007

I know it's done for 'collaboration' purposes, but editing files stored on a network is asking for trouble.

One of the worst thing I see clients do, and I get them to stop it immediately, is storing their active/attached Outlook PST files on a server. In these cases it's not if, but WHEN your PST gets corrupted by something as simple as a router reset, server reboot, etc... and usually losing the data in a 5+GB PST file is a tragic occurance to the user.

0 Votes

+ -

Eh?

bportlock 28th Dec 2007

"but I would NEVER edit a file stored on another machine."

What kind of toy network do you have? Most workplace networks - MS or otherwise - routinely map drives all over the network and often discourage users from doing anything on their own PCs as is may not be archived, searched or backed up correctly.

"Edit local copies, back up to the server. It's very, very simple."

It is also a good way to lose your data. I copy a document, some else copies the same document, I edit it, save it, they edit it save it and my changes are gone! I've seen it happen. Editing in place so that the document is locked stops it.

"Any network/power/software issue in the path to the remote machine can occur without warning."

And any PC can stop without warning for exactly the same reasons.

As far as WHS goes, there is a problem and it needs fixing, not excuses.

0 Votes

+ -

Contributr

Let's step back a minute

Ed Bott 28th Dec 2007

I agree with you that files stored on a network should be available for editing and saving. I think the people who are arguing that this is a problem with networks or servers are way off base. This particular bug isn't about the network, and Microsoft's guidance is not to stop editing all files stored on a WHS machine.

The programs on this list have some characteristics in common, notably that they save data incrementally and are not strictly file-based. OneNote saves its notebooks constantly and incrementally. Money syncs constantly and incrementally. Outlook syncs constantly, SyncToy, well, you get the idea. All of those programs save user data incrementally in the background and don't require the user to explicitly save a file. There's probably some sort of interaction between that type of file-saving activity and the Drive Extender technology in WHS, which does a fine job with conventional file saves such as those you would do if you were editing a Word doc or Excel spreadsheet or a video file or another file-based data type.

0 Votes

+ -

Ed,

Cardinal_Bill 27th Dec 2007

I still say that an OS which can't detect that the data being transfered to it or from it, no matter what's in between, has been corrupted is a piece of dung.

That part of the answer is a cop-out. Loading on the server is a cop-out.

Reply
Flag

0 Votes

+ -

NTFS is a little long in the tooth (nt)

n0neXn0ne 27th Dec 2007

x-(

Reply
Flag

0 Votes

+ -

Aside from...

Cardinal_Bill 27th Dec 2007

the fact I wasn't talking about file systems...I was talking about the OS. Second time in the last two, IIRC, months that Microsoft has blamed hardware on it's OS's inability to detect data corruption.

As an aside, NTFS may be old, but would you accept that it'd corrupt data because of a "faulty router" in the middle? I didn't think so.

0 Votes

+ -

The file system...

Stuka 28th Dec 2007

...is what handles the files, and what would be used to detect data corruption. The only way for the OS itself to do it is with checksums, which could really slow down large file transfers. File systems like ZFS have automatic checksumming built into them, which would basically make data corruption a thing of the past.

MS's answer is quite plausable. I work in network oriented software development and I have seen stranger things happen.

0 Votes

+ -

For MS a file that is only 2-3MB is "fairly large"

wackoae 27th Dec 2007

I have to laught when I read the part about "The files had to be fairly large, at least 2 or 3 megabytes in size."

It is ridiculous to think that this day and age, a 2-3MB file can be considered "fairly large" by a company like MS. Save a file for any of the following and you are already way past the size that MS considers "fairly large"
- An MS Office document that includes 2-3 images.
- An MP3 file with a song.
- A low quality MPEG video file.
- An AVI file with more than 10 secs of video.
- A WMA file (audio only).
- A "Hello World" type .Net executable.

"Fairly large" what a joke.

Reply
Flag

0 Votes

+ -

Contributr

Sheesh

Ed Bott 27th Dec 2007

I was describing the beta-testing process. This server had thousands of files on it. The particular bug I described never occurred on files under 2.5MB in size, which represented about 50% of the files on the server. So part of the testing process was to identify that file size was a factor.

Some people will argue over anything.

Reply
Flag

0 Votes

+ -

Yahbut...

Cardinal_Bill 27th Dec 2007

it's supposed to be a server for sharing files. Audio/video files. My audio files average around 7MB each, I have around 10000 files using 73GB of drive space (yes, I own all of the music). Some of them are really, really small...in the 250KB range and some are pretty big...about 50MB seems to be the biggest mp3 I have from a CD I own, I also have some that range from 170 MB to 575MB from streamed audio.

So, if it fails at 2.5-3MB per what would it do with a "LARGE" file? Do I edit these files? Not them, but I do record from LP's into wav format (running 50-100MB a pop) and then convert to mp3's and edit them. Across my little dinky network at times.

Since I don't do video I have no direct knowledge of them other than thinking they're larger.

No, I don't expect an answer from you. I just wanted you to realize that some of us have different expectations when a file is called "large" and we expect better answers than "It fails on large files". Microsoft dropped the ball testing.

0 Votes

+ -

Contributr

Jeez, are you listening?

Ed Bott 27th Dec 2007

The word "large" was not in any communication from Microsoft. It was part of the process of testing that an MS engineer and I did to verify the bug described in a previous issue. File size was one of FOUR criteria that affected whether this bug fired and was why it was so hard to find a repro case.

"So, if it fails at 2.5-3MB per what would it do with a "LARGE" file?"

There are three other factors involved in this bug, which was patched in November.

Sheesh.

0 Votes

+ -

My aren't we prickly!

Cardinal_Bill 27th Dec 2007

Your definition of "large" is faulty. The "Server" is intended, so it was said, for audio/video files. Your small files created a situation where it's a faulty test using unrealistic parameters.

You need to take a vacation.

0 Votes

+ -

You just love to argue...

Stuka 28th Dec 2007

Large is a completely reletive term. If 50% of the files are under 2.5MB, then that upper 50% is made up of the larger files. Fairly large would mean that its larger than the lower 50%, but not the largest files on the drive.

You have obviously NEVER worked in software QA. If you had, you would not be arguing over such frivolous issues and instead be paying more attention to the larger issue.

0 Votes

+ -

"Cardinal" Bill

justanitguy 28th Dec 2007

Bill, you have been demoted to priest for not listening (reading), for being pedantic (look it up) and for being annoying.

0 Votes

+ -

I'll make...

Cardinal_Bill 28th Dec 2007

one more stab at this and then give up.

Ed did a fine job of reporting how he managed to reproduce the error.

I took issue with Microsofts position that the hardware in between computers can cause data corruption and that they don't need to worry about it because it's not their problem.
I commented that his definition of a "large" file, his original was to someone else, didn't exactly fit what you would expect to find on a server for audio/video files. He became irate that I would question him.

OK...everyone be happy...don't worry...smile...

0 Votes

+ -

Contributr

What you still don't understand...

Ed Bott 28th Dec 2007

Is that the experience I described was with a completely different bug. This bug affects only executable files, not audio/video files. I have a folder containing several hundred downloaded programs and associated files. Well over half of the 4000 files in this directory and its subdirectories are under 100KB in size. DLLs, icon files, readme files, etc. Among the 223 executables, 121, or more than half, were smaller than 2.5MB. An additional 39 files were under 8MB in size.

Again, this older bug, the one I discovered last summer which was patched in November, affected only executable files.
The bug did not affect files under 2.5 MB at all. It affected all exe files over 8MB. It affected fewer than half of the exe files between 2.5 and 8MB in size.

I hope this additional level of detail can help you give up on this obsession over the word "large.: If not, then I freely confess that by some definitions, 2.5MB isn't really large and you may just ignore that clause of the sentence and simply pay attention to the actual technical details.

0 Votes

+ -

Ed,

Cardinal_Bill 28th Dec 2007

You are correct. You did say you were talking about executables, etcetera and in that case 2-3MB would be considered large.

Which is different than:
> "When you use certain programs to edit files on a home computer that uses Windows Home Server, the files may become corrupted when you save them to the home server."

So, is your ability to produce consistent failures related to what the KB is talking about? No, I'm not trying to be a wise ass here. It's just that it sounds like you might have found something related, but not what the KB is talking about. Maybe a clue to their problem. My personal theory is, still, that there's a bug in the network stack and when it's overloaded it fails to tell the sender to stop transmitting, causing it to flush data down the drain and not acknowledge it has done so. Wasn't this portion of the OS recently rewritten?

0 Votes

+ -

Contributr

Let me try again...

Ed Bott 28th Dec 2007

I appreciate your willingness to listen and understand. I'm really not trying to be prickly or rude. But if you would go back and read the entire post again, without rushing through it, I think you might get it. I could be wrong, but you seem like an intelligent person who just misinterpreted something on a first read and needs a reset.

The issue I talked about in the second half of the post was a COMPLETELY DIFFERENT BUG from the one being talked about in the past week. I told the story of that older bug to illustrate the difficulty of getting reliable reproducible bug reports.

My work on the issue from last summer with executable files resulted in a repro case and a patch. The patch was issued in early November.

The current bug is a completely separate issue. My bug (from last summer, patched in November) was with exe files. This bug (from December, unpatched) is with programs that save files directly to a WHS machine. They all have in common that they do not save data in conventionsl File/Save ways.

These are two different bugs. Two. Different. Bugs.

The older bug is related to antivirus software interfering with the proper saving of a file that contains alternate data streams. This bug is (I believe) caused by software that saves files in unconventional ways.

You speculate that this might be related to the network stack, which was 'recently rewritten." No. You are, I presume, referring to the new Vista/Server 2008 network stack, which is indeed rewritten. WHS uses the code base from Windows Server 2003, fairly old, not rewritten at all. The culprit here, I believe, is the Drive Extender technology, which is unique to WHS and is what allows it to present all data files as a single shared folder even when they are located on different physical disks. The DE technology sits on top of NTFS and is the major variable here that makes this product different from its forebears.

Hope that helps.

0 Votes

+ -