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


<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




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