On Mon, Apr 7, 2008 at 4:58 PM, Patrick O'Callaghan <pocallaghan@xxxxxxxxx> 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 -- fedora-list mailing list fedora-list@xxxxxxxxxx To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
