From: The Natural Philosopher on
MatthiasH wrote:
> The Natural Philosopher wrote:
>
>> Why cannot you just let the OS write sectors and the FAT as it wills?
>>
>> I mean either you are trying to look just like a disk drive (in which
>> case all you need to do is read and write 'sectors'), or you are going
>> to have to write your own driver.
>>
>> Or worse, your own OS..
>
> The goal is that the device should work without special driver, under
> any OS. My device wraps the contents of the external memory chip (a few
> kb in size) into a single file


Now I understand. Its one file so you are trying to economise on flash ram.

in a FAT16 system which can be read
> (works 100%) and written (works under Windows). Think of it as the EPROM
> programmer anyone would have dreamt of in the 90s: no drivers, no
> special software; access the chip through a file. For the reading part,
> I'm already there. For the writing, there is the problem I described
> earlier on. I need a way for my firmware to determine which cluster
> currently holds the file contents, whenever the OS decides to change that.

it seems to me you just have to use a bit of it to store that.

If its only ever READ as a file I still dont see why you dont let the OS
have its way, and have a writable FAT.

I think that logically you have an impasse. What the OS decides to do is
not predicable. Ergo you need to store what it has done. Ergo you need
to emulate a disk properly.

This reminds me of a project I was asked to do. Write some software to
drive a comms device to run in background under DOS.

When I arrived they said 'we have it all written, it just needs putting
in the background'

Sadly, after two days I had to report that the only thing of importance
in the whole project was getting it to run under DOS in the background.
The rest was totally trivial.

I have a nasty suspicion your project is similar.



From: David W. Hodgins on
On Tue, 13 Jul 2010 16:37:59 -0400, MatthiasH <news(a)retcheaprolexrode.org> wrote:

> I'm already there. For the writing, there is the problem I described
> earlier on. I need a way for my firmware to determine which cluster
> currently holds the file contents, whenever the OS decides to change that.

The decision of doing an update in place, or creating a new file,
and then doing an unlink/rename, is not done at the filesystem
or os level. That's handled by the user level program, when it
opens the file (read only, or read/write).

The only way I can see to force an update in place, would be to
provide your own editing tool, and either instructing users to
only use your editor, or add some additional application
verification, preventing other applications from being allowed
to write to the device.

Regards, Dave Hodgins

--
Change nomail.afraid.org to ody.ca to reply by email.
(nomail.afraid.org has been set up specifically for
use in usenet. Feel free to use it yourself.)
From: MatthiasH on
David W. Hodgins schrieb:
> On Tue, 13 Jul 2010 16:37:59 -0400, MatthiasH
> <news(a)retcheaprolexrode.org> wrote:
>
>> I'm already there. For the writing, there is the problem I described
>> earlier on. I need a way for my firmware to determine which cluster
>> currently holds the file contents, whenever the OS decides to change
>> that.
>
> The decision of doing an update in place, or creating a new file,
> and then doing an unlink/rename, is not done at the filesystem
> or os level. That's handled by the user level program, when it
> opens the file (read only, or read/write).

Ideally, read only should do nothing at all to the file. But which of
the two does read/write do?

Also, when doing the unlink/rename, is there something like a


> The only way I can see to force an update in place, would be to
> provide your own editing tool, and either instructing users to
> only use your editor, or add some additional application
> verification, preventing other applications from being allowed
> to write to the device.

Too bad. That's something I do not want at all.

Anyway, thank you for your reply.
Matthias