[Mldonkey-tasks] [task #4342] Access to disk data (free space, max file name length)

[spiralvoice]

Update of task #4342 (project mldonkey):

                 Summary: commit failed for super-long name files => Access to
disk data (free space, max file name length)

    _______________________________________________________

Follow-up Comment #5:

Summary was: commit failed for super-long name files

I renamed this task because a broader topic will be addressed here.
Attached is a patch which demonstrates the features to be applied .
For a first impression call the "shares" command in the HTML
interface, it should print some data about the shared directories,
!!temp_directory and the core directory.

It lays the foundation for accessing this data:

type statfs = {
  f_type : int64;   (* type of filesystem *)
  f_bsize : int64;  (* optimal transfer block size *)
  f_blocks : int64; (* total data blocks in file system *)
  f_bfree : int64;  (* free blocks in fs *)
  f_bavail : int64; (* free blocks avail to non-superus *)
  f_files : int64;  (* total file nodes in file system *)
  f_ffree : int64;  (* free file nodes in fs *)
  f_fsid : unit;  (* See note in statfs(2) *)
  f_fnamelen : int64; (* maximum length of filenames *)
}

For the problem with the too-long-filenames something
like this can be coded (to be done):

if Unix32.fnamelen incoming_dir < String.length filename then
  String.shorten filename (Unix32.fnamelen incoming_dir)

I am also thinking about an option hdd_space_reserve (in MB,
default 50):

if (Unix32.diskfree !!temp_directoriy) < (!!hdd_space_reserve **
Int64.megabyte) then () (* pause all downloads here, 
print warnings on all interfaces, also in logfile and stop
logging *)

This should be done in the common module via add_infinite_timer.
These two things are most important and somewhat easy to code.

The rest is not so important as not all users are affected by
the problems described below.

The dllink command should also be made aware of this, if no
sparse files are used the file in !!temp_directory is created
with full length on Windows, so checking if enough space is
available and failing dllink is neccessary if not enough free
space is available. Currently only a zero-byte file and some
obscure error message is printed.

Something similar should be coded for committing if !!temp_directory
and the incoming directory are on different partitions, a check
on the incoming partition if enough space for copying the data
is available. But to reliable check if incoming and temp *are*
really on different physical partitions?
Unix2.rename tries renaming the file during commit, if it fails
with error code EXDEV
(see http://caml.inria.fr/pub/docs/manual-ocaml/libref/Unix.html)
it copies the file, but if this happens during multifile torrent
commit half of the files could already be copied as Unix2.rename
copies file by file and it is the only place where is notice that
different physical partitions are used.

If !!temp_directory and the incoming directory are on the same
physical partition this does not matter because the file is only
renamed so no more space is needed.

Further this patch currently only compiles on Linux,
Solaris/Sparc fails, did not test on other platforms yet.
Please report your findings, especially on Mac OSX, MinGW
(compile should fail there), Cygwin (might work) and *BSD.
    _______________________________________________________

Additional Item Attachment:

File name: free.patch                     Size:12 KB

<http://savannah.nongnu.org/task/download.php?item_id=4342&item_file_id=207>

    _______________________________________________________

Reply to this item at:

  <http://savannah.nongnu.org/task/?func=detailitem&item_id=4342>

_______________________________________________
  Nachricht geschickt von/durch Savannah
  http://savannah.nongnu.org/