Ticket #116 (new defect) — at Initial Version
savannah: infinite loop reading large directories via fish
Reported by: | slavazanko | Owned by: | |
---|---|---|---|
Priority: | major | Milestone: | Future Releases |
Component: | mc-vfs | Version: | master |
Keywords: | Cc: | zaytsev | |
Blocked By: | Blocking: | ||
Branch state: | no branch | Votes for changeset: |
Description
Original: http://savannah.gnu.org/bugs/?15801
Submitted by: | Mario Lorenz <mlo> | Submitted on: | Sun 19 Feb 2006 12:15:18 PM UTC |
Category: | VFS | Severity: | 3 - Normal |
Status: | In Progress | Privacy: | Public |
Assigned to: | Pavel Tsekov <ptsekov> | Open/Closed: | Open |
Release: | 4.6.1 | Operating System: | GNU/Linux |
Discussion:
Thu 23 Feb 2006 03:38:12 PM UTC, comment #1: This problem has been bugging me for a while. I've just commited a patch which exposes a new user configurable option: fish_directory_timeout It contains the lifetime of a directory cache entry measured in seconds. I've adjusted the default value to 900 seconds (same as in ftpfs). This option is not configurable through the user interface, yet - one can change it only by directly editing MC's ini file. I plan to fix this soon. To test the new code you need to fetch MC from the cvs repository or grab a snapshot. Pavel Tsekov <ptsekov> Project AdministratorIn charge of this item. Sun 19 Feb 2006 12:15:18 PM UTC, original submission: Reading large remote directories via fish (shell link) over slow network links causes an infinite or at least very long loop when mc tries to read the directory multiple times. This is due to the fish directory timeout being hardcoded to 10 seconds, whereas reading a 15000 entry directory via a 64kbit/s link will take two minutes (way longer if not using compression). This means the directory objects will be marked obsolete before the directory is even loaded, causing an immediate reload once finished, with this pattern sometimes repeating even more often. That timeout should be tied to the (user settable) ftp directory timeout, or be given its own user settable value; at the very least it should be set to a sane value (that is, >> 10 seconds)
Note: See
TracTickets for help on using
tickets.