delorie.com/archives/browse.cgi   search  
Mail Archives: cygwin/2003/04/09/15:50:40

Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sources.redhat.com/ml/#faqs>
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

--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 <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;
}


--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--

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019