This is the mail archive of the
cygwin@cygwin.com
mailing list for the Cygwin project.
Re: Re: Problem with database engine on Cygwin
- From: günter strubinsky <strubinsky at cox dot net>
- To: dmay at tvi dot edu,lhall at rfk dot com
- Cc: cygwin at cygwin dot com
- Date: Wed, 9 Apr 2003 16:09:41 -0400
- Subject: Re: Re: Problem with database engine on Cygwin
- Reply-to: strubinsky at acm dot org
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 <sys/types.h>
> #include <sys/stat.h>
> #include <fcntl.h>
>
> #include <sys/errno.h>
>
> #include <stdio.h>
> #include <stdlib.h>
> #include <unistd.h>
>
> 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/