-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sun, 24 Aug 2003 18:54:04 -0600, Rodolfo J. Paiz wrote:
> I could not open the file with khexedit, since it complained about > insufficient memory (I have only 256MB of RAM in this machine). But the > theory of it actually having spaces or zeroes at the end does not seem > logical: what on God's green Earth would tack on 1GB of zeroes at the end, rsync > and if so, why does "ls -sh" report the file size correctly? "ls -sh" is like "du -h" and reports disk usage in blocks. > If this space > was indeed being used, then 63GB would have _actually_ expanded to 1.6TB, > instead of just _apparently_ having done so. But that is impossible because your disk is not that big. So, it could still be sparse blocks (or similar symptoms) at the _end_ of a file. You don't hear that, when the music player relies on the WAV length as found in the WAV file header. You would only hear the effect of sparse blocks in the beginning of the file, where empty blocks would be mixed into the WAV stream. > And then it wouldn't fit on the 120GB disk, whereas "df -m" shows the > expected 45GB free and I just moved 10GB to that drive as a test with no > problems. AFAICS, that 1TB discrepancy between listings does seem to be a > phantom... but from what, how, why, and how to fix it? > > I have no idea how to even start looking for this one, but while you guys > attempt to help me, is there perhaps some docs I should be reading at the > same time? A WAV editor which saves only the WAV content size as specified in the WAV header would be able to repair the files. - -- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/Sfgp0iMVcrivHFQRAksCAJ9VCkyWdI4zecILbnVDktx42V/GqwCggC/2 wHpqXMrvH21tFQo3ThNKtc4= =47DG -----END PGP SIGNATURE----- -- redhat-list mailing list unsubscribe mailto:[EMAIL PROTECTED] https://www.redhat.com/mailman/listinfo/redhat-list
