Re: [Freedos-devel] Porting the FAT filesystem (18)

Hi > Hi, > > have you considered EFLS ? I have > a friend that already used it and said that it worked out of > the box. > One suposed advantage is that it was designed for embedded > and has a > small footprint. The licence is LGPL! I know the project,

Re: [Freedos-devel] Porting the FAT filesystem (18)

Hi Imre, > Eric told me you where working on something similar as me, > namely a portable FAT file system. that's right :-) > I am not aware of what your intentions are with this port, > so I am not going to try to steel this from you. > > But have you considered: > - that FreeDOS doesn't ha

Re: [Freedos-devel] Porting the FAT filesystem (18)

Hi, I also found this very good FAT32 tutorial Alain - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log

Re: [Freedos-devel] Porting the FAT filesystem (18)

Hi, have you considered EFLS ? I have a friend that already used it and said that it worked out of the box. One suposed advantage is that it was designed for embedded and has a small footprint. The licence is LGPL! While googling I also found this

Re: [Freedos-devel] Porting the FAT filesystem (18)

On Fri, 24 Aug 2007 19:30:43 +0200, Imre Leber <[EMAIL PROTECTED]> wrote: > namely a portable FAT file system. What do you mean with portable FAT file system? Portable to other operating systems I think...! But compatible with FAT32? btw: Do you know FAT32 Plus from Udo Kuhnt? It supports fi

Re: [Freedos-devel] Porting the FAT filesystem (18)

>- Oorspronkelijk bericht - >Van: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] >Verzonden: vrijdag, augustus 24, 2007 03:35 PM >Aan: 'freedos-devel' >Onderwerp: [Freedos-devel] Porting the FAT filesystem (18) > >Hi guys, > >here I'm back on track

[Freedos-devel] Porting the FAT filesystem (18)

Hi guys, here I'm back on track. I've been pretty busy in the past two months so I couldn't finish the port. At the end of the month I'll have the time to continue. How about if I post somewhere the work done so far? It's a "Microsoft Visual C 6.0" project and the test needs just an usb flash

Re: [Freedos-devel] Porting the FAT filesystem (16)

Hi Enrico, >> [after] dos_cd ("C:\hello\world"); >> dos_open ("C:\hello\world\my_file.txt", O_RDWR | O_CREAT, 0); [ok] >> dos_open ("my_file.txt", O_RDWR | O_CREAT, 0); [fails] > > As discussed earlier, dos_open is a bit "lowlevel" if you look > at DosOpenSft, you will find that it calls truename

Re: [Freedos-devel] Porting the FAT filesystem (16)

Hi Eric, > The difference in the current implementation is that we now > have a "cache" with two "near" fnodes in the kernel data > segment. That way, fewer far pointers are needed, but > several functions got more complicated. For example > get_f_node. The other difference is that > you use

Re: [Freedos-devel] Porting the FAT filesystem (16)

Hi Enrico, > The function works if I rewrite get_f_node() in the following way: ... > for(i = 0; i < NFILES; i++) ... > if(f_nodes[i].f_count == 0) ... > return &f_nodes[i]; ... > This was the implementation present in the source tree four years ago. The difference in the c

[Freedos-devel] Porting the FAT filesystem (16)

Hi guys, during the weekendd I made some tests in my port, and wanted to report the results. - 1. dos_mkdir(), dos_rmdir(), dos_delete() - All these fun

Re: [Freedos-devel] Porting the FAT filesystem (15)

Hi Enrico, I believe that you should take into account a very old dos problem (it happened to a few times in various MS-DOSes) some badly written program manages to write a file with true lower cases, it then becomes very difficult to delete it afterwards. I don't know how programs did manage

Re: [Freedos-devel] Porting the FAT filesystem (15)

Hi Eric and Bart, yes, upcasing filenames in dos_open() is not a problem. I'll add that in my port. The port status is the following: 1. dos_open(), dos_close(), (*) dos_read(), (*) dos_write() work. I still need to write some more test cases, but I'm quite sure that the FAT calculations are

Re: [Freedos-devel] Porting the FAT filesystem (15)

On 5/29/07, Eric Auer <[EMAIL PROTECTED]> wrote: > > there are no "toupper" or similar function calls from dos_open() > > down to exechr(). > > This is because the case (in) sensitivity handling happens in > DosOpenSft which in turn calls dos_open. So dos_open is one > step too "lowlevel" to be cas

Re: [Freedos-devel] Porting the FAT filesystem (15)

Hi Enrico, > there are no "toupper" or similar function calls from dos_open() > down to exechr(). This is because the case (in) sensitivity handling happens in DosOpenSft which in turn calls dos_open. So dos_open is one step too "lowlevel" to be case insensitive. Other functions seem to call tru

Re: [Freedos-devel] Porting the FAT filesystem (15)

Hi Eric, I did many debug sessions and that allowed me to study the filesystem code quite well: there are no "toupper" or similar function calls from dos_open() down to exechr(). Enrico > > Hi Enrico, > > > I noticed that in this version of FreeDOS, the function: > > Upmem (unsigned c

Re: [Freedos-devel] Porting the FAT filesystem (15)

Hi Enrico, > I noticed that in this version of FreeDOS, the function: > Upmem (unsigned char* str, unsigned int len) > is missing and the filesystem seems case sensitive. > I indeed can't open an existing file, named "foo.txt", when I call: > dos_open ("Foo.txt,..,..); Interesting. There are

[Freedos-devel] Porting the FAT filesystem (15)

Hi, I'm finally able to read files from my USB flash disk :-) I noticed that in this version of FreeDOS, the function: Upmem (unsigned char* str, unsigned int len) is missing and the filesystem seems case sensitive. I indeed can't open an existing file, named "foo.txt", when I call: dos_o

[Freedos-devel] Porting the FAT filesystem (13)

Hi Eric, I'm porting the following function: int rqblockio (unsigned char command, struct dpb *dpbp); In particular, the command I need to emulate is: C_BLDBPB (which builds the Bios Parameter Block) to do that, I'm gonna: 1. Read the boot sector of the volume 2. Make some calculati

Re: [Freedos-devel] Porting the FAT filesystem (12)

[EMAIL PROTECTED] escreveu: > UTF8 allows me not to introduce the concept of codepage in my port, which is > wants to be a stand alone filesystem library. > I, for example, could add a function that detects the presence of UTF8 tokens > in the string path passed to dos_open() > What I really

Re: [Freedos-devel] Porting the FAT filesystem (12)

Hi Eric, > There is really no need to inject or trick anything here. Just > implement the PROPER long file name functions int 21.71nn... > > http://www.ctyme.com/intr/rb-3194.htm (21.71) > ... http://www.ctyme.com/intr/rb-3209.htm (21.716c) ... > > http://www.microsoft.com/technet/prodtechnol/windo

Re: [Freedos-devel] Porting the FAT filesystem (12)

Hi Enrico, > Microsoft created ad-hoc functions to deal with UNICODE filenames > ... Linux allows the caller of fopen() to inject UTF8 names There is really no need to inject or trick anything here. Just implement the PROPER long file name functions int 21.71nn... http://www.ctyme.com/intr/rb-3

Re: [Freedos-devel] Porting the FAT filesystem (12)

Hi Eric and Tom, > Both functions are implemented in driver TSRs like DOSLFN, which > split long Unicode file names into short UTF-16 fragments which > are stored in special "invalid" directory entries to hide them > from normal DOS. Each file with a long name also is associated > to one short na

Re: [Freedos-devel] Porting the FAT filesystem (12)

> I'm not able yet to open a file on my flash USB disk but the > debugger travels safely (no NULL pointer exceptions) the following function: > dos_open (path_buf, O_WRONLY, 0); > I noted that MAX_CDSPATH = 67. > Could you explain me briefly how I should use the long file name API's? > Namely:

Re: [Freedos-devel] Porting the FAT filesystem (12)

Hi Enrico, > 1. How does FreeDOS to detect and read a LFN entry? It does not > 2. How FreeDOS writes a LFN entry? It does not Both functions are implemented in driver TSRs like DOSLFN, which split long Unicode file names into short UTF-16 fragments which are stored in special "invalid" dire

[Freedos-devel] Porting the FAT filesystem (12)

Hi Eric, I'm not able yet to open a file on my flash USB disk but the debugger travels safely (no NULL pointer exceptions) the following function: dos_open (path_buf, O_WRONLY, 0); I noted that MAX_CDSPATH = 67. Could you explain me briefly how I should use the long file name API's? Namely:

[Freedos-devel] Porting the FAT filesystem (11)

Hi Eric, I'm finally able to read the partitions written on my flash usb disk (I'm debugging the code on MSVC 6.0 and I wrote some functions that allow me to access the sectors of physical drives). I'm currently studying/working on the DosDefinePartition() function. The CHS and LBA functions

Re: [Freedos-devel] Porting the FAT filesystem (10)

Hi Enrico, > I read carefully the following document about CHS and LBA... > http://www.ata-atapi.com/hiwchs.htm > My guess... > My guess 2... > My guess 3... There is really no need to guess here ;-). Just read the rest of the code of STATIC int LBA_Get_Drive_Parameters( int drive, struct D

Re: [Freedos-devel] Porting the FAT filesystem (10)

Hi Eric and Andre, I read carefully the following document about CHS and LBA addressing performed by the BIOS: http://www.ata-atapi.com/hiwchs.htm > Hi, this sounds like a wrong error message. > > Having more than 64k heads or sectors-per-track is just > a sign of implausible extended geometri

Re: [Freedos-devel] Porting the FAT filesystem (10)

Pardon my jumping in, but last year I've encountered this at least once - back then I didn't have time to test it nor track it down (I received this error message as part of a customer bug report), and in the meantime I'm no longer working on that project... But this is definitely interesting.

Re: [Freedos-devel] Porting the FAT filesystem (10)

Hi, this sounds like a wrong error message. Having more than 64k heads or sectors-per-track is just a sign of implausible extended geometries. The real limit tested for is 2 Terabyte (more than 4 G total sectors)... However, maybe the fallback is to use CHS if the LBA data is implausible - then y

[Freedos-devel] Porting the FAT filesystem (10)

Hi Eric, Tests on Windows XP --- In order to test the filesystem, I wrote a layer of software that allows me to read/write physical sectors of USB flash disks. Space limitation According to the following piece of code, copied from the function LBA_Get_Drive_Pa

[Freedos-devel] Porting the FAT filesystem (9)

Hi Eric, I'm debugging the code and I can't understand the following line: UBYTE bootdrv = peekb(0, 0x5e0); Do you happen to know who writes at this address and what's the content of bootdrv after the peek call? Thanks for any help, Enrico ---

[Freedos-devel] Porting the FAT filesystem (9)

Hi Eric, >> In principle, I would like FFS to be able to handle >> pathnames longer than 67 and possibly read Unicode filenames. > > But then it would not be compatible to FAT. I see... Let's stick with FAT :-) > If you want to > have long unicode file names, then you have to implement > exactl

Re: [Freedos-devel] Porting the FAT filesystem (8)

Hi Enrico, > In principle, I would like FFS to be able to handle > pathnames longer than 67 and possibly read Unicode filenames. But then it would not be compatible to FAT. If you want to have long unicode file names, then you have to implement exactly that - LFN. Look at doslfn. But watch out,

[Freedos-devel] Porting the FAT filesystem (8)

Hi Eric, > That is not a compile time thing. Most of those variables are in > kernel.asm and the List of Lists, where they either have hardcoded > initial values (f_nodes_cnt is 0) or are initialized by zeroing > out memory areas or by calculating values during kernel init. > yes, I read carefull

[Freedos-devel] Porting the FAT filesystem (7)

Hi Eric and all, thanks for your last answer. The port is almost done and I started to debug the code. I figure that it will take me 2 to 3 months to have a solid and reliable port. I'm using Microsoft Visual Studio 6.0 to debug the filesystem and I temporarily created a simple ram disk. Wh

Re: [Freedos-devel] Porting the FAT filesystem (7)

Hi Enrico, > What I need to know to proceed, is how you guys configure FreeDOS at > compile time. In particular, I need to assign an initial value to > variables like: "f_nodes_cnt", or structures like "buffers" list... That is not a compile time thing. Most of those variables are in kernel.asm

Re: [Freedos-devel] Porting the FAT filesystem (6)

Hi Enrico, > I can't find in the source code the place where "fnode[2]" and "fnode_fd[2]" > are allocated: > > GLOBAL struct f_node fnode[2]; > GLOBAL int fnode_fd[2]; > > The above two lines come from "globals.h" The trick is that inthndlr.c defines MAIN, and "GLOBAL" is only "external" if MAI

[Freedos-devel] Porting the FAT filesystem (6)

Hi, I can't find in the source code the place where "fnode[2]" and "fnode_fd[2]" are allocated: GLOBAL struct f_node fnode[2]; GLOBAL int fnode_fd[2]; The above two lines come from "globals.h" but in no file (C or ASM) they are allocated. Is that possible? Any help is appreciated :-) Enrico

Re: [Freedos-devel] Porting the FAT filesystem

Hi Bart and Eric > it's the other way around! You need the latter ones: > dos_open, dos_close, rwblock,... > > Basically the old dos_read() and dos_write() were replaced by rwblock() > quite a few years ago but somebody (it could have been me) forgot to > remove the prototypes in proto.h. > Ok, go

Re: [Freedos-devel] Porting the FAT filesystem

> Hello can you mail me your code? > Thanks, ed. The code is here: www.fatti.com/ffs/ffs.zip That's the plain port of the FAT12/FAT16 filesystem which was included 4 years ago in FreeDOS. Allow a couple of days and I'll post the whole test suite, complete with an exaple project compileable w

Re: [Freedos-devel] Porting the FAT filesystem

Hi Enrico, Bart, > > The starting point of my port should be the following set of functions: > > "DosOpen()", "DosClose(), "DosRead", "DosWrite",... Those are how the kernel implements the basic int21 functions. The int21 handler is only a thin wrapper in this area. > > And not the following se

Re: [Freedos-devel] Porting the FAT filesystem

On 4/14/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > Please, correct me if I'm wrong: > The starting point of my port should be the following set of functions: > > "DosOpen()", "DosClose(), "DosRead", "DosWrite",... > > And not the following set: > > "dos_open()", "dos_close(), "dos_read", "d

Re: [Freedos-devel] Porting the FAT filesystem

Hello can you mail me your code? Thanks, ed. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: 14 April 2007 17:05 To: freedos-devel Subject: Re: [Freedos-devel] Porting the FAT filesystem Hi Eric, thanks for your detailed and

Re: [Freedos-devel] Porting the FAT filesystem

Hi Eric, thanks for your detailed and clear answer. What I'm doing is "borrowing" (with respect to the license) the filesystem and producing a, freestanding (i.e. NO OS dependancies), run-to-completion (no semaphores, no critical sections...), self-consistent, pure ANSI C filesystem for embe

Re: [Freedos-devel] Porting the FAT filesystem

Hi Enrico, for porting the FreeDOS implementation of FAT to another operating systems, you should simplify many things. In particular, each disk access goes through several layers, basically because this is what MS DOS does as well and we have to be compatible to drivers written for MS DOS. > C

[Freedos-devel] Porting the FAT filesystem

Hello, I don't know if this is the right place to post my question. I'm porting the FAT filesystem included in the latest release (20.36) of FreeDOS to two embedded platforms (ARM and Renesas M16C). Actually, it's gonna be a pure ANSI C port. I already ported successfuly the FreeDOS's filesyst