This is more a design problem than anything else, but because data loss is 
associated with it, it is bad enough to classify it as a nasty bug. 
 
Quite simply, when pan fails to write either an output file for what it has 
downloaded, or it fails to write a cache file because of the disk being full, 
the downloaded file is lost.  Worse, pan continues to download more articles, 
each of which may, or often will cause a disk full problem, where again the 
downloaded files are lost.  This is also a serious waste of bandwidth, 
especially for those who have limited amounts of data transfer each month. 
 
Additionally, when the disk is full and pan can't write the cache file, the log 
entries contain corrupted names for the failed article.  This is most likely 
because the name of the article is lost through freeing memory where the 
article was stored, then trying to read that memory again.  A snapshot of the 
log window is available at http://midori.shacknet.nu/images/snapshot23.png  I 
also have some concern that this may cause pan to crash, although it did not 
happen for me. 
 
What I think should happen: 
Pan should recognise when the disk space is running out and stop downloading to 
that partiton.  It should be possible to calculate how much space a downloaded 
article will require, and if there is not enough space, pan should suspend all 
tasks that are downloading to that hard drive partition.  Downloads to other 
partitons could continue.  The user must intervene in order for the failed 
downloads to continue.  The failed downloads should not be removed from the 
queue. 
 
Comments: 
Although theoretically the user should be able to control the situation 
themself, accidents do happen and maybe the wrong directory is chosen, as I 
did.  The result was downloading at 2.3Mbit for several hours and losing about 
1.2Gb of downloaded data.  I hope the importance of this can be understood.