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: <3E94424B.DB1FD807@iee.org> Date: Wed, 09 Apr 2003 16:54:51 +0100 From: Don Sharp X-Accept-Language: en MIME-Version: 1.0 To: cygwin AT cygwin DOT com Subject: Re: Problem with database engine on Cygwin References: <265000-22003439144414575 AT M2W029 DOT mail2web DOT com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit "lhall AT pop DOT ma DOT ultranet DOT com" wrote: > > See my comment below. > > Original Message: > ----------------- > From: dmay AT tvi DOT edu > Date: Wed, 9 Apr 2003 07:10:46 -0600 (MDT) > To: cygwin AT cygwin DOT com, lhall AT rfk DOT com > Subject: Re: Problem with database engine on Cygwin > > On 8 Apr, Igor Pechtchanski wrote: > | Larry, > | > | It may be more complicated than that. unlink() calls DeleteFile(), and > | who knows what happens in the guts of it. For instance, I'm having a > | permission problem with deleting files on a Samba share from inside of > | applications (but no problems deleting them from the shell). I've traced > | it as far as the DeleteFile() call, which fails in the former case and > | succeeds in the latter. Go figure... > | > | My advice to the OP, though, is to check all the return codes, especially > | for system calls. > | Igor > | > | On Tue, 8 Apr 2003, lhall AT pop DOT ma DOT ultranet DOT com wrote: > | > |> Running on a FAT partition perhaps? > |> > |> You may find a review of the code for unlink() (remove() calls this) > |> call in the Cygwin DLL interesting. You might find it even more > interesting > |> to build your own debug version of cygwin1.dll and stop in this function. > |> ;-) > |> > |> Still sounds allot like you're having a permission problem on delete. > |> > |> Larry > |> > |> Original Message: > |> ----------------- > |> From: dmay AT tvi DOT edu > |> Date: Tue, 8 Apr 2003 16:44:06 -0600 (MDT) > |> To: cygwin AT cygwin DOT com, dmay AT tvi DOT edu > |> Subject: Re: Problem with database engine on Cygwin > |> > |> > |> On Monday, Apr 7, 2003 I posted a query re. an issue I am having using a > |> database engine I wrote with Cygwin. Through the use of Asserts() and > |> liberal > |> printf()s I have traced the problem down to a single line of code. > |> Basically, > |> the code does the following: > |> > |> int fd; > |> fd = creat ("SSNumberIndex.inx", 0644); > |> > |> This is failing with a "permission denied" system error. In terms of the > |> order of how things are done, the file SSNumberIndex.inx is unattached > from > |> an > |> old table, deleted, and then recreated. It is during this recreation > that I > |> am having the problem. There is not a file with this name in the current > |> directory (it is deleted through a remove() system call, and the system > |> indicates that the removal is successful). > |> > |> I have tried the following CYGWIN environment variables: > > > > This is an NTFS partition on Windows 2000, not a FAT partition. On the file > deletion, I check the return value and it checks out OK. In stepping > through > the code, I get a return value of 0 from the delete call. At that point, > the > file no longer shows up in file listings. It is when I try to recreate the > file with creat() that I get the "permission denied" error. Is it possible > that the file isn't really deleted, even though the return value indicates > the > delete was successful? > > Thanks for the ideas. I thought before I started debugging this problem > that > I did a pretty good job of monitoring return values...I obviously have some > work to do :o< > > 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 > Hi Everyone It might be worth putting a small sleep (~2 seconds) if the create fails and try it once again. I have heard that sometimes it takes a little while for all parts of the system to agree that the file has been deleted. HTH Don Sharp -- 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/