From: chrisw@rice.edu (Christopher Warrington)
Subject: [sup-talk] [PATCH] shell commands are now run in a child process
Date: Fri, 08 Feb 2008 03:40:55 -0600 [thread overview]
Message-ID: <1202462044-sup-3129@chris-tablet> (raw)
In-Reply-To: <1202241831-sup-1777@south>
Excerpts from William Morgan's message of Tue Feb 05 14:12:23 -0600 2008:
> It would be good to understand this a bit more. Why are the Ferret
> errors caused by open filehandles?
It is an odd interplay between Cygwin and Windows.
Sometimes, when ferret updates the index, it needs to delete (or
rename, I'm not sure) one of its files. So, ferret deletes the file
and then checks that it has been deleted (in fs_exists() from
ferret-.../ext/fs_store.c:70). To do the delete, unlink() is
called. Cygwin maps this to a series of Windows kernel calls that 1)
open the file, 2) set the delete-on-close flag, and 3) close the file.
(See unline_nt() in
http://cygwin.com/cgi-bin/cvsweb.cgi/src/winsup/cygwin/syscalls.cc?rev=1.469&content-type=text/x-cvsweb-markup&cvsroot=src)
If only sup is running, the file is closed and deleted. The file no
longer exists, so the open() in fs_exists fails with ENOENT. This is
to be expected.
If the editor is also running, things happen a little differently. The
editor has inherited all of sup's file handles. When the unlink() is
called this time, the same three kernel calls are made: 1) open, 2)
set delete-on-close flag, 3) close file. However, there are still an
open handle for the file (the editor has it), so the file enters the
DELETE_PENDING state. This causes the open() call in fs_exists to fail
with EACCES, triggering the exception.
I have a Process Monitor log of what's going on and the exception log
if you think that that would be helpful.
> And Windows supports fork now? I thought that didn't work.
No. But Cygwin does. This still causes the file handle duplication, so
I close all the open files except STDIN, STDOUT, and STDERR. That way,
the ferret file never enters the DELETE_PENDING state.
I don't think that this would be an issue if I were running sup
natively on Windows. The editor would NOT inherit sup's file
handlers. However, I have not been able to get ncurses (or the Ruby
gem, I can't remember) to compile for Windows. So, I'm stuck in Cygwin
bizzaro-land.
--
Christopher Warrington <chrisw at rice.edu>
next prev parent reply other threads:[~2008-02-08 9:40 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-02-03 8:11 Christopher Warrington
2008-02-05 17:34 ` William Morgan
2008-02-05 19:29 ` Christopher Warrington
2008-02-05 20:12 ` William Morgan
2008-02-08 9:40 ` Christopher Warrington [this message]
2008-02-19 17:48 ` William Morgan
2008-02-25 17:48 William Morgan
2008-03-01 4:42 ` Christopher Warrington
2008-03-01 20:37 ` William Morgan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1202462044-sup-3129@chris-tablet \
--to=chrisw@rice.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox