Original message was posted November the 12th. Wasn't subscribed to the mailing list then so this is from the archives..
"It would be nice to keep temp files, and client cache, in the datastore. This would give freenet a fixed space usage, and eliminate out-of-disk-space and too-many-open-files errors." It would just move the problem, the datastore can still get full. Imho it is very easy to explain to the user that when you download things it will cost him additional diskspace. "It would also be nice if aforesaid attacker could not trivially obtain a list of keys in the store, without having a list of known keys already and doing some computational work." Agreed, this isn't too difficult. "When we want to make a temp file, we simply create a series of fake keys. We keep these only in RAM. The on-disk structure is not affected. We will have to keep these blocks from being reallocated, but that can be done in RAM; we are using the file for something anyway, so the small memory overhead is irrelevant." What is the content of these temp files? I'll presume these are in-progress downloads and (maybe) in progress uploads. If that is the case how would we handle restarts of the node. If the node would restart we would lose all this data. To handle this we would need to store this information on hard drive, and then the whole purpose would be lost. Or am i missing something? "Should we save the free blocks list to disk? Free blocks are generally blocks which have been used for temp files and so on, rather than real keys. We don't want to give this information away to an attacker." Again, how would we handle restarts. We need to know which blocks are empty or we wouldn't be able to know where to write. To find out which blocks are empty we have to walk through all the keys in the database and 'mark'(in memory) which ones are empty. This can make the initialisation off the database take very long, and it wouldn't scale very well. For a would-be attacker, these few minutes are hardly a problem but for a regular user these minutes would get pretty annoying. I like the idea of 'preallocation' and 'multiple store files'(as described in follow up messages). But this does require an on-disk list of empty blocks due to above reason. -- Peter van Fessem
