linuxdcpp should not unconditionally fsync() finished downloads

Bug #510493 reported by Marc D.
This bug affects 1 person
Affects Status Importance Assigned to Milestone

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.

Revision history for this message
Razzloss (razzloss) wrote :

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.


Changed in linuxdcpp:
importance: Undecided → Wishlist
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers