|
Rockbox mail archiveSubject: Re: Status reportRe: Status report
From: Paul Suade <paul.suade_at_laposte.net>
Date: Wed, 8 May 2002 23:27:07 +0200 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. > > > Received on 2002-05-08 Page template was last modified "Tue Sep 7 00:00:02 2021" The Rockbox Crew -- Privacy Policy |