Rockbox.org home
release
dev builds
extras
themes manual
wiki
device status forums
mailing lists
IRC bugs
patches
dev guide



Rockbox mail archive

Subject: Re: Status report
From: Paul Suade (paul.suade_at_laposte.net)
Date: 2002-05-08


Hum sorry, time is late and i did some mistakes :)

well, what we can do :

-truncate the first file and keeping link of the truncated part for the new
file
-if splitting on cluster alignment, just give the truncated part as the cluster
chain for the new file
-if not, move bytes in each cluster of the truncated part at their new right
place and give the truncated part as the cluster chain for the new file.

How to move byte in cluster chain ?

Bytes always be copied at a lesser address :

|----1234|56789ABC|DEF-----| ===> |12345678|ABCDEF--|

algo :

From the truncated part
    reset ring buffer
    and set the first cluster as current read cluster
    and set the first cluster as current write cluster
loop:
    read valid bytes into ring buffer
    if ring buffer filled (one cluster size),
        write the current cluster with ring buffer
        and reset ring buffer
        and set the next cluster as current write cluster
    if all valid bytes read from the current cluster,
        set the next cluster as current read cluster
    if current read sector is not the last cluster
        goto loop
    if ring buffer not reset,
        fill the gap in the ring buffer
        and write the current cluster with ring buffer
    if the current write cluster is not the last cluster
        free the last cluster

Even with such algo you still need to write back in all truncated clusters.

Yes, maybe we can use the truncated part as the cluster chain for the new file,
if we copy the pre-truncated cluster and fill the gap with a dummy mp3 chunk
(?) for the start cluster of the new file and link it with the post-truncated
clusters without change to form a cluster chain. But I'm not sure if it is
feasable and recommended.

----- Original Message -----
From: Paul Suade <paul.suade_at_laposte.net>
To: <rockbox_at_cool.haxx.se>
Sent: Wednesday, May 08, 2002 10:51 PM
Subject: Re: Status report

> >So it would seem to me, following this (perhaps flawed) logic, that we
> >could get by by only moving the first portion of the cluster of the new
> >file to a new location and linking back to the second cluster through the
> >FAT32 addressing. (Hmmm, maybe that's how fragmentation got started...)
>
> What are you saying ? to share some clusters between two files ? there is no
> way to know if a cluster is shared between files so it is strictly forbidden
to
> do so and there is chance that some fat tools would consider such
"duplicated"
> cluster chain as being corrupted.
>
> >We would lose a lot of space depending on how often this was done between
> >defrags (which I think would have to be run fairly often if this was used a
> >lot), but I *think* it would mean that we would only have to copy the
> >contents of one cluster to a new cluster, and not rewrite the whole file.
>
> Anyway, the minimal size of a file is cluster unit. And because the file
starts
> always on a cluster alignment. So if you split inside a cluster, the new file
> have no way to tell us where the first content of the file begins in the
first
> cluster of the file. So you are forced to shift bytes in the first sector.
But
> shifting bytes in the first sectors would also need to shift bytes of the
> following clusters.
>
> Supposedly it is possible to fill the gap with a fake header of something
like
> it in the mp3 file (i'm not a connoisseur), but you will still need to copy
all
> the clusters, so finally to "rewrite" the whole file.
>
>
>



Page was last modified "Jan 10 2012" The Rockbox Crew
aaa