Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Message-ID: <3E94424B.DB1FD807@iee.org>
Date: Wed, 09 Apr 2003 16:54:51 +0100
From: Don Sharp <dwsharp AT iee DOT org>
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:
> 
> <snip>
> 
> 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/