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: <265000-22003439144414575@M2W029.mail2web.com> X-Priority: 3 Reply-To: lhall AT rfk DOT com X-Originating-IP: 209.113.174.244 From: "lhall AT pop DOT ma DOT ultranet DOT com" To: dmay AT tvi DOT edu, cygwin AT cygwin DOT com Subject: Re: Problem with database engine on Cygwin Date: Wed, 9 Apr 2003 10:44:14 -0400 MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 X-OriginalArrivalTime: 09 Apr 2003 14:44:13.0181 (UTC) FILETIME=[7CCFBAD0:01C2FEA6] Note-from-DJ: This may be spam Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by delorie.com id h39EiNv29169 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 -------------------------------------------------------------------- mail2web - Check your email from the web at http://mail2web.com/ . -- 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/