summaryrefslogtreecommitdiff
path: root/etc/PROBLEMS
diff options
context:
space:
mode:
authorGlenn Morris <rgm@gnu.org>2014-01-06 21:11:14 -0500
committerGlenn Morris <rgm@gnu.org>2014-01-06 21:11:14 -0500
commit05834033161a7769b02dd2eea976938bb1795733 (patch)
tree341de1e82d8e18617baff82837331fa432528d59 /etc/PROBLEMS
parent0d3c6661753ce5fd9f53ff9306b90a73addb8ef2 (diff)
downloademacs-05834033161a7769b02dd2eea976938bb1795733.tar.gz
* etc/PROBLEMS: More removal of old stuff
Diffstat (limited to 'etc/PROBLEMS')
-rw-r--r--etc/PROBLEMS58
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.