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