I guess, basically, because printing out a number ("you
have 10Mbytes of free space") and expecting the user to find the
corresponding number for the files to be submitted... is too much
work. That's the kind of bookkeeping that a lot of users expect the
system to do for them nowadays.
On the other hand, I myself would prefer to see the free space
ahead of time. I'll have to retain that idea.
Per-user limits can keep a single user from consuming
excessive amounts of disk space. Early detection will reduce the
consumption of excesive communication resources. Both ways, we are
reducing the potential for denial-of-service attacks.
In the applications I have in mind, the "good" users are going
to prepare and submit their files anyway; a lack of free space
requires a temporary deferment. This actually brings me to my next
wish list item:
Suppose you start a large transfer (this applies to either
upload or download). If the net is slow, it might take a long time to
complete the transfer. If the server is buey, it might be difficult
to even open a connection. There should be options for background
transfers, other than just setting the window aside and doing
something else ("clone" during transfer might help); something like
bftp ("bhttp"?) for loading a cache in the server-to-client direction,
and for queuing large jobs in the client-to-server direction.
Craig Milo Rogers