diff options
author | Glenn Morris <rgm@gnu.org> | 2014-01-06 21:11:14 -0500 |
---|---|---|
committer | Glenn Morris <rgm@gnu.org> | 2014-01-06 21:11:14 -0500 |
commit | 05834033161a7769b02dd2eea976938bb1795733 (patch) | |
tree | 341de1e82d8e18617baff82837331fa432528d59 | |
parent | 0d3c6661753ce5fd9f53ff9306b90a73addb8ef2 (diff) | |
download | emacs-05834033161a7769b02dd2eea976938bb1795733.tar.gz |
* etc/PROBLEMS: More removal of old stuff
-rw-r--r-- | etc/PROBLEMS | 58 |
1 files changed, 5 insertions, 53 deletions
diff --git a/etc/PROBLEMS b/etc/PROBLEMS index f3e2b5d6689..3d7a426b3fa 100644 --- a/etc/PROBLEMS +++ b/etc/PROBLEMS @@ -400,7 +400,7 @@ You need to configure your machine with a fully qualified domain name, If you cannot fix the configuration, you can set the Lisp variable mail-host-address to the value you want. -** NFS and RFS +** NFS *** Emacs says it has saved a file, but the file does not actually appear on disk. @@ -412,55 +412,6 @@ detect the problem. Emacs checks the failure codes of all the system calls involved in writing a file, including `close'; but in the case where the problem occurs, none of those system calls fails. -*** Editing files through RFS gives spurious "file has changed" warnings. -It is possible that a change in Emacs 18.37 gets around this problem, -but in case not, here is a description of how to fix the RFS bug that -causes it. - - There was a serious pair of bugs in the handling of the fsync() system - call in the RFS server. - - The first is that the fsync() call is handled as another name for the - close() system call (!!). It appears that fsync() is not used by very - many programs; Emacs version 18 does an fsync() before closing files - to make sure that the bits are on the disk. - - This is fixed by the enclosed patch to the RFS server. - - The second, more serious problem, is that fsync() is treated as a - non-blocking system call (i.e., it's implemented as a message that - gets sent to the remote system without waiting for a reply). Fsync is - a useful tool for building atomic file transactions. Implementing it - as a non-blocking RPC call (when the local call blocks until the sync - is done) is a bad idea; unfortunately, changing it will break the RFS - protocol. No fix was supplied for this problem. - - (as always, your line numbers may vary) - - % rcsdiff -c -r1.2 serversyscall.c - RCS file: RCS/serversyscall.c,v - retrieving revision 1.2 - diff -c -r1.2 serversyscall.c - *** /tmp/,RCSt1003677 Wed Jan 28 15:15:02 1987 - --- serversyscall.c Wed Jan 28 15:14:48 1987 - *************** - *** 163,169 **** - /* - * No return sent for close or fsync! - */ - ! if (syscall == RSYS_close || syscall == RSYS_fsync) - proc->p_returnval = deallocate_fd(proc, msg->m_args[0]); - else - { - --- 166,172 ---- - /* - * No return sent for close or fsync! - */ - ! if (syscall == RSYS_close) - proc->p_returnval = deallocate_fd(proc, msg->m_args[0]); - else - { - ** PSGML conflicts with sgml-mode. PSGML package uses the same names of some variables (like keymap) @@ -495,9 +446,10 @@ This is a known limitation of Emacs with no solution at this time. *** Emacs uses 100% of CPU time -This is a known problem with some versions of the Semantic package. -The solution is to upgrade Semantic to version 2.0pre4 (distributed -with CEDET 1.0pre4) or later. +This was a known problem with some old versions of the Semantic package. +The solution was to upgrade Semantic to version 2.0pre4 (distributed +with CEDET 1.0pre4) or later. Note that Emacs includes Semantic since +23.2, and this issue does not apply to the included version. *** Self-documentation messages are garbled. |