How does 9x/NT do it (I mean 95, 98, NT, 2k, XP, ...)?
are they only deleting the folder's header? so files are still there
because it really seems to be faster under graphical OS

I think they just modify DIRTREE & FATs marking sectors as 'free'. That's why there're so many utilities for files recovery.

Yes, this is what i meant. it should be in the kernel becuz it is an addition to the deletion system. But if we will had recycle bin, maybe we could remove it from there....

Updated fat32.inc set_FAT/get_FAT and disk cache rewritten

Removedir almost 3 times faster on fat32 and almost 2 times faster on fat16.
Also disk cache works better

New subfunction and more error codes

function 58 / subfunction 15 = get_disk_info

get_disk_info return current hd cluster info thru dirnamez field
dword [dirnamez+0] = cluster size in bytes
dword [dirnamez+4] = total clusters
dword [dirnamez+8] = free clusters

disk_size = cluster_size * total_clusters
free_size = cluster_size * free_clusters

New error codes for function 58
; eax = 8 : disk full
; eax = 9 : fat table corrupted
; eax = 10 : access denied

Hi, ATV!

If you still don't know what to do next, I'd be much appreciate if you'll implement BETTER WAY of partitions handling. What I mean is to delete partition selection function and make 58th and others to get partition number from path, e.g. /hd/1/ is 1st partition (c:), /hd/3/ is 3rd (e:) etc. Hope you like this idea.

wow, nice code, really!
Will this code released with MenuetOS 0.78 pre 4 +?
I really hope so!

greets, ...

Instead of partition number it would be better to use the partition name
so you have the same location for a file even if you move your hard disk to another computer.
The partition name can be found in the boot sector, and also in the root directory (optional).

But this means Menuet users will need to name all the partitions, otherwise they'll be unable to work with some of them w/o names... and, numbering is just as alpha names (e.g. in Windows) but more convinient - AA:\ in Windows, /hd/27/ in Menuet

Updated fat32.inc don't allow overwrite directory with file

Is remove whole directory structure too dangerous? Should i remove it?

Note: Original read_file was return end_of_file with code 5 (now 6) and not_found with code 6 (now 5) they are fixend now, but tinypad don't like it.

And yes i have think about big changes to handle different partitions. LBA read uses "number" like it is hd_base. Problem is that there is hd_base AND hd_partition, but there is only one level for numbers /hd/"number"/path/file. Maybe counting all hd's and partitions to go "1"... or something like it. That need identify if hd exist at startup.

So if all partitions are /hd/1/ then what for /1/ is? We could make it /hd/... I think that /1/ means something, isn't it?

/1/ is needed, but currently not used (exception, LBA read use it as hd_base = pri.master - sec.slave). Maybe array to keep fat_type and all partition info for each partition. After that "numbers" can handle one physical hd set via setup. When setting hd_base collect all partition info into array (fat_type / cluster info / ...). Then expand path can set right partition depending on "number", just copy partition info. Big problem is all applications that uses /hd/1/ and your program is in /hd/2/ they can't find data/external files. Maybe new number "0" or "." to use last used partition "/hd/0/" or "/hd/./". New problem what if another program uses different partition between calls?

I don't know what is best solution, i have only 2 months experience of Menuet. I have not found any future guidelines how Menuet should handle hd_base/partitions.

Important: Append directory bug fix

There was bug (converting cluster -> sector) when existing directory need new cluster. It has been there since my very first fat32.inc. It can happend when directory has 254 files in 4k cluster size (510 files in 8k) and new file/dir is created.

Bug can overwrite data.
Run Scandisk to see if your disk is ok

I hope that didn't cause any troubles. I have too bad memory, maybe i have to reserve room in old people's home.

You warned us that these are only test versions so you don't have to feel sorry. I also hope that everyone's HDDs are ok, but I namely didn't use your project until I would find it ripe. Another fact is that I have an NTFS so...
But I'll fix myself an old computer some day and stuff it with some HDD and video so it could only be used for MenuetOS - then any crash can be delt with ease. I'd have to consult my father to let me drag some scrap material home from the work

Oh sh*t! It corrupted a lot of files on my disk

ATV, you should e-mail your stuff directly to Mike Hibbett because he don't read forums last month.

Important: New bug fix, again

Ivan, i am very sorry about disk corrupt.

About new bug, there was bug when delete file, it was deleted like directory. Is removedir allowed and is it directory tested wrong way, i can't believe my eyes.

Bug can corrupt FAT table with clearing extra clusters.
Run Scandisk to see if your disk is ok

Is there anybody reading/testing fat32.inc/fs.inc to find errors? This feels little too big job for me.

I have used DOS over 10 years and i have not realize that volume label can have same 8+3 name as file or directory, that bug is also fixed. Should there be subfunction for Menuet to get/set volume label or is it applications job?

I'll test it this afternoon and post here when i find bugs



i would say subfunction: this code is gonna be used more than once i gues

hmm reading files was ok but when i tried to save i got hd time out
I'll check later today with the original kernel (it's the first time i use this hd in menuetos...)

I had to reboot so wasnt able to see if making dirs etc is ok..

edit:
same prob with the original kernel..

what could be going wrong?
i'm using meneutos 078 pre 3 and an old western digital caviar hd of 324 MB

i can read from it but not write to it

another edit:
menuetos did write a svreen.raw to my hd but it was corrupted: this is what chkdisk says:
\screen.RAW holds an invalid shortcut.
The size of \screen.RAW is invalid.
There are problems with the filesystem.

Tested it today, had to do some backups, and everything went well.
Excellent in fact MAKDIR did everything it should have and more.
RENAME & DISKINFO worked as expected also.

I did notice that you could not set the hd params in kernel.asm/; device addresses
without then resetting them using the settings program (don't need it anyway)

I even deleted the dir "C:\Documents and Settings\Administrator.REACTOS"
without any ill effects

Good Job