Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com Message-Id: <200304091950.h39Jo0kx029631@phys-nfs1.tvi.cc.nm.us> Date: Wed, 9 Apr 2003 13:49:50 -0600 (MDT) From: dmay AT tvi DOT edu Reply-To: dmay AT tvi DOT edu Subject: Re: Problem with database engine on Cygwin To: lhall AT rfk DOT com cc: cygwin AT cygwin DOT com In-Reply-To: <265000-22003439144414575@M2W029.mail2web.com> MIME-Version: 1.0 Content-Type: MULTIPART/mixed; BOUNDARY="413990147-1804289383-1049917797=:14304" Content-Transfer-Encoding: BINARY --413990147-1804289383-1049917797=:14304 Content-Type: TEXT/plain; charset=us-ascii On 9 Apr, lhall AT pop DOT ma DOT ultranet DOT com wrote: | Hi David, | | The semantics of deleting a file on UNIX/Linux systems is different than | on Windows with the Win32 API. Traditionally, access issues during deletion | under Cygwin could cause the unlink call to succeed in some circumstances | (the file was open by some other application requesting exclusivity) even | if the file was not immediately deleted. There has been more work in this | area recently as Chris Faylor pointed out. But you may need to dig deeper | than the POSIX API boundary to get a better understanding of the problem | you're seeing, though looking at the return values may give some clue. | Sounds like Igor Pechtchanski is already looking at the unlink() code in | cygwin1.dll for his problem. Perhaps he'll turn up something that will | help you too. | | Larry | | | | | -------------------------------------------------------------------- | mail2web - Check your email from the web at | http://mail2web.com/ . | | OK. I devised a work-around. You are probably right that the problem occurs when you try to delete the file. Apparently, the system still has some sense that the file is still there, even though it is not. The error condition is definitely occuring at the point that I try to create a file with the same name that has been deleted. There is a small C file attached that compiles cleanly under Cygwin that shows the behavior I am seeing with my database engine. Basically, as you can see when you run this code, on the second call to creat(), you get a permission denied error. Is this a windows thing or is it a cygwin thing? I don't have VC++, so I can't compile this for pure windows and see how it works. Would someone who has VC++ please do that for my curiosity and let me know what the result is? You will have to change the code slightly if you do. I worked around the issue in my code by closing the offending file, renaming it to a 20 character pseudo-random string and then deleting it. When I did that, I had no problem creating another file with the same name. The problem here is if I happen to get 2 20-character psuedo-random strings that are identical (not likely, I know), this is going to fail. So, I kludged it in a somewhat unclean, albeit functional, way. Is there another workaround that is a little more elegant? Thanks again for the responses so far...I am interested in the final disposition of this issue although I don't lurk the list. -- ================================= David May Senior UNIX System Administrator Albuquerque TVI 505-224-3015 --413990147-1804289383-1049917797=:14304 Content-Type: TEXT/plain; name="test_file_del.c" Content-Disposition: attachment; filename="test_file_del.c" #include #include #include #include #include #include #include char buf[] = "abcdefghijkABCDEFGHIJK"; #define FILENAME "test_windows_file" int main (void) { int fd; int status; fd = creat (FILENAME, (S_IWRITE|S_IREAD)); if (-1 == fd) { printf ("\n\nError creating %s:\n", FILENAME); perror(0); return -1; } #ifdef __CYGWIN__ fd = open (FILENAME, (O_RDWR|O_BINARY), (S_IREAD|S_IWRITE)); #endif #ifndef __CYGWIN__ fd = open (FILENAME, O_RDWR, (S_IREAD|S_IWRITE)); #endif if (-1 == fd) { printf ("\n\nError opening %s:\n", FILENAME); perror(0); return -1; } status = write (fd, buf, 20); if (status != 20) { printf ("\n\nError writing to %s\n", FILENAME); return -1; } status = close (fd); if (0 != status) { printf ("\n\nError closing %s\n", FILENAME); return -1; } status = remove (FILENAME); if (-1 == status) { printf ("\n\nError removing %s\n", FILENAME); return -1; } fd = 0; fd = creat (FILENAME, (S_IWRITE|S_IREAD)); if (-1 == fd) { printf ("\n\nError creating %s again:\n", FILENAME); perror(0); return -1; } fd = open (FILENAME, (O_RDWR|O_BINARY), (S_IREAD|S_IWRITE)); if (-1 == fd) { printf ("\n\nError opening %s:\n", FILENAME); perror(0); return -1; } status = write (fd, buf, 20); if (status != 20) { printf ("\n\nError writing to %s\n", FILENAME); return -1; } status = write (fd, "\n", 1); if (status != 1) { printf ("\n\nError writing to %s\n", FILENAME); return -1; } status = write (fd, buf, 20); if (status != 20) { printf ("\n\nError writing to %s\n", FILENAME); return -1; } status = close (fd); if (0 != status) { printf ("\n\nError closing %s again\n", FILENAME); return -1; } return 0; } --413990147-1804289383-1049917797=:14304 Content-Type: text/plain; charset=us-ascii -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ --413990147-1804289383-1049917797=:14304--