 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 07/06/2011 02:45 PM, Darren New wrote:
> On 6/7/2011 3:58, Invisible wrote:
>> Quite why Windows can't just write the final listing to the directory
>> block
>> and then write all the file data blocks sequentially is beyond me, but
>> anyway...
>
> Read up on how FAT works. It's not seeking back to write the directory
> listing. It's seeking back to read/write the FAT table.
OK. So it's called a file allocation table rather than a directory
listing. Same difference.
> Didn't you just say that security updates can be done without breaking
> things? Yet here you are, amazed that a Win3 program runs under XP. ;-)
Why would a security update break a program that only reads and writes
text files and accesses the serial port?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 6/7/2011 7:04, Invisible wrote:
> On 07/06/2011 02:47 PM, Darren New wrote:
>> On 6/7/2011 5:00, Invisible wrote:
>>> Still, why it can't build an image of what the final disk layout will
>>> look
>>> like in RAM and then write it all to disk in the most efficient order, I
>>> don't know. That's how I would probably do it.
>>
>> It's a removable disk.
>
> And?
And it has to be not completely corrupted if you remove it?
> Because it's a trivially easy optimisation?
Not really. What happens if you have multiple processes writing to the disk
at the same time? You're looking at one specific use case, and complaining
that the general tool isn't optimized for that use case.
--
Darren New, San Diego CA, USA (PST)
"Coding without comments is like
driving without turn signals."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 6/7/2011 7:05, Invisible wrote:
> OK. So do it in the opposite order. Write the directory entry last, after
> all the files have been written.
It's not the directory entry. It's the file allocation table.
--
Darren New, San Diego CA, USA (PST)
"Coding without comments is like
driving without turn signals."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 6/7/2011 7:08, Invisible wrote:
> OK. So it's called a file allocation table rather than a directory listing.
> Same difference.
Um, no. These are two entirely different things.
> Why would a security update break a program that only reads and writes text
> files and accesses the serial port?
Because the serial port is hardware that many programs accessed without
going through the operating system to do so.
--
Darren New, San Diego CA, USA (PST)
"Coding without comments is like
driving without turn signals."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> Because it's a trivially easy optimisation?
>
> Not really. What happens if you have multiple processes writing to the
> disk at the same time? You're looking at one specific use case, and
> complaining that the general tool isn't optimized for that use case.
You know, the rest of the filesystem is cached too, and that doesn't
seem to cause any problems...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 07/06/2011 03:36 PM, Darren New wrote:
> On 6/7/2011 7:08, Invisible wrote:
>> OK. So it's called a file allocation table rather than a directory
>> listing. Same difference.
>
> Um, no. These are two entirely different things.
In what way?
>> Why would a security update break a program that only reads and writes
>> text files and accesses the serial port?
>
> Because the serial port is hardware that many programs accessed without
> going through the operating system to do so.
Ah, now *that* I would expect to fail, yes. And, indeed, one of our
other programs *does* fail on Windows XP because it actually tries to
overwrite SERIAL.SYS with its own customised version...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 6/7/2011 7:49, Invisible wrote:
> You know, the rest of the filesystem is cached too,
Not on a removable floppy drive.
--
Darren New, San Diego CA, USA (PST)
"Coding without comments is like
driving without turn signals."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 07/06/2011 16:50, Invisible a écrit :
> On 07/06/2011 03:36 PM, Darren New wrote:
>> On 6/7/2011 7:08, Invisible wrote:
>>> OK. So it's called a file allocation table rather than a directory
>>> listing. Same difference.
>>
>> Um, no. These are two entirely different things.
>
> In what way?
The File allocation table is a MAP of sectors (which ones are free,
which ones are busy). When writing a file, not in that order:
* allocate sectors for the file content
* file the sectors with file content
* update the sector of the directory content to have "name-->sector/id"
* update the FAT.
Notice that until you update the FAT, you cannot have a concurrent
allocation for another file.
(also, the update of directory might need a new sector)
--
Software is like dirt - it costs time and money to change it and move it
around.
Just because you can't see it, it doesn't weigh anything,
and you can't drill a hole in it and stick a rivet into it doesn't mean
it's free.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 6/7/2011 7:50, Invisible wrote:
> On 07/06/2011 03:36 PM, Darren New wrote:
>> On 6/7/2011 7:08, Invisible wrote:
>>> OK. So it's called a file allocation table rather than a directory
>>> listing. Same difference.
>>
>> Um, no. These are two entirely different things.
>
> In what way?
http://en.wikipedia.org/wiki/FAT_file_system#Design
In the same way that a linked list is an entirely different thing from a
hashtable.
> Ah, now *that* I would expect to fail, yes. And, indeed, one of our other
> programs *does* fail on Windows XP because it actually tries to overwrite
> SERIAL.SYS with its own customised version...
That's another example.
--
Darren New, San Diego CA, USA (PST)
"Coding without comments is like
driving without turn signals."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 6/7/2011 8:02, Le_Forgeron wrote:
> The File allocation table is a MAP of sectors (which ones are free,
> which ones are busy).
Actually, it's not only that but also what granules are allocated to what
file in what order. It's not just a free-space bitmap, but an actual
collection of linked lists.
--
Darren New, San Diego CA, USA (PST)
"Coding without comments is like
driving without turn signals."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
