I don't remember the three modes but memory does not necessarily serve
me well. Perhaps it came much later than DOS 3.2 which was the last
time I had anything to do with DOS at a programmer's level.
And I wasn't aware that I had "assumed an allocation strategy"; at least
in any sense that I could make meaningful decisions about it.
Chuck Norcutt
Manuel Viet wrote:
> Le mardi 19 Décembre 2006 04:04, Chuck Norcutt a écrit :
>
>
>>Anyhow, that's my hypothesis and it seems to explain what happened. But
>>its surprising if true since one of the major changes in the DOS file
>>system going all the way back to IBM PC DOS 2.0 (or maybe 2.1) was to
>>avoid reusing old, "empty" space if you didn't have to. This was
>>specifically to avoid the problem just described and make it easier to
>>recover accidentally deleted files. It tried to keep everything
>>contiguous if it could allocate enough contiguos space to do so and also
>>tried to use previously unallocated space if it could.
>
>
> Errr... even with good ol' DOS, that is a terribly dangerous assumption to
> make ; if memory serves well, the write DOS call had 3 modes to choose from,
> and only one of them was "best fit", that is, find the smallest contiguous
> area to write into. This happened to be the default, and generally put the
> new file at the end of the volume before fragmenting. But you (programmer)
> might as well choose "first fit", that is, fill any block you may encounter
> until the file is written in the gaps of the disk. Or "last fit", to
> voluntarily put the new file in a single block at the end of the volume.
>
> In a word, never, ever, assume an allocation strategy. Check first.
>
==============================================
List usage info: http://www.zuikoholic.com
List nannies: olympusadmin@xxxxxxxxxx
==============================================
|