4:14 a.m.
Benson Margulies writes:
I've never seen any program other than xemacs pay any attention
to the
read-only attribute on a Windows directory. I suspect that XEmacs is
manually checking the bit. Given the complexity of ACLS, XEmacs needs to
just go ahead and try to write to the directory and see what comes back,
or learn to use the API that asks 'do I have effective Write access'.
Looking at the flag is only causing confusion.
We have both native and Cygwin implementations, and currently no
active experienced Windows developers. Patches would be welcome.
Vague specifications that say "this is hard" ;-) will be ignored by me
for sure (I don't even have a working Windows system at the moment),
and probably by the project for lack of skills.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
1:03 p.m.
New subject: XEmacs 21.4.19: Problem with customized folders on Windows XP
Can you point me at some description of how to get off the ground as an
XEmacs contributor.
-----Original Message-----
From: stephen(a)xemacs.org [mailto:stephen＠xemacs.org]
Sent: Sunday, November 12, 2006 11:15 PM
To: Benson Margulies
Cc: tony(a)tigerheron.com; XEmacs-Beta(a)xemacs.org
Subject: RE: XEmacs 21.4.19: Problem with customized folders on Windows
XP
Benson Margulies writes:
I've never seen any program other than xemacs pay any attention
to
the
read-only attribute on a Windows directory. I suspect that XEmacs is
manually checking the bit. Given the complexity of ACLS, XEmacs needs
to
just go ahead and try to write to the directory and see what comes
back,
or learn to use the API that asks 'do I have effective Write
access'.
Looking at the flag is only causing confusion.
We have both native and Cygwin implementations, and currently no
active experienced Windows developers. Patches would be welcome.
Vague specifications that say "this is hard" ;-) will be ignored by me
for sure (I don't even have a working Windows system at the moment),
and probably by the project for lack of skills.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
3:37 p.m.
New subject: XEmacs 21.4.19: Problem with customized folders on Windows XP
Benson Margulies writes:
Can you point me at some description of how to get off the ground as
an
XEmacs contributor.
You started yesterday by posting to xemacs-beta. :-) Thank you for
your interest!
As far as getting code into the repository:
The beta.info file describes the project workflow in some detail, but
for now the process may be summarized as
(1) you submit a patch to <xemacs-patches(a)xemacs.org> in "diff -u"
format for all files you change except ChangeLogs; ChangeLog
entries can be submitted as plain text or in diff -U 0 format.
There are several ChangeLogs in the tree, you should provide
appropriate entries for the nearest one to each file you change.
The `add-change-log-entry' command (C-x 4 a) invoked from the
point of each change will format a log entry in the appropriate
ChangeLog for you.
(2) we (the XEmacs Review Board) review the patch, and after
discussion and approval, somebody commits it. Discussion related
to technical issues with specific patches takes place on
xemacs-patches, until approval or veto.
If you have technical questions on how XEmacs works, or how best to do
something, post to <xemacs-beta(a)xemacs.org>. (We used to have a
separate xemacs-design list, and that could be reactivated if traffic
justifies, but that seems unlikely in the near future.)
How to organize your personal workspace: Unless you're really pressed
for disk space, check out the core mainline from CVS. There is a fair
amount of documentation, specifically the beta.texi file, that is
available only in the mainline. The internals.texi file is much more
up-to-date there than in the 21.4 branch. If you plan to work mostly
on 21.4, you could get just those files from
http://cvs.xemacs.org/viewcvs.cgi/XEmacs/xemacs/man/beta.texi and
http://cvs.xemacs.org/viewcvs.cgi/XEmacs/xemacs/man/internals/internals.texi.
Convert them to Info files with the makeinfo utility (available from
both Cygwin and MSYS, I'm sure). However, the 21.5 tree is also often
directly useful, as source for patches to backport.
The beta.info file is required reading; it describes the workflow and
other important disciplines in detail. The internals.info file
contains some early, generic sections on coding style and the like;
those are must-reads. Other parts of the Internals manual describe
how XEmacs works internally in some detail; read them as they seem
relevant. Contributions to the Internals manual are very valuable.
Check out the tree you plan to work on (21.4, using the -rrelease-21-4
tag, or 21.5, with no options, or with the -A option to update from a
21.4 tree). The module is named "xemacs". See http://cvs.xemacs.org/
for more information on our CVS repository; if you're familiar with
anonymous CVS, it's pretty standard stuff. We use the pserver
transport for anonymous CVS.
If you want to work on packaged applications, you'll also want to
check out the "packages" module. That's not necessary for the task
that triggered this thread, though.
Streamlining your administrative scutwork: If you expect to submit
many patches, or to do work that might be best done on a CVS branch,
request CVS commit access by sending a request to
<cvs-manager(a)xemacs.org>. We'll need an SSH public key in order to
grant write access, also a nickname for your CVS committer name. This
will take a few days to process (it requires absence of veto from the
Review Board---there's never been a veto AFAIK but it's a necessary
formality).
If you would like to directly participate in governance, including
approving patches for commit to the mainline, you'll need to become a
member of the Review Board. That requires that we get to know you, or
that you have a backer on the board to lobby for you. The best way to
put yourself forward as a potential Reviewer is to review patches for
technical issues (on xemacs-patches) and discuss design issues (on
xemacs-beta). Expect it to take a while, though. Most Reviewers were
active in development for several months before becoming Reviewers,
and it is essential to contribute to others' work by reviewing their
patches and responding to their requests for help in areas where you
have expertise.
Regards,
Steve
P.S. These remarks could be called my viewpoint, there's no formal
policy on this yet. However, I believe that the Review Board is in
substantial agreement on these guidelines.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
4:01 p.m.
New subject: XEmacs 21.4.19: Problem with customized folders on Windows XP
Benson Margulies wrote:
Can you point me at some description of how to get off the ground as
an
XEmacs contributor. ...
Please do it this way:
#define DONT_CHECK_DIRECTORY_WRITABLE
#if !defined(MS_WINDOWS) || !defined(DONT_CHECK_DIRECTORY_WRITABLE)
/* code that does the wrong thing on windows */
#endif
and send a patch to xemacs-patches.
Benson, feel free to take this on--I don't
have the time or the
expertise. Here's what I did on my system using the XEmacs 21.4.19 source:
In src/fileio.c:
DEFUN ("file-writable-p", Ffile_writable_p, 1, 1, 0, /*
Return t if file FILENAME can be written or created by you.
*/
(filename))
{
/* This function can GC. GC checked 1997.04.10. */
Lisp_Object abspath, dir;
Lisp_Object handler;
struct stat statbuf;
struct gcpro gcpro1;
CHECK_STRING (filename);
abspath = Fexpand_file_name (filename, Qnil);
/* If the file name has special constructs in it,
call the corresponding file handler. */
GCPRO1 (abspath);
handler = Ffind_file_name_handler (abspath, Qfile_writable_p);
UNGCPRO;
if (!NILP (handler))
return call2 (handler, Qfile_writable_p, abspath);
if (xemacs_stat ((char *) XSTRING_DATA (abspath), &statbuf) >= 0)
return (check_writable ((char *) XSTRING_DATA (abspath))
? Qt : Qnil);
// GCPRO1 (abspath);
// dir = Ffile_name_directory (abspath);
// UNGCPRO;
// return (check_writable (!NILP (dir) ? (char *) XSTRING_DATA (dir)
//: "")
// ? Qt : Qnil);
//AF The check_writable() method doesn't work correctly on NTFS so
//we are going to lie
return Qt;
}
With Stephen's suggestion, the commented out section would become:
#if !defined(MS_WINDOWS) || !defined(DONT_CHECK_DIRECTORY_WRITABLE)
GCPRO1 (abspath);
dir = Ffile_name_directory (abspath);
UNGCPRO;
return (check_writable (!NILP (dir) ? (char *) XSTRING_DATA (dir)
: "")
? Qt : Qnil);
#else
return Qt;
#endif
The "right" solution would be to fix the check_writable function in the
same file:
static int
check_writable (const char *filename)
{
#ifdef MS_WINDOWS
// Use correct access control for Windows
// Needs to work for FAT, FAT32, NTFS and ???
// Filename can be a file, directory, junction point(?), shortcut(??)
#else
#ifdef HAVE_EACCESS
return (eaccess (filename, W_OK) >= 0);
#else
/* Access isn't quite right because it uses the real uid
and we really want to test with the effective uid.
But Unix doesn't give us a right way to do it.
Opening with O_WRONLY could work for an ordinary file,
but would lose for directories. */
return (access (filename, W_OK) >= 0);
#endif
#endif
}
If you don't plan to take this on, let me know and I'll try to submit a
patch for the stop-gap solution.
--
Tony Freixas
Tiger Heron LLC
tony(a)tigerheron.com
http://www.tigerheron.com
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
6427
days inactive
6427
days old
3 comments
3 participants
participants (3)
-
Benson Margulies -
Stephen J. Turnbull -
Tony Freixas