Rockbox mail archive
Subject: Re: Status report
From: Paul Suade (paul.suade_at_laposte.net)
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
-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--|
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
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
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>
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
> do so and there is chance that some fat tools would consider such
> 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
> 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
> cluster of the file. So you are forced to shift bytes in the first sector.
> 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
> it in the mp3 file (i'm not a connoisseur), but you will still need to copy
> the clusters, so finally to "rewrite" the whole file.
Page was last modified "Jan 10 2012" The Rockbox Crew