Index
> MenuetOS > Directory routines for function 58Goto page 1, 2, 3, 4 Next |
| Author |
|
|
daneel 18 Oct 2004, 17:14
Very good job! MOS need more FS support
 |
|||
18 Oct 2004, 17:14 |
|
|
ATV 20 Oct 2004, 08:14
Updated fat32.inc/fs.inc support for long filename delete over sector limit
What about file read/write/seek, byte/sector level? Byte level need more code into kernel, but it's easy to use in applications. Sector level is easy to add into kernel, but need more application code. Last edited by ATV on 08 Nov 2004, 08:17; edited 2 times in total |
|||
|
20 Oct 2004, 08:14 |
|
|
drh3xx 20 Oct 2004, 09:33
I'd opt for byte level access. Sure it's more code in the kernel but the whole point of an OS is to make coding an app easyier.
Bearing in mind we can now delete LFN's how hard will it be to add support for them when creating/loading/updating a file/directory? I have some trouble with my FAT32 access and I think LFN's might be the problem. Keep up the good work ATV |
|||
|
20 Oct 2004, 09:33 |
|
|
ATV 23 Oct 2004, 07:30
drh3xx, are you going over 9 directory deep because fs.inc currently can handle path with deepnes of 8+1?
Code: Just change fs.inc (line 143-): mov ecx,127 cld rep stosb mov ecx,9 with: mov ecx,41*12+12 cld rep stosb mov ecx,41 About direct byte read/write using func 58 and whole path/fat travel per byte makes it so slow that nobody want use it. So i need more future guidelines for MeOS because that need somekind file handle table inside kernel (hd_base / partition / dir_entry_pos / current_filepos / user_prog_id / ...) and maybe sector buffer for each handle. Is there reserved mode numbers under func 58? Do i have free hands to do almost anything? |
|||
|
23 Oct 2004, 07:30 |
|
|
bloglite 23 Oct 2004, 10:34
I don't speak for everyone but the idea here is to create functional code and the optimization of that code.
By all means fix what needs fixing. Comment your code well so others know what you did, There is plenty to be done. (a new to-do list may be in order.) What eventually shows in the "official release" is what we have to start with in each "evolution". Being able to easily modify or make your own version of this OS is IMHO the best part. Lots of talented people and as evidenced in these forums some quick learners are on board. It just gets better and better. Encourage others too! G'day, Mark |
|||
|
23 Oct 2004, 10:34 |
|
|
drh3xx 23 Oct 2004, 12:17
No ATV only using Root->Directory->File setup so that's not the problem.
It works for some directories (without LFN) but not others (also not LFN) it's really odd. I wondered if it might be to do with LFNs because if I create a dir with 8 char name it seems to work but if I rename a LFN directory to 8 chars then sometimes it does and sometimes it doesn't. Do M$ cut corners in this situation which results in this odd behavior? |
|||
|
23 Oct 2004, 12:17 |
|
|
Octavio 23 Oct 2004, 13:06
ATV wrote: Updated fat32.inc/fs.inc support for long filename delete over sector limit In the file 'filelib.asm' part of jpegview source, there is a routine for reading files at the byte level. Also it would be useful that menuetos returns the correct value for directory size , the size of directories depends on the number of clusters, in the fat entry the directory size is always 0 and this is the value returned by menuetos,at least it was some months ago. |
|||
|
23 Oct 2004, 13:06 |
|
|
ATV 30 Oct 2004, 07:05
Updated fat32.inc
Now file_read return also dirsize in bytes Tip for testing: [partition_count] can be returned after set_FAT32_variables call Note: in russian kernel.asm need to remove Mario79 added part2_ld/fat32part routine in sys_setup and replace it with single line: Code: mov [fat32part],ebx I have written partition travel / fat16 / make directory / remove file/directory and now return of directory size. What's next, any ideas? Last edited by ATV on 08 Nov 2004, 08:18; edited 1 time in total |
|||
|
30 Oct 2004, 07:05 |
|
|
Mario79 30 Oct 2004, 13:20
You such clever, think up to itself the purpose! Four months I understood the code of the driver Fat32 and wrote Fat16 (2 months for a kernel 076, and then 2 months altered for a kernel 077). But you have appeared and has told - " As ridiculously your code reminds to me - BASIC ". I need only to have a drink of alcohol and will be hung up on a good cord. You have taken away for me sense of life...
Best regards! |
|||
|
30 Oct 2004, 13:20 |
|
|
Octavio 30 Oct 2004, 15:13
ATV, it seems that your code is not using the disk cache.
|
|||
|
30 Oct 2004, 15:13 |
|
|
ATV 04 Nov 2004, 08:22
Mario79, I don't know what to say. Coding should be fun and interesting and there is always something to learn.
Octavio, Every read is done thru hd_read and it uses disk cache. Write is different, after write/delete will be forced to write it to disk. That prevent disk corrupt if user turn off computer. There is "cache_max equ 1000" at start of fat32.inc that's maximum sector count for cache (1000*512=512000 bytes) maybe you are over that. Maybe find_empty_read_slot need some work too. Do anybody know why there is limited use of cache "mov ecx,cache_max-15" and "cmp [fat_search_start],cache_max-10"? Or is it bug? What about dos like FindFirst/FindNext for MeOS? Function number? Data structure? |
|||
|
04 Nov 2004, 08:22 |
|
|
Octavio 04 Nov 2004, 17:47
ATV wrote: That prevent disk corrupt if user turn off computer. There is "cache_max equ 1000" at start of fat32.inc that's maximum sector count for cache (1000*512=512000 bytes) maybe you are over that. Maybe find_empty_read_slot need some work too.What about dos like FindFirst/FindNext for MeOS? Function number? Data structure? preventing disk corrupt is a bit more complex than this,and is not a cache problem. but caching write operations will increase performance. menuetos uses fixed data structures because is simpler than dinamic memory allocation, but in other OS the cache uses all free memory on the system. find_empty_read_slot needs very little work if the correct algoritm is used like a fifo ramdom list ,also for disk operations it would be better to read/write at least 4kb at a time and use this size also for the cache. about findfirst/findnext ,on my os i can select files by number (position on the dir struct). also it would be interesting to implement a 'move' like in dos,that just copy the directory entry of the file but not the file itself,is faster than copy-delete. |
|||
|
04 Nov 2004, 17:47 |
|
|
Madis731 04 Nov 2004, 19:07
Well, I would be more concerned about bugs, than that of disk write failures. This is up to user and user should NOT be mad, when he/she doesn't turn off computer as supposed to or takes a HDD out while running or haven't got UPS or whatever.
PR rates are much higher when users won't be furious about disk write failures, because OS didn't do it right 
Another view to look from: we went assembly with this project. Prabability theory says that there is much less chance that HDD won't be able to finish writing on time or sth... and if I recall right, HDD parking won't happen before cache is empty and the HDD has some conductors(is this the word in English? the one that holds energy but prevents it from flowing through) that have enough juice to park head from anywhere on the disk. |
|||
|
04 Nov 2004, 19:07 |
|
|
ATV 08 Nov 2004, 08:20
Support for rename/move file or directory (only for hd)
Code: fileinfo: ; fileinfo for function 58 .mode dd 5 ; 2=delete, 4=makedir, 5=rename .start_block dd 0x0 ; block to read .blocks dd 0x0 ; num of blocks .address dd 0x20000 ; return data pointer .workarea dd 0x10000 ; work area for os dirnamez: times 256 db 0 ; 2 successive asciiz names - Makedir can only make one directory at time - Delete can only remove empty directory - Rename can only rename/move file/dir inside current hd - Rename dirnamez field need 2 successive asciiz name (full source and full destination) ex. "/HD/1/MEOSTEST/TEST.TXT",0,"/HD/1/DOC/OLD.TXT",0 ex. "/HD/1/WINDOWS",0,"/HD/1/RECYCLED/WIN",0 Last edited by ATV on 23 Nov 2004, 08:30; edited 1 time in total |
|||
|
08 Nov 2004, 08:20 |
|
|
Barak 08 Nov 2004, 13:03
I'm not an asm programmer but in other languages I would do an if (check) statment to see if a directory is empty and if not I will delete all of its info and then delete the directory.
But what am I talking about, you already have thought of it i belive. |
|||
|
08 Nov 2004, 13:03 |
|
|
Wishing 09 Nov 2004, 08:56
Yeah.. do that ^ .... that way we can NEVER make a new directory since it
immediately would get deleted before we put anything in it |
|||
|
09 Nov 2004, 08:56 |
|
|
Barak 09 Nov 2004, 13:40
no no no, i mean when someone wants to delete a folder that is not empty.
|
|||
|
09 Nov 2004, 13:40 |
|
|
Madis731 09 Nov 2004, 14:52
I understand what you are saying and also
think that it is possible, but I haven't seen this so far  for example DOS commands.
There is some tricky part there. |
|||
|
09 Nov 2004, 14:52 |
|
|
ATV 11 Nov 2004, 08:05
Updated Removedir clear whole directory structure
Barak, Is this what you mean? Is it really kernels job to clear all? Little competition, because we need more space for MenuetOS. How much time it takes in your computer to clear "/hd/1/windows"? (my old P100 with 1003 files in FAT16 = 11s) Last edited by ATV on 17 Nov 2004, 09:16; edited 1 time in total |
|||
|
11 Nov 2004, 08:05 |
|
| Goto page 1, 2, 3, 4 Next < Last Thread | Next Thread > |
Forum Rules:
|