> -----Original Message-----
> From: Bob Archer [mailto:Bob.Archer_at_amsi.com]
> Sent: vrijdag 5 februari 2010 21:15
> To: James Mansion; Bert Huijben
> Cc: Erik Funkenbusch; users_at_subversion.apache.org
> Subject: RE: Action needed to get critical SVN related fix in Windows 7
SP1
>
> > Bert Huijben wrote:
> > >
> > > Hi,
> > >
> > >
> > >
> > > Theoretically we could work around this by deleting the file in your
> > > working copy... and then write the new data. But this has one
> > > essential problem: What if for whatever reason the delete occured
> > > but the write didn't? (Or when it stops half way). Now we write a
> > > temporary file and then move it in place. This file move operation
> > > either succeeds, or it fails (leaving both files). In both cases we
> > > don't lose data, while in the delete then write case we would.
> > >
> > Isn't there transactional update support in NTFS now? Disclaimer: I
> > haven't tried it.
> >
>
> Yes.
>
> http://msdn.microsoft.com/en-us/magazine/cc163388.aspx
The transactional apis use the same low level interface that generate this
failure in the first place and would most likely be much slower if we would
have to initiate a transaction for every file move. (The technical details
are in the forum post... But you have to familiarize with oplocks on MSDN to
see where it impacts).
The new working copy storage we work on for 1.7 will use less file
operations than 1.6 and earlier versions, so this should relieve some if not
most of the pain if the issue is not fixed by then... But I really hope it
is fixed much earlier.
Via a different channel I heard that the same or a similar issue is/was
triggered by some virusscanners.
http://www.pcpro.co.uk/news/security/353734/windows-7-chkdsk-bug-linked-to-a
ntivirus-software
Bert
>
> BOb
Received on 2010-02-05 23:43:25 CET