Patch for filesystems that do not support chmod.

Patch for filesystems that do not support chmod.

[Paul Stodghill]

Here's my problem: I store all of my Gnus files on a FAT32 filesystem so
that I can share them between Windows and Linux on my dual-boot system.
Unfortunately, Cygwin (Linux too, I think) does not provide a complete
implementation of chmod for FAT32 filesystems. As a result, Gnus's calls
to `set-file-modes' will likely fail.

I offer the following patch to NGnus 0.02 for your consideration.
Basically, it introduces a global variable, `gnus-set-file-modes', which
can be set to nil to prevent Gnus from making any calls to
set-file-modes.

I will be happy to rework this basic upon feedback. I have copyright
assignment papers files with the FSF for Gnus.

Thank you.


diff -ru ../ngnus-0.2-orig/lisp/gnus-registry.el ./lisp/gnus-registry.el
--- ../ngnus-0.2-orig/lisp/gnus-registry.el	2004-04-27 19:10:12.000000000 -0400
+++ ./lisp/gnus-registry.el	2004-05-19 08:42:52.000000000 -0400
@@ -202,7 +202,7 @@
 		
 		;; Replace the existing startup file with the temp file.
 		(rename-file working-file startup-file t)
-		(set-file-modes startup-file setmodes)))
+		(gnus-set-file-modes startup-file setmodes)))
 	  (condition-case nil
 	      (delete-file working-file)
 	    (file-error nil)))))
diff -ru ../ngnus-0.2-orig/lisp/gnus-start.el ./lisp/gnus-start.el
--- ../ngnus-0.2-orig/lisp/gnus-start.el	2004-04-08 12:02:08.000000000 -0400
+++ ./lisp/gnus-start.el	2004-05-19 08:42:46.000000000 -0400
@@ -870,7 +870,7 @@
 	  (when (and (file-exists-p gnus-current-startup-file)
 		     (file-exists-p dribble-file)
 		     (setq modes (file-modes gnus-current-startup-file)))
-	    (set-file-modes dribble-file modes))
+	    (gnus-set-file-modes dribble-file modes))
 	  (goto-char (point-min))
 	  (when (search-forward "Gnus was exited on purpose" nil t)
 	    (setq purpose t))
@@ -2752,7 +2752,7 @@
 
                       ;; Replace the existing startup file with the temp file.
                       (rename-file working-file startup-file t)
-                      (set-file-modes startup-file setmodes)))
+                      (gnus-set-file-modes startup-file setmodes)))
                 (condition-case nil
                     (delete-file working-file)
                   (file-error nil)))))
@@ -2897,7 +2897,7 @@
       (let ((coding-system-for-write gnus-ding-file-coding-system))
 	(gnus-write-buffer slave-name))
       (when modes
-	(set-file-modes slave-name modes)))))
+	(gnus-set-file-modes slave-name modes)))))
 
 (defun gnus-master-read-slave-newsrc ()
   (let ((slave-files
diff -ru ../ngnus-0.2-orig/lisp/gnus-util.el ./lisp/gnus-util.el
--- ../ngnus-0.2-orig/lisp/gnus-util.el	2004-04-07 21:48:42.000000000 -0400
+++ ./lisp/gnus-util.el	2004-05-19 08:43:06.000000000 -0400
@@ -1473,6 +1473,14 @@
 			  (concat old-dir "..")))))))))
 
 
+(defcustom gnus-set-file-modes t "When nil, do not attempt to change file modes. This is useful when Gnus files are stored on filesystems that do not support chmod (e.g., FAT32)." :type 'boolean :group 'gnus)
+
+(defun gnus-set-file-modes (filename mode)
+  "Wrapper for set-file-modes.
+No-op if `gnus-set-file-modes' is set to nil."
+  (if gnus-set-file-modes
+      (set-file-modes filename mode)))
+
 (provide 'gnus-util)
 
 ;;; gnus-util.el ends here
diff -ru ../ngnus-0.2-orig/lisp/gnus-uu.el ./lisp/gnus-uu.el
--- ../ngnus-0.2-orig/lisp/gnus-uu.el	2004-04-25 14:01:34.000000000 -0400
+++ ./lisp/gnus-uu.el	2004-05-19 08:42:42.000000000 -0400
@@ -1751,7 +1751,7 @@
 
       (setq gnus-uu-work-dir
 	    (mm-make-temp-file (concat gnus-uu-tmp-dir "gnus") 'dir))
-      (set-file-modes gnus-uu-work-dir 448)
+      (gnus-set-file-modes gnus-uu-work-dir 448)
       (setq gnus-uu-work-dir (file-name-as-directory gnus-uu-work-dir))
       (push (cons gnus-newsgroup-name gnus-uu-work-dir)
 	    gnus-uu-tmp-alist))))
diff -ru ../ngnus-0.2-orig/lisp/mail-source.el ./lisp/mail-source.el
--- ../ngnus-0.2-orig/lisp/mail-source.el	2004-03-08 01:54:24.000000000 -0500
+++ ./lisp/mail-source.el	2004-05-19 08:42:38.000000000 -0400
@@ -608,7 +608,7 @@
 			     (expand-file-name "movemail" exec-directory))
 			 nil errors nil from to)))))
 	      (when (file-exists-p to)
-		(set-file-modes to mail-source-default-file-modes))
+		(gnus-set-file-modes to mail-source-default-file-modes))
 	      (if (and (or (not (buffer-modified-p errors))
 			   (zerop (buffer-size errors)))
 		       (and (numberp result)
diff -ru ../ngnus-0.2-orig/lisp/mm-decode.el ./lisp/mm-decode.el
--- ../ngnus-0.2-orig/lisp/mm-decode.el	2004-03-22 00:31:58.000000000 -0500
+++ ./lisp/mm-decode.el	2004-05-19 08:42:36.000000000 -0400
@@ -735,7 +735,7 @@
 	       (copiousoutput (assoc "copiousoutput" mime-info))
 	       file buffer)
 	  ;; We create a private sub-directory where we store our files.
-	  (set-file-modes dir 448)
+	  (gnus-set-file-modes dir 448)
 	  (if filename
 	      (setq file (expand-file-name
 			  (gnus-map-function mm-file-name-rewrite-functions
diff -ru ../ngnus-0.2-orig/lisp/nnmail.el ./lisp/nnmail.el
--- ../ngnus-0.2-orig/lisp/nnmail.el	2004-04-15 02:42:24.000000000 -0400
+++ ./lisp/nnmail.el	2004-05-19 08:42:30.000000000 -0400
@@ -1882,7 +1882,7 @@
   (let ((coding-system-for-write nnmail-file-coding-system)
 	(file-name-coding-system nnmail-pathname-coding-system))
     (write-region start end filename append visit lockname)
-    (set-file-modes filename nnmail-default-file-modes)))
+    (gnus-set-file-modes filename nnmail-default-file-modes)))
 
 ;;;
 ;;; Status functions

Re: Patch for filesystems that do not support chmod.

[Jesper Harder]

Paul Stodghill <stodghil@cs.cornell.edu> writes:

> I store all of my Gnus files on a FAT32 filesystem so that I can
> share them between Windows and Linux on my dual-boot system.
> Unfortunately, Cygwin (Linux too, I think) does not provide a
> complete implementation of chmod for FAT32 filesystems. As a result,
> Gnus's calls to `set-file-modes' will likely fail.

It's not clear to me whether you're saying that `set-file-modes'
actually throws an error or you think it _might_ throw an error.

But if it does, I'd tend to think it's a bug in XEmacs, which it would
be bette to fix there instead of in Gnus.

-- 
Jesper Harder                                <http://purl.org/harder/>

Re: Patch for filesystems that do not support chmod.

[Lars Magne Ingebrigtsen]

Jesper Harder <harder@ifa.au.dk> writes:

> It's not clear to me whether you're saying that `set-file-modes'
> actually throws an error or you think it _might_ throw an error.
>
> But if it does, I'd tend to think it's a bug in XEmacs, which it would
> be bette to fix there instead of in Gnus.

Hm...  I'm not sure.  Would it be better for the chmod to fail
silently on some OS-es than letting the user control this explicitly
and be made aware of the issue?

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Patch for filesystems that do not support chmod.

[Jesper Harder]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Jesper Harder <harder@ifa.au.dk> writes:
>
>> It's not clear to me whether you're saying that `set-file-modes'
>> actually throws an error or you think it _might_ throw an error.
>>
>> But if it does, I'd tend to think it's a bug in XEmacs, which it would
>> be bette to fix there instead of in Gnus.
>
> Hm...  I'm not sure.  Would it be better for the chmod to fail
> silently on some OS-es than letting the user control this explicitly
> and be made aware of the issue?

As far as I can tell, none of the other places in the Emacs sources
where `set-file-modes' is used take any OS specific precautions.

Also, does this only happen for XEmacs+cygwin -- what about
XEmacs+windows, Emacs+windows, Emacs+cygwin, Emacs+dos etc.

If XEmacs+cygwin is the odd man out, I think it would be better to
make it consistant with the other ports.

-- 
Jesper Harder                                <http://purl.org/harder/>

Re: Patch for filesystems that do not support chmod.

[Lars Magne Ingebrigtsen]

Jesper Harder <harder@ifa.au.dk> writes:

> As far as I can tell, none of the other places in the Emacs sources
> where `set-file-modes' is used take any OS specific precautions.

Right.  But are these called way down in the code, or are they "user
command"-like things?

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Patch for filesystems that do not support chmod.

[Paul Stodghill]

> If XEmacs+cygwin is the odd man out, I think it would be better to
> make it consistant with the other ports.

XEmacs will raise an exception on any platform when the call to chmod
fails. This can happen, for instance, if you do not own the file being
chmod'ed. I believe that this can also happen for certain file modes on
SMB file systems. Someone with a Linux system and a Samba mounted file
system could verify this.

This is not a platform bug. IMO, Gnus should not request a file mode
that the underlying filesystem cannot support.

Re: Patch for filesystems that do not support chmod.

[Paul Stodghill]

I wrote,

> This is not a platform bug. IMO, Gnus should not request a file mode
> that the underlying filesystem cannot support.

... or, Gnus should gracefully handle the case of when the
set-file-modes call fails.

Re: Patch for filesystems that do not support chmod.

[Jon Ericson]

Paul Stodghill <stodghil@cs.cornell.edu> writes:

> I wrote,
>
>> This is not a platform bug. IMO, Gnus should not request a file mode
>> that the underlying filesystem cannot support.
>
> ... or, Gnus should gracefully handle the case of when the
> set-file-modes call fails.

Yes, please.  Recently the company mandated virus checker on my
machine has been deleting email as Gnus rights it disk.  When Gnus
tries to chmod the non-existent file, it can't.  I've had to delete
the mails from .emacs-mail-crash-box to read my mail, which is a huge
pain.[1]

Thanks,
Jon

Footnotes: 
[1]  But not enough pain to track down either the virus scan or the
     Gnus issue yet.  I'm not even sure if I have diagnosed the
     problem correctly.

Re: Patch for filesystems that do not support chmod.

[Lars Magne Ingebrigtsen]

Paul Stodghill <stodghil@cs.cornell.edu> writes:

> ... or, Gnus should gracefully handle the case of when the
> set-file-modes call fails.

I've now applied your patch, but changed the gnus-set-file-modes
function to just ignore all errors.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Patch for filesystems that do not support chmod.

[Jesper Harder]

Paul Stodghill <stodghil@cs.cornell.edu> writes:

>> If XEmacs+cygwin is the odd man out, I think it would be better to
>> make it consistant with the other ports.
>
> XEmacs will raise an exception on any platform when the call to chmod
> fails.

OK, I'm just surprised that we haven't seen this problem before --
some of those set-file-modes lines have been there for a long time,
AFAIK.

Does somone know if Emacs behaves in the same way as XEmacs?

> This is not a platform bug. IMO, Gnus should not request a file mode
> that the underlying filesystem cannot support.

I don't know ... if you're requesting something which the semantics of
the file system doesn't support, I think it's legitimate to just do
something reasonable and not throw an error -- e.g. if you request +x
on ms-windows then it could safely be ignored because all files on
ms-windows are executable anyway.

The Common Lisp standard recommends this type of approach:

  An implementation is required to recognize all of the ‘open’ keyword
  options and to do something reasonable in the context of the host
  operating system.  For example, if a file system does not support
  distinct file versions and does not distinguish the notions of
  deletion and expunging, :new-version might be treated the same as
  :rename or :supersede, and :rename-and-delete might be treated the
  same as :supersede.

-- 
Jesper Harder                                <http://purl.org/harder/>

Re: Patch for filesystems that do not support chmod.

[Paul Stodghill]

> It's not clear to me whether you're saying that `set-file-modes'
> actually throws an error or you think it _might_ throw an error.

It throws an error. Gnus cannot fetch new mail as a result.

> But if it does, I'd tend to think it's a bug in XEmacs, which it would
> be bette to fix there instead of in Gnus.

I'm not sure that I agree. The underlying "chmod" call is returning an
error status. XEmacs raises and error. I don't see this as a bug in
XEmacs.