Follow-up Comment #3, bug #4248 (project mc): The problem is not where the swapping is handled or whether a device buffer is empty or not. The problem is that the viewer when subjected to the commands outlined in the report, it will read and read and read and read ... until a hard operating system crash or something similar stops it. You should limit that "read and read and read and ..." to something reasonable. More precisely the viewer should not read more than about 8MB between two keystrokes and also the actions performed between these two keystrokes should not last longer than about 0.25 of seconds.
Attempting to read the whole file into memory when switching to hex view definitely is a bug. You don't need that. Attempt to go to the end of the displayed data when the data is still growing is harder to fix but a reasonable solution would be to allow the data to grow for example 8 MB and then move to the end of the data fetched so far. Using ulimit causes hard abort when the program hits the limit and that is somewhat user-unfriendly. A nice error message would be much better. _______________________________________________________ Reply to this item at: <http://savannah.gnu.org/bugs/?func=detailitem&item_id=4248> _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ _______________________________________________ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel