Fix for mistargetted write with a file size > 2G when a background scatter...
Fix for mistargetted write with a file size > 2G when a background scatter list straddles a fragment When large transfers are being buffered to be written in the background they are attached to the Fcb without considering how the underlying disc fragments are lined up. When the background process grabs a handful of buffers to build into a scatter list to pass to the low level DiscOp it picks the head of the list and goes forward (SkipWriteBehind) to the fragment end and back (BackwardSkipWriteBehind). However, BackwardsSkipWriteBehind uses DefFileFrag which substitutes a default offset of 0, and the signed compare resulted in this being left as the believed start of fragment. In turn, far too many buffers got associated with the fragment, and written to the wrong place on the disc. In general this doesn't occur, but if the group of buffers happens to straddle a fragment, and that group of buffers is > 2G, the signed compare would trip up. As fsbash uses the same random number seed this conspired that testing the same drive twice (with and without background transfers enabled) would appear to pass the integrity check step. A new harddisc was used to show this up. FileCore80.s: Recoded the compare to be in sectors, so 4G files aren't top bit set, but shared files not at the fragment start still are. Docs/AdfsBuffers: Added some notes before I forget what I just wrote meant. Version 3.58. Tagged as 'FileCore-3_58'
Showing with 64 additions and 93 deletions