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 From: =?8859_1?B?Z/xudGVyIA==?=strubinsky Reply-To: strubinsky AT acm DOT org To: dmay AT tvi DOT edu, lhall AT rfk DOT com CC: cygwin AT cygwin DOT com Subject: Re: Re: Problem with database engine on Cygwin Date: Wed, 9 Apr 2003 16:09:41 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Message-Id: <20030409200940.CWUQ23505.lakemtao06.cox.net@smtp.central.cox.net> Just to follow the 20 char filename and the chnces it might appear to become a real filename, if you prepend the generated fn with, let's s 5 underscores your chnaces that this filename will ever exist are NIL! I have never seen files with a name like that over the last 20 years. It does not fix the original problem but keeps Murphy out of all! guenter > > From: dmay AT tvi DOT edu > Date: 2003/04/09 Wed PM 03:49:50 EDT > To: lhall AT rfk DOT com > CC: cygwin AT cygwin DOT com > Subject: Re: Problem with database engine on Cygwin > > 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 > #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; > } > > > -- > 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/ > -- 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/