"shatty" <shatty@xxxxxxxxxxxxx> 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.