Why don't these P2P apps store the file chunks in your hard drive's free space? The fact that commands like `shred` exist means that you can readily read/write from it, and your OS will automatically overwrite the cache contents when you need to use space (and it doesn't matter because P2P networks are fault tolerant anyway).
That way users don't have to face the idea of "giving up" their disk space to be part of the network.
There is no generalized way to access the free space of a mounted and mutable file system.
What you'd be better off doing on Unix type OSes is creating a large empty file, deleting it but keeping the file handle, and reading/writing that. That's a traditional way to make a self erasing scratch file.
It doesn't work on Windows, though, because Windows won't let you delete a file that's open.
Storage is getting so cheap so quickly that this is a disappearing problem. Also, glossing over the barriers to implementation, your solution to the stated issue makes the overall fidelity of files on the network much less predictable, particularly for those with fewer up-votes. To compensate, the minimum number of copies of each part of each file that the network would have to cache to be reasonably certain of its ability to completely deliver to new downloaders the files riding the minimum up-vote threshold would have to go up. This would in turn push the minimum up-vote threshold up and make it more difficult for obscure content to survive on the network.
Shred doesn't operate on free space at all. It overwrites the file, and assumes that the underlying filesystem will overwrite the data in place.
http://www.gnu.org/software/coreutils/manual/html_node/shred...
"Please note that shred relies on a very important assumption: that the file system overwrites data in place. This is the traditional way to do things, but many modern file system designs do not satisfy this assumption. Exceptions include:
Log-structured or journaled file systems, such as those supplied with AIX and Solaris, and JFS, ReiserFS, XFS, Ext3 (in data=journal mode), BFS, NTFS, etc., when they are configured to journal data.
File systems that write redundant data and carry on even if some writes fail, such as RAID-based file systems.
File systems that make snapshots, such as Network Appliance's NFS server.
File systems that cache in temporary locations, such as NFS version 3 clients.
Compressed file systems."
That way users don't have to face the idea of "giving up" their disk space to be part of the network.