From mboxrd@z Thu Jan 1 00:00:00 1970 From: chrisw@rice.edu (Christopher Warrington) Date: Fri, 08 Feb 2008 03:40:55 -0600 Subject: [sup-talk] [PATCH] shell commands are now run in a child process In-Reply-To: <1202241831-sup-1777@south> References: <1202026272-3432-2-git-send-email-chrisw@rice.edu> <1202232814-sup-1005@south> <1202239755-sup-3523@chris-tablet> <1202241831-sup-1777@south> Message-ID: <1202462044-sup-3129@chris-tablet> 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