of opening the file, to avoid needing to claim SFTs in later changes.
Clarify and implement parts of the correct SHARE behaviour.
git-svn-id: https://svn.code.sf.net/p/freedos/svn/kernel/trunk@1393 6ac86273-5f31-0410-b378-82cca8765d1b
you reboot while files are open... Reported by Hardi Stengelin :-).
Always test *link_fat* result. New function is_free_cluster. Extra
checks in *link_fat* (bad r/w offset, i/o, write) and *next_cluster*
(dangling chain: bad value in chain) with short messages (no msg for
bad chain start). Shorter "Bad DPB" (FAT size) msg. More comments!
Update FS INFO on disk only when needed. Check if chain EOF was at
expected place when extending. Call *link_fat* before! *setdstart*
when a FAT chain grows. [Q: Does 0 byte write always trunc? Why?]
git-svn-id: https://svn.code.sf.net/p/freedos/svn/kernel/trunk@1358 6ac86273-5f31-0410-b378-82cca8765d1b
field, simplifies remove_lfn_entries(), and avoids a bug if you delete
the first entry in the root directory on FAT32.
git-svn-id: https://svn.code.sf.net/p/freedos/svn/kernel/trunk@911 6ac86273-5f31-0410-b378-82cca8765d1b
Internally the kernel uses two near fnodes though, to save on codesize
and fmemcpy's if necessary. Having memory management on two fnodes is
a little silly but I just want to make sure with the panic message
that we never accidentally try to use three near fnodes at the same time.
(two are used at the same time by rename, commit, and merge_file_changes).
This can be cleaned up later.
Anyway. 644736 bytes free conv memory isn't bad.
git-svn-id: https://svn.code.sf.net/p/freedos/svn/kernel/trunk@821 6ac86273-5f31-0410-b378-82cca8765d1b
Have a simplified clause for f_cluster == FREE.
Set f_cluster = FREE in shrink_file if the file is set to 0 bytes; in
that case we should set the current cluster to FREE even if it is
currently a LONG_LAST_CLUSTER.
git-svn-id: https://svn.code.sf.net/p/freedos/svn/kernel/trunk@818 6ac86273-5f31-0410-b378-82cca8765d1b
extend() now uses f_cluster instead of f_back, while map_cluster makes
sure it's not set to LONG_LAST_CLUSTER (but to the cluster before it)
when calling extend().
extend() and first_fat() now return the new cluster number or
LONG_LAST_CLUSTER, just like find_fat_free()
Hopefully I didn't break anything... Initial testing was successful.
git-svn-id: https://svn.code.sf.net/p/freedos/svn/kernel/trunk@816 6ac86273-5f31-0410-b378-82cca8765d1b
save a few bytes too. Also changed the FcbParseFname return value:
returns offset portion of pointer (SI) instead of the number of bytes to
be added to SI.
git-svn-id: https://svn.code.sf.net/p/freedos/svn/kernel/trunk@775 6ac86273-5f31-0410-b378-82cca8765d1b
and find_fat_free). This completely messed up rwblock. Removed these calls
(for directories they are already covered at a higher level) and added
a few sanity checks to dir_close and dir_write.
git-svn-id: https://svn.code.sf.net/p/freedos/svn/kernel/trunk@761 6ac86273-5f31-0410-b378-82cca8765d1b
FAT16 partitions (just like FAT16 kernels do)
* added extra checks to make sure that invalid FAT entries are never
followed
* made put_console() public to be able to print a message in case of
FAT corruption
* some small optimizations and header cleanups (some suggested by Arkady)
git-svn-id: https://svn.code.sf.net/p/freedos/svn/kernel/trunk@753 6ac86273-5f31-0410-b378-82cca8765d1b
This solves problems with int24 handlers that call int21/ah=59.
Let truename and blockrw return with an error if there is a critical error.
Don't overwrite the critical error # with the DOS error #.
git-svn-id: https://svn.code.sf.net/p/freedos/svn/kernel/trunk@709 6ac86273-5f31-0410-b378-82cca8765d1b
Make sure the number of FAT sectors is actually enough to hold that
many clusters. Otherwise back the number of clusters down (LG & AB)
git-svn-id: https://svn.code.sf.net/p/freedos/svn/kernel/trunk@655 6ac86273-5f31-0410-b378-82cca8765d1b
