Changes between Version 2 and Version 3 of Ticket #116
- Timestamp:
- 09/15/10 15:57:14 (14 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Ticket #116 – Description
v2 v3 11 11 Thu 23 Feb 2006 03:38:12 PM UTC, comment #1: 12 12 13 14 15 13 This problem has been bugging me for a while. I've just commited a patch 16 17 14 which exposes a new user configurable option: 18 19 20 15 21 16 fish_directory_timeout 22 17 23 24 25 18 It contains the lifetime of a directory cache entry measured in seconds. 26 27 19 I've adjusted the default value to 900 seconds (same as in ftpfs). 28 20 29 30 31 21 This option is not configurable through the user interface, yet - one 32 33 22 can change it only by directly editing MC's ini file. I plan to fix this 34 35 23 soon. 36 24 37 38 39 25 To test the new code you need to fetch MC from the cvs repository or 40 41 26 grab a snapshot. 42 27 43 44 45 28 Pavel Tsekov <ptsekov> 46 47 29 Project AdministratorIn charge of this item. 48 49 30 Sun 19 Feb 2006 12:15:18 PM UTC, original submission: 50 31 51 52 53 32 Reading large remote directories via fish (shell link) 54 55 33 over slow network links causes an infinite or at least very long 56 57 34 loop when mc tries to read the directory multiple times. 58 35 59 60 61 36 This is due to the fish directory timeout being hardcoded to 10 seconds, 62 63 37 whereas reading a 15000 entry directory via a 64kbit/s link will take 64 65 38 two minutes (way longer if not using compression). This means the 66 67 39 directory objects will be marked obsolete before the directory is even 68 69 40 loaded, causing an immediate reload once finished, with this pattern 70 71 41 sometimes repeating even more often. 72 42 73 74 75 43 That timeout should be tied to the (user settable) ftp directory 76 77 44 timeout, or be given its own user settable value; at the very least it 78 79 45 should be set to a sane value (that is, >> 10 seconds). 80 81 46 }}}