Forums

LARWE's dosfs

Started by Will Dean May 8, 2008
Hi,

Are there many people around on the group who are actually using LARWE's 
dosfs in real apps?

I rather like its general style, and the code seems pretty good quality, but 
I'm actually starting to suspect it's pretty buggy.

Things I've noticed so far include:

Bug in root-directory allocation for new items in a root directory (this was 
mentioned in here last year by someone who posted a fix, thanks to him)
Possible problems with FAT12 (I'm not actually using FAT12, but some of the 
code caused compiler warnings, and looks wrong to me)
Doesn't seem to be able to seek properly (gets stuck in an infinite loop) 
seeking forward (I haven't debugged this yet - I think it's caused by 
seeking forward by exactly one cluster's worth of bytes, or something, which 
causes a loop in DFS_Seek to never complete.

Minor irritants are a lack of const-correctness and the use of uint8_t 
instead of char (though I'm sure there was a good reason for that).

I think I'm going to persist with it, but if there were other users who'd 
fixed problems, I would be interested in shared experiences.

I think Larwe himeself has moved on to other things now, which is fair 
enough - it's generous enough to have made it available in the first place, 
he certainly doesn't owe me free support.

Thanks,

Will


Will Dean wrote:

> Hi, > > Are there many people around on the group who are actually using LARWE's > dosfs in real apps?
I modified it a bit and posted a link to the results in this N.G. some time ago, as described from this snippet of an email to Lewin:
> The attached diffs document some trivial patches to permit > mixed-case pathnames and FAT16 < 16MB support. There are > also changes to DFS_OpenFile I needed to make to permit > working with files in the root directory; without them > a pointer to the filename backed-up one character too many > and there was no detection for a pathname without a separator.
I use it to inspect oddball FAT partitions on drives from certain embedded devices, and have plans to use it in some current projects of mine. Michael
On May 8, 10:10=A0am, "Will Dean" <w...@nospam.demon.co.uk> wrote:

> I think Larwe himeself has moved on to other things now, which is fair > enough - it's generous enough to have made it available in the first place=
,
> he certainly doesn't owe me free support.
It's not that I've moved on to other things so much as I haven't had time to go through all the effort and testing that's required to do a full release. Just rolling in some anonymously received patches is one thing - putting my name on it is a rather different story. There are about half a dozen patches waiting to be publicized. There is also the fast file I/O support (perhaps better called "more deterministic"), which I have scheduled for public release at the end of May; obviously that release will include bugfixes that I'm aware of to date. There are definitely a couple of FAT12 bugs. I don't think my test data set is adequate to flush them out. FAT12 is very much the poor cousin :)
Will

> Are there many people around on the group who are actually using LARWE's > dosfs in real apps?
Yes, I've used it.
> I rather like its general style, and the code seems pretty good quality, > but I'm actually starting to suspect it's pretty buggy.
I found a number of faults in the FAT12 code which I fixed and reported to Larwe (though I was never sure that he received them because of his email filtering service). I found also found faults in some code using div (rather than ldiv) as well as in some pointer incrementing.
> I think I'm going to persist with it, but if there were other users > who'd fixed problems, I would be interested in shared experiences.
It all worked quite well in the end. Andrew
"Will Dean" <will@nospam.demon.co.uk> writes:
> Minor irritants are a lack of const-correctness and the use of uint8_t > instead of char (though I'm sure there was a good reason for that).
uint8_t is guaranteed to be an 8-bit type, while char is not. The uint8_t type is optional, but if it is provided (in stdint.h), then char must be an 8-bit type, though char may be signed or unsigned. On an unrelated note, I just noticed that the between paragraphs 4 and 6 of section 6.2.5 of ISO/IEC 9899:1999, it appears that the correct way to designate an unsigned character type should be "unsigned signed char". Paragraph 4 defines "signed char" as one of the five standard signed integer types, and paragraph 6 says "For each of the signed integer types, there is a (but different) unsigned integer type (designated with the keyword unsigned) [...]". It does not state that any part of the designation of the signed integer type can be dropped as part of the construction of the designation of the corresponding unsigned integer type.
"Eric Smith" <eric@brouhaha.com> wrote in message 
news:m3ve1o37pd.fsf@donnybrook.brouhaha.com...
> "Will Dean" <will@nospam.demon.co.uk> writes: > > uint8_t is guaranteed to be an 8-bit type, while char is not. The > uint8_t type is optional, but if it is provided (in stdint.h), then > char must be an 8-bit type, though char may be signed or unsigned.
This kind of rarified argument would impress me a little more if the code didn't promptly cast all the uint8_t* back to char* to pass to the standard libary string functions. :-) So whatever property is being aimed for by using uint8_t*, it isn't something which can't survive a simple cast to char*... Will
"larwe" <zwsdotcom@gmail.com> wrote in message 
news:ae1917ad-a4bc-472f-a883-0d5ed8beb003@k13g2000hse.googlegroups.com...
On May 8, 10:10 am, "Will Dean" <w...@nospam.demon.co.uk> wrote:

{snip}
> which I have scheduled for public release at the end of May; obviously > that release will include bugfixes that I'm aware of to date.
Thanks for the reply - that's great to hear that you're still thinking about it. I suspect that by the time you release this version, my source will be so far from the original that there will be little benefit in merging, but it will still be useful to compare. As someone else mentioned, your use of 'div' might be playing somewhat fast-and-loose with signed/unsigned issues - C++ compilers in particular are not very happy with that code - I also suspect on a some platforms the div() ends up doing a lot of unused work too, because either the / or the % isn't used from any one call. Regards, Will
On May 8, 10:21 am, larwe <zwsdot...@gmail.com> wrote:
> On May 8, 10:10 am, "Will Dean" <w...@nospam.demon.co.uk> wrote: > > > I think Larwe himeself has moved on to other things now, which is fair > > enough - it's generous enough to have made it available in the first place, > > he certainly doesn't owe me free support. > > It's not that I've moved on to other things so much as I haven't had > time to go through all the effort and testing that's required to do a > full release. Just rolling in some anonymously received patches is one > thing - putting my name on it is a rather different story. There are > about half a dozen patches waiting to be publicized. There is also the > fast file I/O support (perhaps better called "more deterministic"), > which I have scheduled for public release at the end of May; obviously > that release will include bugfixes that I'm aware of to date.
Maybe you could put them on a website and let others decide how to use them.
On May 8, 6:16=A0pm, "Will Dean" <w...@nospam.demon.co.uk> wrote:

> So whatever property is being aimed for by using uint8_t*, it isn't > something which can't survive a simple cast to char*...
I should point out that DOSFS was not developed as an in vitro computer science project; it was originally a very small module in a much larger piece of firmware in a real product. Without going into details (as I don't remember them), the uint* declarations all come from the coding style requirements of the containing project. The containing project also had no standard library, so part of the extraction process involved changing over to str* functions.
In article <48237bd5$0$652$bed64819@news.gradwell.net>, 
will@nospam.demon.co.uk says...
> "Eric Smith" <eric@brouhaha.com> wrote in message > news:m3ve1o37pd.fsf@donnybrook.brouhaha.com... > > "Will Dean" <will@nospam.demon.co.uk> writes: > > > > uint8_t is guaranteed to be an 8-bit type, while char is not. The > > uint8_t type is optional, but if it is provided (in stdint.h), then > > char must be an 8-bit type, though char may be signed or unsigned. > > This kind of rarified argument would impress me a little more if the code > didn't promptly cast all the uint8_t* back to char* to pass to the standard > libary string functions. :-) > > So whatever property is being aimed for by using uint8_t*, it isn't > something which can't survive a simple cast to char*... > > Will >
I guess it depends on the situation. Wouldn't want to make sure that an item who's target was an 8 bit register was in fact 8 bits, so an architecture that could move around bigger words too didn't do the old even/odd thing and attempt to write a mutibyte value to the registers, but the library expects a native word when taking an argument, for stack alignment or some such. I'm not saying that is the case, but it came quickly to mind. As usual, I could be talking out my ass. :) Jim