Since weekend update, small files up to 4096 bytes get cor..

YES I have been in a losing battle with Msoft support since thursday last
week.

For me, Its KB920958 and it can be forced to happen if the data folder is
compressed (with explorer) and trigger it to happen immediately with a
chkdsk c: /f and a reboot
otherwise you have to wait for a while for it to go bad. We assume the
compressoin is done by a LAZY process and sin't immediate.
I don't think its the length as once the file is corrupt I have edited the
contents to other values and replaced it without a problem, there must be a
trigger byte sequence or something.
If you look at the file with the 2000 resource kit dskprobe sector editor it
complains about the length.
Are you using compressed folders for yourr data cos I can't get it to fail
otherwise and that seems to be my key trigger.
We have disabled antivirus and gone through hoops to prove the point.
Keith

"Pegasus (MVP)" wrote in message

> Multi-posted - see your other posts. Please use cross-posting
> if you wish to address several newsgroups. Multiposting wastes
> everybody's time.
>
>
> "Andy Schmidt" wrote in message
>
> > Hi,
> >
> > I have two different servers (different models and manufacturing years),
> but
> > both of them running Windows 2000 server with software mirrored NTFS
> drives,
> > which suddenly corrupt small image thumbnail files after an hour or two.
> >
> > No larger file sizes seem to be effected. The file content is set to all
> > binary 0xdf.
> >
> > If we replace those files with valid copies, then those files will
appear
> to
> > be correct for a while (probably read back from cache) but after some
time
> > they will "revert" back to all 0xdf.
> >
> > I have since been in contact with another customer who has the exact
same
> > problem with his Windows 2000 server also since around the past weekend.
> In
> > the days prior we did install recent security fixes and Microsoft
product
> > updates that were released in the past month.
> >
> > Is there anyone else out there with the same problem?
>
>
 >> Stay informed about: Since weekend update, small files up to 4096 bytes get cor.. 

Hi Keith,

Let's please try to compare commonalities:

- Yes, on both servers those folders and parent folders have the compression
flag on.

- On both effected servers, the disks are defined as "dynamic"
- They are software mirrored (using Windows 2000' Disk Management)
- On both servers the files show all 0xDF characters (which shows up as the
German special 's', looks a little like a B or a beta character.)
- We run NetShield 4.5 with the 5.1.00 scan engine

How does that compare with your environment?

Andy
at Argos.net


"KeithMail" wrote:

> YES I have been in a losing battle with Msoft support since thursday last
> week.
>
> For me, Its KB920958 and it can be forced to happen if the data folder is
> compressed (with explorer) and trigger it to happen immediately with a
> chkdsk c: /f and a reboot
> otherwise you have to wait for a while for it to go bad. We assume the
> compressoin is done by a LAZY process and sin't immediate.
> I don't think its the length as once the file is corrupt I have edited the
> contents to other values and replaced it without a problem, there must be a
> trigger byte sequence or something.
> If you look at the file with the 2000 resource kit dskprobe sector editor it
> complains about the length.
> Are you using compressed folders for yourr data cos I can't get it to fail
> otherwise and that seems to be my key trigger.
> We have disabled antivirus and gone through hoops to prove the point.
> Keith
>
> "Pegasus (MVP)" wrote in message
>
> > Multi-posted - see your other posts. Please use cross-posting
> > if you wish to address several newsgroups. Multiposting wastes
> > everybody's time.
> >
> >
> > "Andy Schmidt" wrote in message
> >
> > > Hi,
> > >
> > > I have two different servers (different models and manufacturing years),
> > but
> > > both of them running Windows 2000 server with software mirrored NTFS
> > drives,
> > > which suddenly corrupt small image thumbnail files after an hour or two.
> > >
> > > No larger file sizes seem to be effected. The file content is set to all
> > > binary 0xdf.
> > >
> > > If we replace those files with valid copies, then those files will
> appear
> > to
> > > be correct for a while (probably read back from cache) but after some
> time
> > > they will "revert" back to all 0xdf.
> > >
> > > I have since been in contact with another customer who has the exact
> same
> > > problem with his Windows 2000 server also since around the past weekend.
> > In
> > > the days prior we did install recent security fixes and Microsoft
> product
> > > updates that were released in the past month.
> > >
> > > Is there anyone else out there with the same problem?
> >
> >
>
>
>
 >> Stay informed about: Since weekend update, small files up to 4096 bytes get cor.. 

PS:

>> For me, Its KB920958 <<

Does that mean you have removed this Hotfix and your problems disappeared?



"KeithMail" wrote:

> YES I have been in a losing battle with Msoft support since thursday last
> week.
>
> For me, Its KB920958 and it can be forced to happen if the data folder is
> compressed (with explorer) and trigger it to happen immediately with a
> chkdsk c: /f and a reboot
> otherwise you have to wait for a while for it to go bad. We assume the
> compressoin is done by a LAZY process and sin't immediate.
> I don't think its the length as once the file is corrupt I have edited the
> contents to other values and replaced it without a problem, there must be a
> trigger byte sequence or something.
> If you look at the file with the 2000 resource kit dskprobe sector editor it
> complains about the length.
> Are you using compressed folders for yourr data cos I can't get it to fail
> otherwise and that seems to be my key trigger.
> We have disabled antivirus and gone through hoops to prove the point.
> Keith
>
> "Pegasus (MVP)" wrote in message
>
> > Multi-posted - see your other posts. Please use cross-posting
> > if you wish to address several newsgroups. Multiposting wastes
> > everybody's time.
> >
> >
> > "Andy Schmidt" wrote in message
> >
> > > Hi,
> > >
> > > I have two different servers (different models and manufacturing years),
> > but
> > > both of them running Windows 2000 server with software mirrored NTFS
> > drives,
> > > which suddenly corrupt small image thumbnail files after an hour or two.
> > >
> > > No larger file sizes seem to be effected. The file content is set to all
> > > binary 0xdf.
> > >
> > > If we replace those files with valid copies, then those files will
> appear
> > to
> > > be correct for a while (probably read back from cache) but after some
> time
> > > they will "revert" back to all 0xdf.
> > >
> > > I have since been in contact with another customer who has the exact
> same
> > > problem with his Windows 2000 server also since around the past weekend.
> > In
> > > the days prior we did install recent security fixes and Microsoft
> product
> > > updates that were released in the past month.
> > >
> > > Is there anyone else out there with the same problem?
> >
> >
>
>
>
 >> Stay informed about: Since weekend update, small files up to 4096 bytes get cor.. 

I just removed KB920958.
Its has not been more then an hour so its too early to tell.

We are having problems with jpg files.
Small thumbnails that we create is being corrupted.

Heimir

"Andy Schmidt" wrote:

> PS:
>
> >> For me, Its KB920958 <<
>
> Does that mean you have removed this Hotfix and your problems disappeared?
>
>
>
> "KeithMail" wrote:
>
> > YES I have been in a losing battle with Msoft support since thursday last
> > week.
> >
> > For me, Its KB920958 and it can be forced to happen if the data folder is
> > compressed (with explorer) and trigger it to happen immediately with a
> > chkdsk c: /f and a reboot
> > otherwise you have to wait for a while for it to go bad. We assume the
> > compressoin is done by a LAZY process and sin't immediate.
> > I don't think its the length as once the file is corrupt I have edited the
> > contents to other values and replaced it without a problem, there must be a
> > trigger byte sequence or something.
> > If you look at the file with the 2000 resource kit dskprobe sector editor it
> > complains about the length.
> > Are you using compressed folders for yourr data cos I can't get it to fail
> > otherwise and that seems to be my key trigger.
> > We have disabled antivirus and gone through hoops to prove the point.
> > Keith
> >
> > "Pegasus (MVP)" wrote in message
> >
> > > Multi-posted - see your other posts. Please use cross-posting
> > > if you wish to address several newsgroups. Multiposting wastes
> > > everybody's time.
> > >
> > >
> > > "Andy Schmidt" wrote in message
> > >
> > > > Hi,
> > > >
> > > > I have two different servers (different models and manufacturing years),
> > > but
> > > > both of them running Windows 2000 server with software mirrored NTFS
> > > drives,
> > > > which suddenly corrupt small image thumbnail files after an hour or two.
> > > >
> > > > No larger file sizes seem to be effected. The file content is set to all
> > > > binary 0xdf.
> > > >
> > > > If we replace those files with valid copies, then those files will
> > appear
> > > to
> > > > be correct for a while (probably read back from cache) but after some
> > time
> > > > they will "revert" back to all 0xdf.
> > > >
> > > > I have since been in contact with another customer who has the exact
> > same
> > > > problem with his Windows 2000 server also since around the past weekend.
> > > In
> > > > the days prior we did install recent security fixes and Microsoft
> > product
> > > > updates that were released in the past month.
> > > >
> > > > Is there anyone else out there with the same problem?
> > >
> > >
> >
> >
> >
 >> Stay informed about: Since weekend update, small files up to 4096 bytes get cor.. 

The problem has now been seen on over 7 systems here in uk and usa, both
win2000server and Pro across differing machine manufacturers so I have
pretty well eliminated hard disk controllers, device drivers etc.
Simply put if a folder is compressed and one of these (<4096 bytes) files is
dropped into the compressed folder, then either after a period of time
(hence my question of a "lazy" compression process) or by forcing with a
chkdsk it will be corrupt immediately you reboot - this saves time waiting!

I do have mirrored disks on the 2000 server but just standard basic disks on
my 2000pros

If the Kb920958 is removed, then no amount of file placement and chkdsk will
cause the problem, all files already corrupt stay corrupt but no new damage
occurs.
If I confirm my compressed folder is good and then re add the kb920958 ,
followed by chkdsk /f etc the file corruption process occurs again.

I have checked the files with 3 hex editors (Cygnus, win2kresource kit
dskprobe and our own company proprietary viewer)
The problem as far as I can see is
KB920958
With Compressed folders
and only CERTAIN files smaller than 4096 bytes (interesting match to cluster
size perhaps?) I have dropped in text files of a k or so and they seem to be
impervious.

I have disabled all AV (was sophos), and other adaware checkers etc (that's
the beauty of being in a test lab I can pull systems apart as I see fit)

The most difficult question that our Msoft security case engineer wants
answering is what other file types are affected. Until you popped up I was
dealing with one of our own companies proprietary data storage types which
should, as far as the O/S is concerned, be just a binary file.

Once a file has gone bad then it never seems to "comes back", if I hexedit
the 0xDF file content to another hex value the bad file doesn't seem to get
made bad again (go back to 0xdf). This is why I was looking for a string of
bytes as a trigger. Still , I don't have access to Msoft O/s Code and that's
why I hoped raising a "case" with them would get it fixed.

In answer to your other post (17:16) then
At the moment, the solution for me is to
Take off the kb920958 patch
Go through storage and restore all bad files
Wait for a fix.
If the KB is necessary for you then I have not found corruption on a non
compressed folder so maybe the option would be to remove compression, then
restore the bad files
In essence if you need the 920958 then don't enable compression.

Keith


"Andy Schmidt" wrote in message

> Hi Keith,
>
> Let's please try to compare commonalities:
>
> - Yes, on both servers those folders and parent folders have the
compression
> flag on.
>
> - On both effected servers, the disks are defined as "dynamic"
> - They are software mirrored (using Windows 2000' Disk Management)
> - On both servers the files show all 0xDF characters (which shows up as
the
> German special 's', looks a little like a B or a beta character.)
> - We run NetShield 4.5 with the 5.1.00 scan engine
>
> How does that compare with your environment?
>
> Andy
> at Argos.net
>
>
> "KeithMail" wrote:
>
> > YES I have been in a losing battle with Msoft support since thursday
last
> > week.
> >
> > For me, Its KB920958 and it can be forced to happen if the data folder
is
> > compressed (with explorer) and trigger it to happen immediately with a
> > chkdsk c: /f and a reboot
> > otherwise you have to wait for a while for it to go bad. We assume the
> > compressoin is done by a LAZY process and sin't immediate.
> > I don't think its the length as once the file is corrupt I have edited
the
> > contents to other values and replaced it without a problem, there must
be a
> > trigger byte sequence or something.
> > If you look at the file with the 2000 resource kit dskprobe sector
editor it
> > complains about the length.
> > Are you using compressed folders for yourr data cos I can't get it to
fail
> > otherwise and that seems to be my key trigger.
> > We have disabled antivirus and gone through hoops to prove the point.
> > Keith
> >
> > "Pegasus (MVP)" wrote in message
> >
> > > Multi-posted - see your other posts. Please use cross-posting
> > > if you wish to address several newsgroups. Multiposting wastes
> > > everybody's time.
> > >
> > >
> > > "Andy Schmidt" wrote in
message
> > >
> > > > Hi,
> > > >
> > > > I have two different servers (different models and manufacturing
years),
> > > but
> > > > both of them running Windows 2000 server with software mirrored NTFS
> > > drives,
> > > > which suddenly corrupt small image thumbnail files after an hour or
two.
> > > >
> > > > No larger file sizes seem to be effected. The file content is set to
all
> > > > binary 0xdf.
> > > >
> > > > If we replace those files with valid copies, then those files will
> > appear
> > > to
> > > > be correct for a while (probably read back from cache) but after
some
> > time
> > > > they will "revert" back to all 0xdf.
> > > >
> > > > I have since been in contact with another customer who has the exact
> > same
> > > > problem with his Windows 2000 server also since around the past
weekend.
> > > In
> > > > the days prior we did install recent security fixes and Microsoft
> > product
> > > > updates that were released in the past month.
> > > >
> > > > Is there anyone else out there with the same problem?
> > >
> > >
> >
> >
> >
 >> Stay informed about: Since weekend update, small files up to 4096 bytes get cor.. 

Hi Keith,

okay, I will attempt to uninstall Kb920958 tonight! That's the best lead yet.

I will also test the "compression" theory as soon as one of my customers
reports another failure with one of their files.

I definitely have seen at LEAST two files that are larger than 4096.
However, both are very close to a MULTIPLE of 4096 (close to 8K in one case,
in the other case 167,564 bytes = 163K). I inspected the files. In each case
the beginning of the files are good, and ONLY the last 4000 or so bytes have
the 0xDF byte pattern.

I too created a small TXT file (just one line) and it never corrupted, while
other files around it repeatedly did.

I can say, that I have seen corruptions with the following file types:
..JPG
..GIF
..SWF

where the vast majority are small .JPG and .GIF thumbnails and so far I've
only found few files that are larger. But that may be deceiving, because you
simply may not notice the end of a larger file being corrupted, because the
it "starts" out correctly!

Best Regards,
Andy

"KeithMail" wrote:

> The problem has now been seen on over 7 systems here in uk and usa, both
> win2000server and Pro across differing machine manufacturers so I have
> pretty well eliminated hard disk controllers, device drivers etc.
> Simply put if a folder is compressed and one of these (<4096 bytes) files is
> dropped into the compressed folder, then either after a period of time
> (hence my question of a "lazy" compression process) or by forcing with a
> chkdsk it will be corrupt immediately you reboot - this saves time waiting!
>
> I do have mirrored disks on the 2000 server but just standard basic disks on
> my 2000pros
>
> If the Kb920958 is removed, then no amount of file placement and chkdsk will
> cause the problem, all files already corrupt stay corrupt but no new damage
> occurs.
> If I confirm my compressed folder is good and then re add the kb920958 ,
> followed by chkdsk /f etc the file corruption process occurs again.
>
> I have checked the files with 3 hex editors (Cygnus, win2kresource kit
> dskprobe and our own company proprietary viewer)
> The problem as far as I can see is
> KB920958
> With Compressed folders
> and only CERTAIN files smaller than 4096 bytes (interesting match to cluster
> size perhaps?) I have dropped in text files of a k or so and they seem to be
> impervious.
>
> I have disabled all AV (was sophos), and other adaware checkers etc (that's
> the beauty of being in a test lab I can pull systems apart as I see fit)
>
> The most difficult question that our Msoft security case engineer wants
> answering is what other file types are affected. Until you popped up I was
> dealing with one of our own companies proprietary data storage types which
> should, as far as the O/S is concerned, be just a binary file.
>
> Once a file has gone bad then it never seems to "comes back", if I hexedit
> the 0xDF file content to another hex value the bad file doesn't seem to get
> made bad again (go back to 0xdf). This is why I was looking for a string of
> bytes as a trigger. Still , I don't have access to Msoft O/s Code and that's
> why I hoped raising a "case" with them would get it fixed.
>
> In answer to your other post (17:16) then
> At the moment, the solution for me is to
> Take off the kb920958 patch
> Go through storage and restore all bad files
> Wait for a fix.
> If the KB is necessary for you then I have not found corruption on a non
> compressed folder so maybe the option would be to remove compression, then
> restore the bad files
> In essence if you need the 920958 then don't enable compression.
>
> Keith
>
>
> "Andy Schmidt" wrote in message
>
> > Hi Keith,
> >
> > Let's please try to compare commonalities:
> >
> > - Yes, on both servers those folders and parent folders have the
> compression
> > flag on.
> >
> > - On both effected servers, the disks are defined as "dynamic"
> > - They are software mirrored (using Windows 2000' Disk Management)
> > - On both servers the files show all 0xDF characters (which shows up as
> the
> > German special 's', looks a little like a B or a beta character.)
> > - We run NetShield 4.5 with the 5.1.00 scan engine
> >
> > How does that compare with your environment?
> >
> > Andy
> > at Argos.net
> >
> >
> > "KeithMail" wrote:
> >
> > > YES I have been in a losing battle with Msoft support since thursday
> last
> > > week.
> > >
> > > For me, Its KB920958 and it can be forced to happen if the data folder
> is
> > > compressed (with explorer) and trigger it to happen immediately with a
> > > chkdsk c: /f and a reboot
> > > otherwise you have to wait for a while for it to go bad. We assume the
> > > compressoin is done by a LAZY process and sin't immediate.
> > > I don't think its the length as once the file is corrupt I have edited
> the
> > > contents to other values and replaced it without a problem, there must
> be a
> > > trigger byte sequence or something.
> > > If you look at the file with the 2000 resource kit dskprobe sector
> editor it
> > > complains about the length.
> > > Are you using compressed folders for yourr data cos I can't get it to
> fail
> > > otherwise and that seems to be my key trigger.
> > > We have disabled antivirus and gone through hoops to prove the point.
> > > Keith
> > >
> > > "Pegasus (MVP)" wrote in message
> > >
> > > > Multi-posted - see your other posts. Please use cross-posting
> > > > if you wish to address several newsgroups. Multiposting wastes
> > > > everybody's time.
> > > >
> > > >
> > > > "Andy Schmidt" wrote in
> message
> > > >
> > > > > Hi,
> > > > >
> > > > > I have two different servers (different models and manufacturing
> years),
> > > > but
> > > > > both of them running Windows 2000 server with software mirrored NTFS
> > > > drives,
> > > > > which suddenly corrupt small image thumbnail files after an hour or
> two.
> > > > >
> > > > > No larger file sizes seem to be effected. The file content is set to
> all
> > > > > binary 0xdf.
> > > > >
> > > > > If we replace those files with valid copies, then those files will
> > > appear
> > > > to
> > > > > be correct for a while (probably read back from cache) but after
> some
> > > time
> > > > > they will "revert" back to all 0xdf.
> > > > >
> > > > > I have since been in contact with another customer who has the exact
> > > same
> > > > > problem with his Windows 2000 server also since around the past
> weekend.
> > > > In
> > > > > the days prior we did install recent security fixes and Microsoft
> > > product
> > > > > updates that were released in the past month.
> > > > >
> > > > > Is there anyone else out there with the same problem?
> > > >
> > > >
> > >
> > >
> > >
>
>
>
 >> Stay informed about: Since weekend update, small files up to 4096 bytes get cor.. 

Hi Keith,

you were "right on". Disabling compression on certain folders seem to fix
it temporarily - and after uninstalling the hotfix last night on all servers
with compressed disks I have had no more complaints thus far.

Thank you for sharing your insight and for researching this so thoroughly.

Let's see how long it takes Microsoft to take your bug report and
proactively warn its customers that their hotfix can cause loss of data!

Best Regards,
Andy

"KeithMail" wrote:

> The problem has now been seen on over 7 systems here in uk and usa, both
> win2000server and Pro across differing machine manufacturers so I have
> pretty well eliminated hard disk controllers, device drivers etc.
> Simply put if a folder is compressed and one of these (<4096 bytes) files is
> dropped into the compressed folder, then either after a period of time
> (hence my question of a "lazy" compression process) or by forcing with a
> chkdsk it will be corrupt immediately you reboot - this saves time waiting!
>
> I do have mirrored disks on the 2000 server but just standard basic disks on
> my 2000pros
>
> If the Kb920958 is removed, then no amount of file placement and chkdsk will
> cause the problem, all files already corrupt stay corrupt but no new damage
> occurs.
> If I confirm my compressed folder is good and then re add the kb920958 ,
> followed by chkdsk /f etc the file corruption process occurs again.
>
> I have checked the files with 3 hex editors (Cygnus, win2kresource kit
> dskprobe and our own company proprietary viewer)
> The problem as far as I can see is
> KB920958
> With Compressed folders
> and only CERTAIN files smaller than 4096 bytes (interesting match to cluster
> size perhaps?) I have dropped in text files of a k or so and they seem to be
> impervious.
>
> I have disabled all AV (was sophos), and other adaware checkers etc (that's
> the beauty of being in a test lab I can pull systems apart as I see fit)
>
> The most difficult question that our Msoft security case engineer wants
> answering is what other file types are affected. Until you popped up I was
> dealing with one of our own companies proprietary data storage types which
> should, as far as the O/S is concerned, be just a binary file.
>
> Once a file has gone bad then it never seems to "comes back", if I hexedit
> the 0xDF file content to another hex value the bad file doesn't seem to get
> made bad again (go back to 0xdf). This is why I was looking for a string of
> bytes as a trigger. Still , I don't have access to Msoft O/s Code and that's
> why I hoped raising a "case" with them would get it fixed.
>
> In answer to your other post (17:16) then
> At the moment, the solution for me is to
> Take off the kb920958 patch
> Go through storage and restore all bad files
> Wait for a fix.
> If the KB is necessary for you then I have not found corruption on a non
> compressed folder so maybe the option would be to remove compression, then
> restore the bad files
> In essence if you need the 920958 then don't enable compression.
>
> Keith
>
>
> "Andy Schmidt" wrote in message
>
> > Hi Keith,
> >
> > Let's please try to compare commonalities:
> >
> > - Yes, on both servers those folders and parent folders have the
> compression
> > flag on.
> >
> > - On both effected servers, the disks are defined as "dynamic"
> > - They are software mirrored (using Windows 2000' Disk Management)
> > - On both servers the files show all 0xDF characters (which shows up as
> the
> > German special 's', looks a little like a B or a beta character.)
> > - We run NetShield 4.5 with the 5.1.00 scan engine
> >
> > How does that compare with your environment?
> >
> > Andy
> > at Argos.net
> >
> >
> > "KeithMail" wrote:
> >
> > > YES I have been in a losing battle with Msoft support since thursday
> last
> > > week.
> > >
> > > For me, Its KB920958 and it can be forced to happen if the data folder
> is
> > > compressed (with explorer) and trigger it to happen immediately with a
> > > chkdsk c: /f and a reboot
> > > otherwise you have to wait for a while for it to go bad. We assume the
> > > compressoin is done by a LAZY process and sin't immediate.
> > > I don't think its the length as once the file is corrupt I have edited
> the
> > > contents to other values and replaced it without a problem, there must
> be a
> > > trigger byte sequence or something.
> > > If you look at the file with the 2000 resource kit dskprobe sector
> editor it
> > > complains about the length.
> > > Are you using compressed folders for yourr data cos I can't get it to
> fail
> > > otherwise and that seems to be my key trigger.
> > > We have disabled antivirus and gone through hoops to prove the point.
> > > Keith
> > >
> > > "Pegasus (MVP)" wrote in message
> > >
> > > > Multi-posted - see your other posts. Please use cross-posting
> > > > if you wish to address several newsgroups. Multiposting wastes
> > > > everybody's time.
> > > >
> > > >
> > > > "Andy Schmidt" wrote in
> message
> > > >
> > > > > Hi,
> > > > >
> > > > > I have two different servers (different models and manufacturing
> years),
> > > > but
> > > > > both of them running Windows 2000 server with software mirrored NTFS
> > > > drives,
> > > > > which suddenly corrupt small image thumbnail files after an hour or
> two.
> > > > >
> > > > > No larger file sizes seem to be effected. The file content is set to
> all
> > > > > binary 0xdf.
> > > > >
> > > > > If we replace those files with valid copies, then those files will
> > > appear
> > > > to
> > > > > be correct for a while (probably read back from cache) but after
> some
> > > time
> > > > > they will "revert" back to all 0xdf.
> > > > >
> > > > > I have since been in contact with another customer who has the exact
> > > same
> > > > > problem with his Windows 2000 server also since around the past
> weekend.
> > > > In
> > > > > the days prior we did install recent security fixes and Microsoft
> > > product
> > > > > updates that were released in the past month.
> > > > >
> > > > > Is there anyone else out there with the same problem?
> > > >
> > > >
> > >
> > >
> > >
>
>
>
 >> Stay informed about: Since weekend update, small files up to 4096 bytes get cor.. 

27 hours since I removed the update and we have not have any problems since.

Heimir



"Heimir" wrote:

> I just removed KB920958.
> Its has not been more then an hour so its too early to tell.
>
> We are having problems with jpg files.
> Small thumbnails that we create is being corrupted.
>
> Heimir
>
 >> Stay informed about: Since weekend update, small files up to 4096 bytes get cor.. 

Out of curiosity, does Automatic Updates try to re-apply the patch? Did you
have to turn that off?

-jl

"Heimir" wrote:

> 27 hours since I removed the update and we have not have any problems since.
>
> Heimir
>
>
>
> "Heimir" wrote:
>
> > I just removed KB920958.
> > Its has not been more then an hour so its too early to tell.
> >
> > We are having problems with jpg files.
> > Small thumbnails that we create is being corrupted.
> >
> > Heimir
> >
>
 >> Stay informed about: Since weekend update, small files up to 4096 bytes get cor.. 

I have auto update disabled as I need control of my environment but after I
removed the patch it re downloaded it and notified me that it was there and
waiting to be applied so I assume the answer is yes to your question.
It is always a difficult compromise in an IT environment, do you want
platform stability or up to date security, its a pity this has shown you
can't always have both.
As of this date I have still NO confirmation from the patch authors to
acknowledge this as happening.
So, either we are imagining this problem or this has bigger repercussions
than we have discovered ourselves?
"John Linn" wrote in message

> Out of curiosity, does Automatic Updates try to re-apply the patch? Did
you
> have to turn that off?
>
> -jl
>
> "Heimir" wrote:
>
> > 27 hours since I removed the update and we have not have any problems
since.
> >
> > Heimir
> >
> >
> >
> > "Heimir" wrote:
> >
> > > I just removed KB920958.
> > > Its has not been more then an hour so its too early to tell.
> > >
> > > We are having problems with jpg files.
> > > Small thumbnails that we create is being corrupted.
> > >
> > > Heimir
> > >
> >
 >> Stay informed about: Since weekend update, small files up to 4096 bytes get cor.. 

Hey Keith, thanks for the reply, I actually discovered this answer myself. I
have 2 production environment that house most of my clients' files and to
test I uncompressed one, and I uninstalled the patch from the other (which
subsequently auto applied the patch again, hehe). It is a shame that I must
choose between manual patching my application, and therefore violating my own
security policy, or to uncompress many gigs worth of data, costing me 20-30%
additional space now.

I have to believe the lack of acknowledgement is out of embarassment or fear
of the bug's effects. I have over 300 clients who upload images all the time
and I've personally counted around 800 images (especially thumbnails) that
kept getting corrupt during that week from Hell. Luckily, my business isn't
file storage or graphic files. But if it was, this bug could of been
catastrophic. And that's just a with a small business...

If this isn't a Sev 1 bug within MS's system, I would be completedly
shocked. My guess is the next round of patches will fix it and it will be
done very quietly.

-jl

"KeithMail" wrote:

> I have auto update disabled as I need control of my environment but after I
> removed the patch it re downloaded it and notified me that it was there and
> waiting to be applied so I assume the answer is yes to your question.
> It is always a difficult compromise in an IT environment, do you want
> platform stability or up to date security, its a pity this has shown you
> can't always have both.
> As of this date I have still NO confirmation from the patch authors to
> acknowledge this as happening.
> So, either we are imagining this problem or this has bigger repercussions
> than we have discovered ourselves?
> "John Linn" wrote in message
>
> > Out of curiosity, does Automatic Updates try to re-apply the patch? Did
> you
> > have to turn that off?
> >
> > -jl
> >
> > "Heimir" wrote:
> >
> > > 27 hours since I removed the update and we have not have any problems
> since.
> > >
> > > Heimir
> > >
> > >
> > >
> > > "Heimir" wrote:
> > >
> > > > I just removed KB920958.
> > > > Its has not been more then an hour so its too early to tell.
> > > >
> > > > We are having problems with jpg files.
> > > > Small thumbnails that we create is being corrupted.
> > > >
> > > > Heimir
> > > >
> > >
>
>
>
 >> Stay informed about: Since weekend update, small files up to 4096 bytes get cor.. 

Hi Keith.

I'm posting over here as you requested. Right now I'm generating a list
of all the files which get altered through the copy operation (I
understand it can happen whenever *any* small file gets written or
altered?). I'll be able to give you a list of filetypes and filesize
limits as well. After that, I'll be trying to roll back the KB 920958
and see if that fixes my problem.

Thanks!

Frank


KeithMail wrote:
> I have auto update disabled as I need control of my environment but after I
> removed the patch it re downloaded it and notified me that it was there and
> waiting to be applied so I assume the answer is yes to your question.
> It is always a difficult compromise in an IT environment, do you want
> platform stability or up to date security, its a pity this has shown you
> can't always have both.
> As of this date I have still NO confirmation from the patch authors to
> acknowledge this as happening.
> So, either we are imagining this problem or this has bigger repercussions
> than we have discovered ourselves?
> "John Linn" wrote in message
>
> > Out of curiosity, does Automatic Updates try to re-apply the patch? Did
> you
> > have to turn that off?
> >
> > -jl
> >
> > "Heimir" wrote:
> >
> > > 27 hours since I removed the update and we have not have any problems
> since.
> > >
> > > Heimir
> > >
> > >
> > >
> > > "Heimir" wrote:
> > >
> > > > I just removed KB920958.
> > > > Its has not been more then an hour so its too early to tell.
> > > >
> > > > We are having problems with jpg files.
> > > > Small thumbnails that we create is being corrupted.
> > > >
> > > > Heimir
> > > >
> > >
 >> Stay informed about: Since weekend update, small files up to 4096 bytes get cor.. 

We have seen this on a fairly significant scale and it seems, as you have stated, to be only on machines with that patch, in compressed folders, and happening to binary files (.gif, .jpg, .swf for us).

I am working on a solution to decompress folders, but that is an uphill battle from a space standpoint.

I am hoping that MS will own up and release a fix for this issue, detailing the problem, as I can not believe it is just the handfull of us having this issue. I was tearing my hair out looking for a cause till I found you guys excellent work on narrowing it down.
 >> Stay informed about: Since weekend update, small files up to 4096 bytes get cor..