Ticket #39 (closed defect: fixed)

Opened 5 years ago

Last modified 2 weeks ago

trying to download on fat

Reported by: some1 Owned by: rakshasa
Priority: high Milestone: 1.0 Soggy Rabbit
Component: libtorrent Version: HEAD
Severity: normal Keywords: Caught exception
Cc:

Description

Whenever I try to download anything with rtorrent on a mounted fat32 fs, an error appears: "Caught exception: "Could not resize files"". With native (ext3) fs everything works fine. BTW, other torrent clients don't have this kind of problem.

Attachments

Change History

Changed 5 years ago by rakshasa

  • component changed from rtorrent to libtorrent
  • milestone set to 0.8 Sodden Squirrel

Changed 5 years ago by rakshasa

  • milestone changed from 0.8 Sodden Squirrel to 1.0 Soggy Rabbit

Changed 5 years ago by anonymous

  • priority changed from normal to high

Could be due to libtorrent using ftruncate to resize files on disk (data/File::set_size())

 http://www.winehq.org/hypermail/wine-devel/2002/01/att-0500/01-FSERVER.TXT

Please fix.

Changed 5 years ago by anonymous

Updated doc about disk allocation.

Changed 5 years ago by rakshasa

A few days ago I implemented a work-around that uses lseek and write. The problem with this is that it blocks for a long time. I might make enabling this a compile time option, atleast until i've made a worker thread for dealing with various IO stuff.

Changed 5 years ago by anonymous

Or you can make libtorrent allocate disk space on demand like most other bittorrent clients. Allocate in the unit of Chunks when writing a fresh chunk will help to make the system more responsive.

Of course you can also cooperate the allocation into a timeout signal and allocate a small piece a time.

Changed 5 years ago by rakshasa

There are advantages and disadvantages to both methods of allocating, but I'm not going to let a vfat specific bug affect that. The problem here is that a file resize that should have taken O(1) time takes O(N) time on vfat due to a bug.

Changed 5 years ago by anonymous

From man ftruncate, it's not really a bug. Posix allows both behaviors when length is bigger than file size.

So resize can still use ftruncate, when ftruncate returns -1, a lseek based resize function could be called to perform a not so perfect resizing. On most Unix filesystem, O(1) will be ensured.

Still allocation on demand will have some advantage if libtorrent is ported to the evil OS in the future.

Changed 5 years ago by rakshasa

O(1) isn't ensured on vfat using linux-2.6.9. The lseek+write seems to require the whole file to be blanked by the kernel, rather than waiting until the pages are written to.

Changed 5 years ago by anonymous

vfat is not a "Unix filesystem".

Changed 5 years ago by rakshasa

  • status changed from new to closed
  • resolution set to fixed

Yet some people still mount vfat filesystems from unix. This bug is fixed in SVN, but does ATM block. I might improve this later.

Changed 2 months ago by anonymous

I have the same problem. Is there any master hand can help us?  http://www.astrabeds.com/latex-mattresses.html

Changed 2 weeks ago by anonymous

I've watched his performance twice and I still can't let them out of my mind. He's a terrific pianist!  http://www.esleepmasters.com/Hammock_Chair_Stands_s/1869.htm

Add/Change #39 (trying to download on fat)

Author


E-mail address and user name can be saved in the Preferences.


Action
as closed
Next status will be 'reopened'
 
Note: See TracTickets for help on using tickets.