gorged harddrive

Paul Johnson pauljohn32 at gmail.com
Tue Apr 8 00:56:38 UTC 2008


On Mon, Apr 7, 2008 at 4:58 PM, Patrick O'Callaghan
<pocallaghan at gmail.com> wrote:
> On Wed, 2008-04-02 at 23:13 +0800, Ed Greshko wrote:
>
>
>  "du -b" acts differently from "du", and "du -k", and "du -m". The latter
>  three all give the real disk usage, which for a sparse file will be low
>  until the file fills up. "du -b" gives the *apparent* file size, which
>  can indeed be larger than the total filesystem size.
>
>  So it all comes down to RTFM ...
>

I've seen this same trouble with torrent downloads.  And I'm not quite
sure about its practical meaning.

In particular, I wonder "How to kill the sparsely filled incomplete
torrent files"?

I'm using the KDE program ktorrent.  When you start to download a
bittorrent it creates a  bunch of file names and reserves all that
space. When the bit torrent client closes, it leaves behind those file
names even if they are not completed.   It seems to me that "du" gives
the reserved space totals, not the actually filled in space. (I don't
use the --apparent-files option).   I there any way to know if the
torrent files are downloaded completely?

I'm guessing it is impossible to tell if a file is filled up without
the bit torrent client itself to compare the files.    Sometimes the
client itself can't tell.

I have the following problem with the KDE torrent client ktorrent.
When ktorrent starts downloading a torrent, and then the system is
turned off, then re-started, the ktorrent starts to download stuff
again.  It downloads the working files to a temporary space, but when
it finishes downloading into the temporary space and it tries to copy
into the finished directory, then it mistakenly thinks that the files
already exist and it asks for new file names.  In other words, even
ktorrent is fooled by the "saved space" it marked out when it started
previously.  If you give it new file names, it creates them side by
side with the "apparent but really empty" files, and du shows the same
information for them.  The only way to tell if the files are real is
to try to load them in a program (in the case of music or video) or
mount (in the case of iso files).

??


-- 
Paul E. Johnson
Professor, Political Science
1541 Lilac Lane, Room 504
University of Kansas




More information about the fedora-list mailing list