Re: DiskDevice API v2.1

"shatty" <[email protected]> wrote:
> Somebody wrote:
> > But anyway, it *is* a problem, and we will not be=3D20
> > able to solve it completely (and efficiently when=3D20
> > complete), due to the heavy usage of entry=3D3D3D5Frefs=3D20
> > in BeOS.
> An offset in the in-memory data structure representing
> a volume/partition/whatever can efficiently and simply
> solve this problem assuming that you are simply going=3D20
> to move everything linearly.
> 
> You don't even have to remember which entry=5Frefs were
> from before the move.  You can treat them all the same
> by subtracting the offset every time you create an
> entry=5Fref.
> ...

How is that supposed to work=3F
The entry=5Frefs thing only happens when resizing or defragmenting a file 
system. Because there, the on disk location of files can be changed, 
and thus an entry=5Fref might be rendered invalid through that action.
When a partition is moved around, the file system doesn't even have to 
be aware if it doesn't use absolute block addressing - and that's only 
used by iso9660 and UDF - both are very unlikely to be found on a hard 
drive.

Adios...
   Axel.