public inbox for cygwin@cygwin.com
 help / color / mirror / Atom feed
From: Mark Ord <ord@alphalink.com.au>
To: cygwin@cygwin.com
Subject: Re: cygwin-1.5.4-1 breaks fetchmail on Win9x
Date: Sun, 05 Oct 2003 03:16:00 -0000	[thread overview]
Message-ID: <3F7F77B0.853C8E40@alphalink.com.au> (raw)

Jason,

Jason Tishler <jason@tishler.net> wrote:

> I do not have access to 9x so you will have to debug this further
> yourself.  Can you run fetchmail under strace or gdb?  If so, can you
> determine why the attempt to delete the lock file fails?

Actually, on a further look, I think I have - the problem is
one of two things, depending on how ulink() is supposed to function.

I've always been under the impression that files need to be closed before
unlink() - which I guess is from my DOS days. If this still holds true,
it's a simple case of lock_state() in lock.c (fetchmail) calling unlink
on the lockfile while it still has the file pointer opened. (Explicitly
doing fclose() before unlink() sees the stale lock file being removed
correctly). -If- that's how unlink is supposed to behave, that's
obviously why.

However, I was curious as to why the same fetchmail binary worked fine
with cygwin-1.3.22, and looked up the unlink() man page on linux and came
across:

   If the name was the last link to a file but any  processes 
   still have the file open the file will remain in existence
   until the last file descriptor referring to it is  closed.

Which seems to imply that unlinking a file while a process has it open is
fine, and it is deleted when fclose() is called. If I am correct in this
assumption, fetchmail's code is okay, but cygwin-1.5.5 on Win9x doesn't do
it:

#include <stdlib.h>
#include <stdio.h>

int main(void)
{
   FILE* fp;

   if( (fp = fopen("file.txt", "r")) != NULL){
      unlink("file.txt");
      fclose(fp);
   }
   return(0);
}

11:06pm uname -a
CYGWIN_98-4.10 scholars 1.5.5(0.94/3/2) 2003-09-20 16:31 i686 unknown unknown
Cygwin
11:06pm [ord@scholars ~] > gcc test.c
11:06pm [ord@scholars ~] > touch file.txt
11:06pm [ord@scholars ~] > ls -l file.txt
-rw-r--r--    1 ord      all             0 Oct  4 23:06 file.txt
11:06pm [ord@scholars ~] > ./a
11:07pm [ord@scholars ~] > ls -l file.txt
-rw-r--r--    1 ord      all             0 Oct  4 23:06 file.txt

> > As far as I can tell, this is a Win9x (Win98SE) issue. Testing
> > fetchmail on XP with cygwin-1.5.5-1 doesn't seem to suffer from this
> > problem
> 
> Could this be a FAT/FAT32 vs. NTFS issue instead?

Maybe, though it seems like a unlink() on 9x vs. a unlink() on NT issue
with cygwin-1.5.5.

11:08pm [ord@chimera ~] > uname -a
CYGWIN_NT-5.1 chimera 1.5.5(0.94/3/2) 2003-09-20 16:31 i686 unknown unknown
Cygwin
11:08pm [ord@chimera ~] > touch file.txt
11:08pm [ord@chimera ~] > ls -l file.txt
-rw-r--r--    1 ord      None            0 Oct  4 23:08 file.txt
11:08pm [ord@chimera ~] > gcc test.c
11:08pm [ord@chimera ~] > ./a
11:08pm [ord@chimera ~] > ls -l file.txt
/bin/ls: file.txt: No such file or directory

I realise this still could be a FAT vs. NTFS issue with unlink(), or more
approprately, probably the code that is responsible for deleting an
unlinked file when the handle is closed. But FWIW, that's where the
problem seems to lie.

I've done a strace, which I can post if it's helpful, but personally I couldn't
find anything useful in it.

But wait... :)

Okay, I could be wrong, but I've been going through the code for unlink() and
I might be onto something. Note, I've never looked at any code from winsup
before, but hopefully I'm not far from the mark.

The source for cygwin-1.3.22 has the line code segment
(winsup/cygwin/syscalls.cc - unlink() ):

if (GetFileAttributes (win32_name) == INVALID_FILE_ATTRIBUTES
    || (!win32_name.isremote () && wincap.has_delete_on_close ()))
{
  syscall_printf ("CreateFile (FILE_FLAG_DELETE_ON_CLOSE) succeeded");
  goto ok;
}
else
{
  syscall_printf ("CreateFile (FILE_FLAG_DELETE_ON_CLOSE) failed");
  SetFileAttributes (win32_name, (DWORD) win32_name & ~(FILE_ATTRIBUTE_READONLY
| FILE_ATTRIBUTE_SYSTEM));
}

The source for cygwin-1.5.5 has the line code segment:
(winsup/cygwin/syscalls.cc - unlink() - line 177):

if (GetFileAttributes (win32_name) == INVALID_FILE_ATTRIBUTES
    || !win32_name.isremote ())
{ 
   syscall_printf ("CreateFile (FILE_FLAG_DELETE_ON_CLOSE) succeeded");
   goto ok;
}
else
{ 
   syscall_printf ("CreateFile (FILE_FLAG_DELETE_ON_CLOSE) failed");
   if (setattrs)
      SetFileAttributes (win32_name, (DWORD) win32_name &
~(FILE_ATTRIBUTE_READONLY | FILE_ATTRIBUTE_SYSTEM));
   }
}

Notible is that wincap.has_delete_on_close() *isn't* called/checked
in the 1.5.5 code.

Looking in winsup/cygwin/wincap.cc (1.5.5), all the wincaps 'entries' (sorry,
the syntax of those is a bit foriegn) for win9x has
has_delete_on_close:false, (while all for NT is true). I assume that
the effect is that wincap.has_delete_on_close() returns false on win9x.

Personally, I've never noticed the WinAPI docs specifying that
FILE_FLAG_DELETE_ON_CLOSE doesn't work on win9x, but at the same time, I've
never used the flag before. Based on what I found in wincaps.cc,
I'm guess it doesn't. In which case, if it's required as part of the if
statement for correct behaviour on win9x, 1.5.5 is actually it's going into
the true part of the if (which it *is* according to strace) and not falling
into the DeleteFile() code later on when (if) FILE_FLAG_DELETE_ON_CLOSE is
failing, hence the file not being deleted.

It seems to make sense, because if FILE_FLAG_DELETE_ON_CLOSE doesn't
delete on win9x (and doesn't cause CreateFile() to return an error),
GetFileAttributes() will succeed on the still existing file after
CloseHandle(), indicating unlink() was successful (or will be successful
when every handle to the file is closed), even when the file isn't
deleted.

In short, I'm assuming that DeleteFile() is required for correct behaviour
of unlink() under Win9x, and it's simply not happening in cygwin-1.5.5,
where it was in cygwin-1.3.22. I can't see why any other code in unlink()
would be responsible for the problem.

That's my educated WAG at what is happening. Maybe someone who is more
familar with the code in question/cygwin1.dll code in general can look
into whether this assessment is correct or not.

Mark.

-- 
Mark Ord                               | Take an eye for an eye and make the
Melbourne, Australia                   | whole world blind.
mailto://ord@alphalink.com.au          |                  'God Gave Me A Gun'
http://www.alphalink.com.au/~ord/home/ |    - Roger Clyne & The Peacemakers -

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

             reply	other threads:[~2003-10-05  1:45 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-10-05  3:16 Mark Ord [this message]
2003-10-07  2:58 ` Jason Tishler
2003-10-07  3:09   ` Christopher Faylor
2003-10-07 13:49     ` Jason Tishler
2003-10-07 15:29       ` Christopher Faylor
2003-10-07 16:12         ` cygwin-1.5.4-1 breaks fetchmail on Win9x (Pierre can you comment?) Christopher Faylor
2003-10-07 16:18           ` What Linux version corresponds to a specific cygwin version? Uwe Galle
2003-10-07 17:37             ` Ronald Landheer-Cieslak
2003-10-07 22:01             ` Hannu E K Nevalainen
2003-10-08  1:05           ` cygwin-1.5.4-1 breaks fetchmail on Win9x (Pierre can you comment?) Pierre A. Humblet
2003-10-08  1:08             ` Christopher Faylor
2003-10-10 13:17 ` cygwin-1.5.4-1 breaks fetchmail on Win9x Jason Tishler
  -- strict thread matches above, loose matches on Subject: below --
2003-09-27  4:21 Mark Ord
2003-09-29 12:03 ` Jason Tishler

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3F7F77B0.853C8E40@alphalink.com.au \
    --to=ord@alphalink.com.au \
    --cc=cygwin@cygwin.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).