linuxdcpp-team team mailing list archive

[Razzloss <razzloss@xxxxxxxxx>]

Meh, haven't really noticed any slowing due to fsyncs during downloads.

Though that particular fsync might be unnecessary when the destination
partition is different from temporary dl location. Since in that case
the file is moved pretty much immediately after that fsync. If it's the
same then I'd say it's better to have it synced, than risk losing the
data.

Problems with core function signatures are better discussed with the
upstream, but if I had to guess, I'd say it previously returned it's
success status but was later changed to throw and nobody bothered to
change the return type.

--RZ

** Changed in: linuxdcpp
   Importance: Undecided => Wishlist

-- 
linuxdcpp should not unconditionally fsync() finished downloads
https://bugs.launchpad.net/bugs/510493
You received this bug notification because you are a member of LinuxDC++
Team, which is subscribed to LinuxDC++.

Status in Linux DC++: New

Bug description:
Priority: wishlist

linuxdcpp should not unconditionally fsync() finished downloads. Calling fsync() on large files is a huge burden on an interactive system. The use of fsync() after a download has finished should at least be configurable.

Also, seriously, why does this function

size_t File::flush() throw(FileException) {
        if(isOpen() && fsync(h) == -1)
                throw FileException(Util::translateError(errno));
        return 0;
}

return a size_t? It always returns 0 or throws an exception, so it could just as well be void.