* Re: cygwin-1.5.4-1 breaks fetchmail on Win9x
@ 2003-10-05 3:16 Mark Ord
2003-10-07 2:58 ` Jason Tishler
2003-10-10 13:17 ` cygwin-1.5.4-1 breaks fetchmail on Win9x Jason Tishler
0 siblings, 2 replies; 14+ messages in thread
From: Mark Ord @ 2003-10-05 3:16 UTC (permalink / raw)
To: cygwin
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/
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: cygwin-1.5.4-1 breaks fetchmail on Win9x
2003-10-05 3:16 cygwin-1.5.4-1 breaks fetchmail on Win9x Mark Ord
@ 2003-10-07 2:58 ` Jason Tishler
2003-10-07 3:09 ` Christopher Faylor
2003-10-10 13:17 ` cygwin-1.5.4-1 breaks fetchmail on Win9x Jason Tishler
1 sibling, 1 reply; 14+ messages in thread
From: Jason Tishler @ 2003-10-07 2:58 UTC (permalink / raw)
To: cygwin
Chris,
On Sun, Oct 05, 2003 at 11:45:20AM +1000, Mark Ord wrote:
> 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 ()))
> [snip]
>
> 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 ())
> [snip]
>
> Notible is that wincap.has_delete_on_close() *isn't* called/checked
> in the 1.5.5 code.
It appears that the following commit removed the
wincap.has_delete_on_close() check:
http://cygwin.com/ml/cygwin-cvs/2003-q1/msg00400.html
Specifically, the following hunk:
- if (!win32_name.isremote ()
- || (GetFileAttributes (win32_name) == INVALID_FILE_ATTRIBUTES
- || wincap.has_delete_on_close ()))
+ if (GetFileAttributes (win32_name) == INVALID_FILE_ATTRIBUTES
+ || !win32_name.isremote ())
AFAICT, the ChangeLog is not congruent with the above. Did another
unrelated change sneak in accidentally?
BTW, there seemed to be some gyration regarding this section of unlink()
during that time period:
$ for ((i=254;i<296;i=i+1))
> do
> echo 1.$i
> cvs up -p -r 1.$i syscalls.cc | fgrep wincap.has_delete_on_close
> done
1.254
|| (!win32_name.isremote () && wincap.has_delete_on_close ()))
1.255
1.256
1.257
|| wincap.has_delete_on_close ()))
1.258
|| wincap.has_delete_on_close ()))
1.259
1.260
...
Thanks,
Jason
--
PGP/GPG Key: http://www.tishler.net/jason/pubkey.asc or key servers
Fingerprint: 7A73 1405 7F2B E669 C19D 8784 1AFD E4CC ECF4 8EF6
--
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/
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: cygwin-1.5.4-1 breaks fetchmail on Win9x
2003-10-07 2:58 ` Jason Tishler
@ 2003-10-07 3:09 ` Christopher Faylor
2003-10-07 13:49 ` Jason Tishler
0 siblings, 1 reply; 14+ messages in thread
From: Christopher Faylor @ 2003-10-07 3:09 UTC (permalink / raw)
To: cygwin
On Mon, Oct 06, 2003 at 10:13:00PM -0400, Jason Tishler wrote:
>BTW, there seemed to be some gyration regarding this section of unlink()
>during that time period:
...which might be illuminated by reading the archives, I suspect...
cgf
--
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/
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: cygwin-1.5.4-1 breaks fetchmail on Win9x
2003-10-07 3:09 ` Christopher Faylor
@ 2003-10-07 13:49 ` Jason Tishler
2003-10-07 15:29 ` Christopher Faylor
0 siblings, 1 reply; 14+ messages in thread
From: Jason Tishler @ 2003-10-07 13:49 UTC (permalink / raw)
To: cygwin
Chris,
On Mon, Oct 06, 2003 at 10:58:37PM -0400, Christopher Faylor wrote:
> On Mon, Oct 06, 2003 at 10:13:00PM -0400, Jason Tishler wrote:
> >BTW, there seemed to be some gyration regarding this section of
> >unlink() during that time period:
>
> ...which might be illuminated by reading the archives, I suspect...
I tried searching the archives via Google and Cygwin's mailing list
search engine, but came up empty. Would you be willing to enlighten
me?
Thanks,
Jason
--
PGP/GPG Key: http://www.tishler.net/jason/pubkey.asc or key servers
Fingerprint: 7A73 1405 7F2B E669 C19D 8784 1AFD E4CC ECF4 8EF6
--
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/
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: cygwin-1.5.4-1 breaks fetchmail on Win9x
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
0 siblings, 1 reply; 14+ messages in thread
From: Christopher Faylor @ 2003-10-07 15:29 UTC (permalink / raw)
To: cygwin
On Tue, Oct 07, 2003 at 09:19:05AM -0400, Jason Tishler wrote:
>Chris,
>
>On Mon, Oct 06, 2003 at 10:58:37PM -0400, Christopher Faylor wrote:
>> On Mon, Oct 06, 2003 at 10:13:00PM -0400, Jason Tishler wrote:
>> >BTW, there seemed to be some gyration regarding this section of
>> >unlink() during that time period:
>>
>> ...which might be illuminated by reading the archives, I suspect...
>
>I tried searching the archives via Google and Cygwin's mailing list
>search engine, but came up empty. Would you be willing to enlighten
>me?
Actually, I am trying not to have to do the search myself. I recall
that there was a discussion about this with Pierre which caused the
change to take place. It might have been in the cygwin-developers list.
--
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/
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: cygwin-1.5.4-1 breaks fetchmail on Win9x (Pierre can you comment?)
2003-10-07 15:29 ` Christopher Faylor
@ 2003-10-07 16:12 ` Christopher Faylor
2003-10-07 16:18 ` What Linux version corresponds to a specific cygwin version? Uwe Galle
2003-10-08 1:05 ` cygwin-1.5.4-1 breaks fetchmail on Win9x (Pierre can you comment?) Pierre A. Humblet
0 siblings, 2 replies; 14+ messages in thread
From: Christopher Faylor @ 2003-10-07 16:12 UTC (permalink / raw)
To: cygwin
[-- Attachment #1: Type: text/plain, Size: 867 bytes --]
On Tue, Oct 07, 2003 at 09:49:14AM -0400, Christopher Faylor wrote:
>On Tue, Oct 07, 2003 at 09:19:05AM -0400, Jason Tishler wrote:
>>On Mon, Oct 06, 2003 at 10:58:37PM -0400, Christopher Faylor wrote:
>>>On Mon, Oct 06, 2003 at 10:13:00PM -0400, Jason Tishler wrote:
>>>>BTW, there seemed to be some gyration regarding this section of
>>>>unlink() during that time period:
>>>
>>>...which might be illuminated by reading the archives, I suspect...
>>
>>I tried searching the archives via Google and Cygwin's mailing list
>>search engine, but came up empty. Would you be willing to enlighten
>>me?
>
>Actually, I am trying not to have to do the search myself. I recall
>that there was a discussion about this with Pierre which caused the
>change to take place. It might have been in the cygwin-developers
>list.
Here is the thread from my personal archives.
cgf
[-- Attachment #2: unlink.mail --]
[-- Type: text/plain, Size: 9062 bytes --]
From cygwin-developers-return-6502-cgf=redhat.com@nowhere.com Mon Mar 10 10:34:22 2003
Date: Mon, 10 Mar 2003 10:36:26 -0500
From: "Pierre A. Humblet"
MIME-Version: 1.0
To: cygwin-developers
Subject: unlink
Status: RO
Content-Length: 2611
Lines: 59
Chris,
It's a great idea to use FILE_FLAG_DELETE_ON_CLOSE for unlink,
but a few bells rang when I read the code.
1) ntsec
/> mkdir testdir
/> chown 1002:1005 testdir
/> chmod +rwxt testdir
/> touch testdir/testfile
/> chmod 577 testdir/testfile
/> rm -f testdir/testfile
rm: cannot unlink `testdir/testfile': Permission denied
The problem is the DELETE flag in alloc_sd (and sec_acl). Corinna
has put effort into that and when I first saw that code I thought
it was an excellent idea. With the benefit of hindsight I now think it's
counterproductive. POSIX semantics do not support a delete permission
in the Windows sense. Not allowing DELETE in one spot forces us
to *automatically* add it in unlink, so it doesn't help at all from
a Cygwin user point of view.
On the other hand, if a Windows user goes out of Cygwin to remove
DELETE permission on a file, then one could argue that unlink should
fail. Some other action should be required from the user, unlink
shouldn't go out of its way to delete the file.
This is symmetric to refusing to delete a file in a non-writable
directory even though Windows allows it (err on the side of caution).
So I would propose to remove the DELETE code from alloc_sd and sec_acl
and to leave unlink as it is, in that respect.
2) Why is wincap.has_delete_on_close needed?
All Windows versions have delete_on_close capability. This is a snippet
on WinME with a file on a shared directory mounted on Win98.
152 325366 [main] rm 36050599 unlink: _unlink (e:\xx)
6422 331788 [main] rm 36050599 unlink: 1 = CloseHandle (0xCC)
1237 333025 [main] rm 36050599 unlink: CreateFile (FILE_FLAG_DELETE_ON_CLOSE) succeeded
158 333183 [main] rm 36050599 unlink: 0 = unlink (/e/xx)
However Win95 does not have FILE_SHARE_DELETE, so if the file is already opened
the CreateFile fails (and wincap.has_delete_on_close won't be looked up).
Is there reason to believe that a file won't be deleted if the CreateFile succeeds?
It would violate MS semantics. I couldn't create such a case, but I don't have
access to many types of shared drive. Perhaps the test after the CloseHandle could be
if (win32_name.isremote () && GetFileAttributes (win32_name) != INVALID_FILE_ATTRIBUTES)
then handle CreateFile (FILE_FLAG_DELETE_ON_CLOSE) failed
3) I don't understand why there are so many SetFileAttributes after CreateFile
succeeds. If the file will be deleted, its attributes are don't care. If it won't,
then we undo twice what we just did before the CreateFile.
Also it's an easy test to decide if the SetFileAttribute before CreateFile is needed.
Pierre
From cygwin-developers-return-6505-cgf=redhat.com@nowhere.com Mon Mar 10 10:59:24 2003
Date: Mon, 10 Mar 2003 16:58:55 +0100
From: "Corinna Vinschen"
To: cygwin-developers
Subject: Re: unlink
Message-ID: <20030310155855.GB1193@cygbert.vinschen.de>
Reply-To: cygwin-developers
Mail-Followup-To: "cygwin-developers" <cygwin-developers>
References: <3E6CB0FA.2312CCD0@ieee.org>
In-Reply-To: <3E6CB0FA.2312CCD0@ieee.org>
User-Agent: Mutt/1.4i
Status: RO
Content-Length: 3034
Lines: 79
On Mon, Mar 10, 2003 at 10:36:26AM -0500, Pierre A. Humblet wrote:
> So I would propose to remove the DELETE code from alloc_sd and sec_acl
> and to leave unlink as it is, in that respect.
Like this?
Index: sec_acl.cc
===================================================================
RCS file: /cvs/src/src/winsup/cygwin/sec_acl.cc,v
retrieving revision 1.29
diff -p -u -r1.29 sec_acl.cc
--- sec_acl.cc 9 Mar 2003 20:31:07 -0000 1.29
+++ sec_acl.cc 10 Mar 2003 15:52:35 -0000
@@ -119,19 +119,13 @@ setacl (const char *file, int nentries,
DWORD allow;
/* Owner has more standard rights set. */
if ((aclbufp[i].a_type & ~ACL_DEFAULT) == USER_OBJ)
- allow = (STANDARD_RIGHTS_ALL & ~DELETE)
- | FILE_WRITE_ATTRIBUTES | FILE_WRITE_EA;
+ allow = STANDARD_RIGHTS_ALL | FILE_WRITE_ATTRIBUTES | FILE_WRITE_EA;
else
allow = STANDARD_RIGHTS_READ | FILE_READ_ATTRIBUTES | FILE_READ_EA;
if (aclbufp[i].a_perm & S_IROTH)
allow |= FILE_GENERIC_READ;
if (aclbufp[i].a_perm & S_IWOTH)
- {
- allow |= STANDARD_RIGHTS_WRITE | FILE_GENERIC_WRITE;
- /* Owner gets DELETE right, too. */
- if ((aclbufp[i].a_type & ~ACL_DEFAULT) == USER_OBJ)
- allow |= DELETE;
- }
+ allow |= STANDARD_RIGHTS_WRITE | FILE_GENERIC_WRITE;
if (aclbufp[i].a_perm & S_IXOTH)
allow |= FILE_GENERIC_EXECUTE;
if ((aclbufp[i].a_perm & (S_IWOTH | S_IXOTH)) == (S_IWOTH | S_IXOTH))
Index: security.cc
===================================================================
RCS file: /cvs/src/src/winsup/cygwin/security.cc,v
retrieving revision 1.139
diff -p -u -r1.139 security.cc
--- security.cc 9 Mar 2003 20:31:07 -0000 1.139
+++ security.cc 10 Mar 2003 15:52:35 -0000
@@ -1644,12 +1644,12 @@ alloc_sd (__uid32_t uid, __gid32_t gid,
int ace_off = 0;
/* Construct allow attribute for owner. */
- DWORD owner_allow = (STANDARD_RIGHTS_ALL & ~DELETE)
+ DWORD owner_allow = STANDARD_RIGHTS_ALL
| FILE_WRITE_ATTRIBUTES | FILE_WRITE_EA;
if (attribute & S_IRUSR)
owner_allow |= FILE_GENERIC_READ;
if (attribute & S_IWUSR)
- owner_allow |= FILE_GENERIC_WRITE | DELETE;
+ owner_allow |= FILE_GENERIC_WRITE;
if (attribute & S_IXUSR)
owner_allow |= FILE_GENERIC_EXECUTE;
if ((attribute & (S_IFDIR | S_IWUSR | S_IXUSR))
> 2) Why is wincap.has_delete_on_close needed?
Hmm, I can't answer this one. Historical reasons? Bad experience?
> 3) I don't understand why there are so many SetFileAttributes after CreateFile
> succeeds. If the file will be deleted, its attributes are don't care. If it won't,
> then we undo twice what we just did before the CreateFile.
> Also it's an easy test to decide if the SetFileAttribute before CreateFile is needed.
Chris and I are through this attribute hell this weekend. To make it
short: If the file is hardlinked more than once, the other links would
miss an attribute after removing this one link.
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Developer
Red Hat, Inc.
From cygwin-developers-return-6508-cgf=redhat.com@nowhere.com Mon Mar 10 11:18:16 2003
Message-ID: <3E6CBB60.FAC2C62D@ieee.org>
Date: Mon, 10 Mar 2003 11:20:48 -0500
From: "Pierre A. Humblet"
To: cygwin-developers
Subject: Re: unlink
References: <3E6CB0FA.2312CCD0@ieee.org> <20030310155855.GB1193@cygbert.vinschen.de>
Status: RO
Content-Length: 1060
Lines: 29
Corinna Vinschen wrote:
>
> On Mon, Mar 10, 2003 at 10:36:26AM -0500, Pierre A. Humblet wrote:
> > So I would propose to remove the DELETE code from alloc_sd and sec_acl
> > and to leave unlink as it is, in that respect.
>
> Like this?
Wow. Yes.
> > 2) Why is wincap.has_delete_on_close needed?
>
> Hmm, I can't answer this one. Historical reasons? Bad experience?
>
> > 3) I don't understand why there are so many SetFileAttributes after CreateFile
> > succeeds. If the file will be deleted, its attributes are don't care. If it won't,
> > then we undo twice what we just did before the CreateFile.
> > Also it's an easy test to decide if the SetFileAttribute before CreateFile is needed.
>
> Chris and I are through this attribute hell this weekend. To make it
> short: If the file is hardlinked more than once, the other links would
> miss an attribute after removing this one link.
I think I see. When a file is hard linked, SetFileAttributes affects *all* links.
Correct?
Still, it's easy to decide if the calls are needed.
Pierre
From cygwin-developers-return-6507-cgf=redhat.com@nowhere.com Mon Mar 10 11:17:25 2003
Date: Mon, 10 Mar 2003 11:16:28 -0500
From: "Christopher Faylor"
To: cygwin-developers
Subject: Re: unlink
Message-ID: <20030310161628.GG23549@redhat.com>
Reply-To: cygwin-developers
Mail-Followup-To: cygwin-developers
References: <3E6CB0FA.2312CCD0@ieee.org>
Content-Length: 876
Lines: 25
On Mon, Mar 10, 2003 at 10:36:26AM -0500, Pierre A. Humblet wrote:
>Chris,
>
>It's a great idea to use FILE_FLAG_DELETE_ON_CLOSE for unlink,
>but a few bells rang when I read the code.
AFAIK, I didn't add anything here. I just changed the order. unlink
has always used FILE_FLAG_DELETE_ON_CLOSE.
>2) Why is wincap.has_delete_on_close needed?
>
>All Windows versions have delete_on_close capability. This is a snippet
>on WinME with a file on a shared directory mounted on Win98.
It doesn't work quite right on Windows 98. I tested it extensively a
while ago and it seemed unreliable. Maybe it is ok in the current incarnation.
I guess I could remove that test and see if anyone hollers.
>3) I don't understand why there are so many SetFileAttributes after CreateFile
> succeeds. If the file will be deleted, its attributes are don't care.
Think 'hard links'.
cgf
[-- Attachment #3: Type: text/plain, Size: 218 bytes --]
--
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/
^ permalink raw reply [flat|nested] 14+ messages in thread
* What Linux version corresponds to a specific cygwin version?
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 ` 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
1 sibling, 2 replies; 14+ messages in thread
From: Uwe Galle @ 2003-10-07 16:18 UTC (permalink / raw)
To: cygwin
Hi,
after some research this question remained unresolved, that's why I want to
post it to the list.
Some applications, e.g. C-Kermit 8.0
(http://www.columbia.edu/kermit/ck80binaries.html#linux), offer a variety of
binary versions, e.g. Red Hat 7.0, Red Hat 7.1, 7.2, 7.3, 8.0, 9, AS2.1 and
much more. The question is: What version I have to download for a certain
cygwin version?
uname shows for the latest cygwin version CYGWIN_NT-5.1.
cygcheck -s shows as cygwin dll version 1.5.5.
Are there any rules how to map this version information to a certain Linux
version? I think I cannot rely on the compatibility with the latest Red Hat
version - also because of the fact that Red Hat doesn't offer only one
version ...
Thank you for your help.
Uwe Galle
--
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/
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: What Linux version corresponds to a specific cygwin version?
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
1 sibling, 0 replies; 14+ messages in thread
From: Ronald Landheer-Cieslak @ 2003-10-07 17:37 UTC (permalink / raw)
To: cygwin
First: Cygwin != Linux
On Tue, Oct 07, 2003 at 06:03:05PM +0200, Uwe Galle wrote:
> after some research this question remained unresolved, that's why I want to
> post it to the list.
>
> Some applications, e.g. C-Kermit 8.0
> (http://www.columbia.edu/kermit/ck80binaries.html#linux), offer a variety of
> binary versions, e.g. Red Hat 7.0, Red Hat 7.1, 7.2, 7.3, 8.0, 9, AS2.1 and
> much more. The question is: What version I have to download for a certain
> cygwin version?
If the package is part of the Cygwin Net Distribution, you can download it
with http://cygwin.com/setup.exe. Please also read http://cygwin.com.
> uname shows for the latest cygwin version CYGWIN_NT-5.1.
> cygcheck -s shows as cygwin dll version 1.5.5.
>
> Are there any rules how to map this version information to a certain Linux
> version?
Cygwin != Linux.
Cygwin is a POSIX emulation layer for Windows. It is not based on Linux code,
nor is it actually anything more than a DLL with many, many features. There
is no way to "map" a Cygwin version number to a Linux version number because
* there is no relation
* the Cygwin version number (e.g. 1.5.5) is the number of the Cygwin DLL,
not the distribution (comparable with Linux-2.4.x being the version number
of the kernel).
* there is no relation
* there is no relation
> I think I cannot rely on the compatibility with the latest Red Hat
> version - also because of the fact that Red Hat doesn't offer only one
> version ...
You're talking about *distribution* versions here - there is no versioning
scheme for the Cygwin Net Distribution.
rlc
--
Statistics are no substitute for judgement.
-- Henry Clay
--
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/
^ permalink raw reply [flat|nested] 14+ messages in thread
* RE: What Linux version corresponds to a specific cygwin version?
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
1 sibling, 0 replies; 14+ messages in thread
From: Hannu E K Nevalainen @ 2003-10-07 22:01 UTC (permalink / raw)
To: ML CygWIN
> From: Uwe Galle
> Sent: Tuesday, October 07, 2003 6:03 PM
> Some applications, e.g. C-Kermit 8.0
> (http://www.columbia.edu/kermit/ck80binaries.html#linux), offer a
> variety of
> binary versions, e.g. Red Hat 7.0, Red Hat 7.1, 7.2, 7.3, 8.0, 9,
***************
You *can't* run foreign binaries using cygwin, the SOURCE for any softwre
has to be built using cygwin tools.
> AS2.1 and
> much more. The question is: What version I have to download for a certain
> cygwin version?
Easiest: Any that compiles OOTB and suits your needs.
/Hannu E K Nevalainen, B.Sc. EE - 59°16.37'N, 17°12.60'E
-- UTC+01, DST -> UTC+02 --
--END OF MESSAGE--
--
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/
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: cygwin-1.5.4-1 breaks fetchmail on Win9x (Pierre can you comment?)
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-08 1:05 ` Pierre A. Humblet
2003-10-08 1:08 ` Christopher Faylor
1 sibling, 1 reply; 14+ messages in thread
From: Pierre A. Humblet @ 2003-10-08 1:05 UTC (permalink / raw)
To: cygwin
At 11:32 AM 10/7/2003 -0400, Christopher Faylor wrote:
>On Tue, Oct 07, 2003 at 09:49:14AM -0400, Christopher Faylor wrote:
>>On Tue, Oct 07, 2003 at 09:19:05AM -0400, Jason Tishler wrote:
>>>On Mon, Oct 06, 2003 at 10:58:37PM -0400, Christopher Faylor wrote:
>>>>On Mon, Oct 06, 2003 at 10:13:00PM -0400, Jason Tishler wrote:
>>>>>BTW, there seemed to be some gyration regarding this section of
>>>>>unlink() during that time period:
>>>>
>>>>...which might be illuminated by reading the archives, I suspect...
>>>
>>>I tried searching the archives via Google and Cygwin's mailing list
>>>search engine, but came up empty. Would you be willing to enlighten
>>>me?
>>
>>Actually, I am trying not to have to do the search myself. I recall
>>that there was a discussion about this with Pierre which caused the
>>change to take place. It might have been in the cygwin-developers
>>list.
Hmm, I remember investigating what's happening when a Win9X mounts a
file system on NT and there are hard links..
This is what I see on Win98/Me:
- DELETE_ON_CLOSE works if the file is not yet opened.
- If it is opened for writing, CreateFile (DELETE_ON_CLOSE) fails and the
file is eventually put on the delete queue, at least if it is local.
Why not if it's remote?
- However if the file is opened for reading, then CreateFile (DELETE_ON_CLOSE)
succeeds, CloseHandle returns 1, but the file is not deleted.
That's the case that Mark Ord examined. It's an MS bug, the documentation
states that CreateFile should fail.
So there is indeed a current problem. Until the next Cygwin release fetchmail
could possibly patch things up by opening the file for writing.
Pierre
--
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/
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: cygwin-1.5.4-1 breaks fetchmail on Win9x (Pierre can you comment?)
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
0 siblings, 0 replies; 14+ messages in thread
From: Christopher Faylor @ 2003-10-08 1:08 UTC (permalink / raw)
To: cygwin
On Tue, Oct 07, 2003 at 08:38:08PM -0400, Pierre A. Humblet wrote:
>This is what I see on Win98/Me:
>- DELETE_ON_CLOSE works if the file is not yet opened.
>- If it is opened for writing, CreateFile (DELETE_ON_CLOSE) fails and the
> file is eventually put on the delete queue, at least if it is local.
> Why not if it's remote?
You can't assume that an access denied on a remote share means "sharing
violation". If you put something into the delete queue that can't ever
be deleted, then, well... If you do get a sharing violation on a remote
share then it should be put into the delete queue.
cgf
--
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/
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: cygwin-1.5.4-1 breaks fetchmail on Win9x
2003-10-05 3:16 cygwin-1.5.4-1 breaks fetchmail on Win9x Mark Ord
2003-10-07 2:58 ` Jason Tishler
@ 2003-10-10 13:17 ` Jason Tishler
1 sibling, 0 replies; 14+ messages in thread
From: Jason Tishler @ 2003-10-10 13:17 UTC (permalink / raw)
To: cygwin
Mark,
On Sun, Oct 05, 2003 at 11:45:20AM +1000, Mark Ord wrote:
> 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.
AFAICT, the problem has been corrected in CVS:
http://cygwin.com/ml/cygwin-cvs/2003-q4/msg00025.html
Please test against Cygwin CVS or the next snapshot (which has not been
generated yet) and report back to the list.
Thanks,
Jason
--
PGP/GPG Key: http://www.tishler.net/jason/pubkey.asc or key servers
Fingerprint: 7A73 1405 7F2B E669 C19D 8784 1AFD E4CC ECF4 8EF6
--
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/
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: cygwin-1.5.4-1 breaks fetchmail on Win9x
2003-09-27 4:21 Mark Ord
@ 2003-09-29 12:03 ` Jason Tishler
0 siblings, 0 replies; 14+ messages in thread
From: Jason Tishler @ 2003-09-29 12:03 UTC (permalink / raw)
To: cygwin
Mark,
On Sat, Sep 27, 2003 at 01:58:39PM +1000, Mark Ord wrote:
> I then updated to cygwin-1.5.4-1, which seems to break fetchmail.
> Fetchmail complains about not being able to create the lock file, but
> I believe the issue is actually with *removing* the stale lock file
> (it doesn't happen):
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?
> [snip]
>
> 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?
Jason
--
PGP/GPG Key: http://www.tishler.net/jason/pubkey.asc or key servers
Fingerprint: 7A73 1405 7F2B E669 C19D 8784 1AFD E4CC ECF4 8EF6
--
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/
^ permalink raw reply [flat|nested] 14+ messages in thread
* cygwin-1.5.4-1 breaks fetchmail on Win9x
@ 2003-09-27 4:21 Mark Ord
2003-09-29 12:03 ` Jason Tishler
0 siblings, 1 reply; 14+ messages in thread
From: Mark Ord @ 2003-09-27 4:21 UTC (permalink / raw)
To: cygwin
[-- Attachment #1: Type: text/plain, Size: 2081 bytes --]
cygwin-1.3.22-1 + fetchmail 6.2.2-1:
This was working fine. I then updated to cygwin-1.5.4-1, which seems to break
fetchmail. Fetchmail complains about not being able to create the lock file,
but I believe the issue is actually with *removing* the stale lock file
(it doesn't happen):
8:05pm [ord@scholars ~] > ls -l .fetchmail.pid
-rw-r--r-- 1 ord all 10 Sep 23 15:38 .fetchmail.pid
8:10pm [ord@scholars ~] > fetchmail -d0
fetchmail: removing stale lockfile
fetchmail: lock creation failed.
8:10pm [ord@scholars ~] > ls -l .fetchmail.pid
-rw-r--r-- 1 ord all 10 Sep 23 15:38 .fetchmail.pid
8:10pm [ord@scholars ~] >
I then updated to cygwin-1.5.5-1, to fix the ^Z problem in 1.5.4-1,
yet the fetchmail problem remained. Also updated to the latest fetchmail
(6.2.4-1), however that behaves the same. (Seems to be an issue with
cygwin-1.5.5-1 vs. cygwin-1.3.22-1).
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 ,
though I don't normally use fetchmail on my XP box, so milage may vary from
my quick test on XP:
1:21pm [ord@chimera ~] 2 0 > ls -l .fetchmail.pid
-rw------- 1 ord None 8 Sep 27 13:21 .fetchmail.pid
1:22pm [ord@chimera ~] 2 0 > fetchmail -d0
fetchmail: removing stale lockfile
[...fetchmail run output snipped..]
The obvious hack that I am using currently is to delete .fetchmail.pid
in /etc/rc on Win98, which is satisfactory for me, however I thought it
worthwhile reporting the problem.
I've searched the archives, and found no other references to this problem,
which hopefully just means I'm the first to report it and not that I'm missing
anything (apologies if so).
cygcheck -s -v -r > cygcheck.out follows.
Mark.
--
Mark Ord | I tried my best, tried to forget,
Melbourne, Australia | that you're a bad habit, just like a
mailto://ord@alphalink.com.au | cigarette.
http://www.alphalink.com.au/~ord/home/ | "Spark" - Jesse Valenzuela -
[-- Attachment #2: cygcheck.out --]
[-- Type: text/plain, Size: 23842 bytes --]
Cygwin Win95/NT Configuration Diagnostics
Current System Time: Sat Sep 27 13:25:56 2003
Windows 98 SE Ver 4.10 Build 2222
Path: .\
C:\cygwin\home\ord\scripts
C:\cygwin\home\ord\bin\hostname
C:\cygwin\home\ord\bin
C:\cygwin\usr\local\bin
C:\cygwin\bin
C:\cygwin\bin
c:\WINDOWS
c:\WINDOWS\COMMAND
C:\cygwin\bin
C:\cygwin\OPT\BIND\BIN
C:\cygwin\usr\X11R6\bin
C:\cygwin\usr\sbin
C:\cygwin\opt\bind\sbin
Output from C:\cygwin\bin\id.exe (nontsec)
UID: 29815(ord) GID: 544(all)
544(all)
Output from C:\cygwin\bin\id.exe (ntsec)
UID: 29815(ord) GID: 544(all)
544(all)
SysDir: C:\WINDOWS\SYSTEM
WinDir: C:\WINDOWS
HOME = `C:\cygwin\home\ord'
MAKE_MODE = `unix'
PWD = `/home/ord'
USER = `ord'
CFG_FILES = `/home/ord/.configuration_files'
CMDLINE = `WIN'
COMSPEC = `C:\WINDOWS\COMMAND.COM'
CONSOLE = `/dev/null'
DEF_MAKEFILE = `/cygdrive/m/dev/C/makfiles/defs.mak'
DIRCMD = `/w /O:N'
DISPLAY = `chimera:0'
GROUP = `all'
HOMEDRIVE = `C:'
HOMEPATH = `\cygwin\home\ord'
HOST = `scholars'
HOSTTYPE = `i386'
INIT_VERSION = `sysvinit-2.84'
LOGNAME = `ord'
LS_COLORS = `no=00:fi=00:di=01;34:ln=01;31:pi=40;33:so=01;35:bd=40;33;01:cd=40;33;01:or=40;31;01:ex=00;31:'
LYNX_CFG = `/home/ord/.configuration_files/lynx.cfg'
MACHTYPE = `i386'
MAIL = `/var/spool/mail/ord'
MAIL_FOLDERS = `/var/spool/mail/ord /home/ord/Mail/gin_blossomsLoW_moderate /home/ord/Mail/inbox.lv'
MAKEFILEPATH = `/cygdrive/m/dev/C/makfiles'
MANPATH = `:/usr/ssl/man'
MYENVSET = `'
NNTPSERVER = `news.alphalink.com.au'
OSTYPE = `posix'
PREVLEVEL = `N'
PRINTER = `lpt1'
PROFILED = `/home/ord/profile.d'
PROMPT = `$p$g'
REMOTEHOST = `chimera.home'
RUNLEVEL = `S'
SCRIPTS = `/home/ord/scripts'
SHELL = `/bin/tcsh'
SHLVL = `1'
SSH_CLIENT = `192.168.0.2 4595 22'
SSH_CONNECTION = `192.168.0.2 4595 192.168.0.1 22'
SSH_TTY = `/dev/tty0'
TERM = `screen'
TZ = `EST-10'
VENDOR = `intel'
WINBOOTDIR = `C:\WINDOWS'
WINDIR = `C:\WINDOWS'
HKEY_CURRENT_USER\Software\Cygnus Solutions
HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin
HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\mounts v2
HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\Program Options
HKEY_LOCAL_MACHINE\Software\Cygnus Solutions
HKEY_LOCAL_MACHINE\Software\Cygnus Solutions\Cygwin
HKEY_LOCAL_MACHINE\Software\Cygnus Solutions\Cygwin\mounts v2
(default) = 0x00000022
cygdrive prefix = `/cygdrive'
HKEY_LOCAL_MACHINE\Software\Cygnus Solutions\Cygwin\mounts v2\/usr/X11R6/lib/X11/fonts
(default) = `C:\cygwin\usr\X11R6\lib\X11\fonts'
flags = 0x0000000a
HKEY_LOCAL_MACHINE\Software\Cygnus Solutions\Cygwin\mounts v2\/
(default) = `C:\cygwin'
flags = 0x0000000a
HKEY_LOCAL_MACHINE\Software\Cygnus Solutions\Cygwin\mounts v2\/usr/bin
(default) = `C:\cygwin/bin'
flags = 0x0000000a
HKEY_LOCAL_MACHINE\Software\Cygnus Solutions\Cygwin\mounts v2\/usr/lib
(default) = `C:\cygwin/lib'
flags = 0x0000000a
HKEY_LOCAL_MACHINE\Software\Cygnus Solutions\Cygwin\Program Options
a: fd N/A N/A
c: hd FAT32 1031Mb 97% CP UN
d: hd FAT32 1273Mb 88% CP UN
e: cd N/A N/A
f: net NTFS 76308Mb 53% CP CS UN PA FC Local Disk
C:\cygwin\usr\X11R6\lib\X11\fonts /usr/X11R6/lib/X11/fonts system binmode
C:\cygwin / system binmode
C:\cygwin/bin /usr/bin system binmode
C:\cygwin/lib /usr/lib system binmode
. /cygdrive system binmode,cygdrive
Found: C:\cygwin\bin\awk.exe
Found: C:\cygwin\bin\bash.exe
Found: C:\cygwin\bin\cat.exe
Found: C:\cygwin\bin\cp.exe
Found: C:\cygwin\bin\cpp.exe
Found: C:\cygwin\bin\find.exe
Found: c:\WINDOWS\COMMAND\find.exe
Warning: C:\cygwin\bin\find.exe hides c:\WINDOWS\COMMAND\find.exe
Found: C:\cygwin\bin\gcc.exe
Found: C:\cygwin\bin\gdb.exe
Found: C:\cygwin\bin\grep.exe
Found: C:\cygwin\bin\ld.exe
Found: C:\cygwin\bin\ls.exe
Found: C:\cygwin\bin\make.exe
Found: C:\cygwin\bin\mv.exe
Found: C:\cygwin\bin\rm.exe
Found: C:\cygwin\bin\sed.exe
Found: C:\cygwin\bin\sh.exe
Found: C:\cygwin\bin\tar.exe
306k 2002/04/27 C:\cygwin\bin\cyghttpd.dll - os=4.0 img=1.0 sys=4.0
"cyghttpd.dll" v0.0 ts=2002/4/27 23:23
551k 2003/04/02 C:\cygwin\bin\cygcurl-2.dll - os=4.0 img=1.0 sys=4.0
"cygcurl-2.dll" v0.0 ts=2003/4/3 7:09
63k 2003/04/11 C:\cygwin\bin\cygpcre.dll - os=4.0 img=1.0 sys=4.0
"cygpcre.dll" v0.0 ts=2003/4/11 18:31
61k 2003/04/11 C:\cygwin\bin\cygpcreposix.dll - os=4.0 img=1.0 sys=4.0
"cygpcreposix.dll" v0.0 ts=2003/4/11 18:31
61k 2003/08/09 C:\cygwin\bin\cygbz2-1.dll - os=4.0 img=1.0 sys=4.0
"cygbz2-1.dll" v0.0 ts=2003/8/9 16:35
14k 2003/08/10 C:\cygwin\bin\cygcharset-1.dll - os=4.0 img=1.0 sys=4.0
"cygcharset-1.dll" v0.0 ts=2003/8/11 6:57
958k 2003/08/10 C:\cygwin\bin\cygiconv-2.dll - os=4.0 img=1.0 sys=4.0
"cygiconv-2.dll" v0.0 ts=2003/8/11 6:57
37k 2003/08/10 C:\cygwin\bin\cygintl-2.dll - os=4.0 img=1.0 sys=4.0
"cygintl-2.dll" v0.0 ts=2003/8/11 7:50
60k 2003/09/17 C:\cygwin\bin\cygkpathsea-3.dll - os=4.0 img=1.0 sys=4.0
"cygkpathsea-3.dll" v0.0 ts=2003/9/18 2:37
32k 2003/08/18 C:\cygwin\bin\cygltdl-3.dll - os=4.0 img=1.0 sys=4.0
"cygltdl-3.dll" v0.0 ts=2003/8/18 15:35
21k 2001/06/20 C:\cygwin\bin\cygintl.dll - os=4.0 img=1.0 sys=4.0
"cygintl.dll" v0.0 ts=2001/6/21 3:09
22k 2001/12/13 C:\cygwin\bin\cygintl-1.dll - os=4.0 img=1.0 sys=4.0
"cygintl-1.dll" v0.0 ts=2001/12/13 19:28
48k 2003/08/09 C:\cygwin\bin\cygform7.dll - os=4.0 img=1.0 sys=4.0
"cygform7.dll" v0.0 ts=2003/8/9 19:25
29k 2003/08/09 C:\cygwin\bin\cygmenu7.dll - os=4.0 img=1.0 sys=4.0
"cygmenu7.dll" v0.0 ts=2003/8/9 19:25
224k 2003/08/09 C:\cygwin\bin\cygncurses7.dll - os=4.0 img=1.0 sys=4.0
"cygncurses7.dll" v0.0 ts=2003/8/9 19:24
45k 2001/04/25 C:\cygwin\bin\cygform5.dll - os=4.0 img=1.0 sys=4.0
"cygform5.dll" v0.0 ts=2001/4/25 15:28
26k 2001/04/25 C:\cygwin\bin\cygmenu5.dll - os=4.0 img=1.0 sys=4.0
"cygmenu5.dll" v0.0 ts=2001/4/25 15:27
156k 2001/04/25 C:\cygwin\bin\cygncurses++5.dll - os=4.0 img=1.0 sys=4.0
"cygncurses++5.dll" v0.0 ts=2001/4/25 15:29
226k 2001/04/25 C:\cygwin\bin\cygncurses5.dll - os=4.0 img=1.0 sys=4.0
"cygncurses5.dll" v0.0 ts=2001/4/25 15:17
15k 2001/04/25 C:\cygwin\bin\cygpanel5.dll - os=4.0 img=1.0 sys=4.0
"cygpanel5.dll" v0.0 ts=2001/4/25 15:27
35k 2002/01/09 C:\cygwin\bin\cygform6.dll - os=4.0 img=1.0 sys=4.0
"cygform6.dll" v0.0 ts=2002/1/9 16:03
20k 2002/01/09 C:\cygwin\bin\cygmenu6.dll - os=4.0 img=1.0 sys=4.0
"cygmenu6.dll" v0.0 ts=2002/1/9 16:03
175k 2002/01/09 C:\cygwin\bin\cygncurses++6.dll - os=4.0 img=1.0 sys=4.0
"cygncurses++6.dll" v0.0 ts=2002/1/9 16:03
202k 2002/01/09 C:\cygwin\bin\cygncurses6.dll - os=4.0 img=1.0 sys=4.0
"cygncurses6.dll" v0.0 ts=2002/1/9 16:03
12k 2002/01/09 C:\cygwin\bin\cygpanel6.dll - os=4.0 img=1.0 sys=4.0
"cygpanel6.dll" v0.0 ts=2002/1/9 16:03
19k 2003/08/09 C:\cygwin\bin\cygpanel7.dll - os=4.0 img=1.0 sys=4.0
"cygpanel7.dll" v0.0 ts=2003/8/9 19:24
67k 2003/09/10 C:\cygwin\bin\cygpcre-0.dll - os=4.0 img=1.0 sys=4.0
"cygpcre-0.dll" v0.0 ts=2003/9/11 0:25
15k 2003/09/10 C:\cygwin\bin\cygpcreposix-0.dll - os=4.0 img=1.0 sys=4.0
"cygpcreposix-0.dll" v0.0 ts=2003/9/11 0:25
173k 2003/08/10 C:\cygwin\bin\cygpng12.dll - os=4.0 img=1.0 sys=4.0
"cygpng12.dll" v0.0 ts=2003/8/11 8:35
22k 2002/06/09 C:\cygwin\bin\cygpopt-0.dll - os=4.0 img=1.0 sys=4.0
"cygpopt-0.dll" v0.0 ts=2002/6/9 15:45
17k 2001/06/28 C:\cygwin\bin\cyghistory4.dll - os=4.0 img=1.0 sys=4.0
"cyghistory4.dll" v0.0 ts=2001/1/7 14:34
108k 2001/06/28 C:\cygwin\bin\cygreadline4.dll - os=4.0 img=1.0 sys=4.0
"cygreadline4.dll" v0.0 ts=2001/1/7 14:34
29k 2003/08/10 C:\cygwin\bin\cyghistory5.dll - os=4.0 img=1.0 sys=4.0
"cyghistory5.dll" v0.0 ts=2003/8/11 9:16
148k 2003/08/10 C:\cygwin\bin\cygreadline5.dll - os=4.0 img=1.0 sys=4.0
"cygreadline5.dll" v0.0 ts=2003/8/11 9:16
2689k 2002/11/16 C:\cygwin\bin\cygxerces-c21.dll - os=4.0 img=1.0 sys=4.0
"cygxerces-c21.dll" v0.0 ts=2002/11/16 14:07
19k 2003/03/22 C:\cygwin\bin\cyggdbm.dll - os=4.0 img=1.0 sys=4.0
"cyggdbm.dll" v0.0 ts=2002/2/20 13:05
28k 2003/07/20 C:\cygwin\bin\cyggdbm-3.dll - os=4.0 img=1.0 sys=4.0
"cyggdbm-3.dll" v0.0 ts=2003/7/20 17:58
15k 2003/07/20 C:\cygwin\bin\cyggdbm_compat-3.dll - os=4.0 img=1.0 sys=4.0
"cyggdbm_compat-3.dll" v0.0 ts=2003/7/20 18:00
380k 2002/07/24 C:\cygwin\bin\cygdb-3.1.dll - os=4.0 img=1.0 sys=4.0
"cygdb-3.1.dll" v0.0 ts=2002/7/25 2:24
487k 2002/07/24 C:\cygwin\bin\cygdb_cxx-3.1.dll - os=4.0 img=1.0 sys=4.0
"cygdb_cxx-3.1.dll" v0.0 ts=2002/7/25 2:25
1100k 2003/08/29 C:\cygwin\bin\cygperl5_8_0.dll - os=4.0 img=1.0 sys=4.0
"cygperl5_8_0.dll" v0.0 ts=2003/8/29 20:20
645k 2003/04/11 C:\cygwin\bin\cygcrypto.dll - os=4.0 img=1.0 sys=4.0
"cygcrypto.dll" v0.0 ts=2003/4/11 20:37
165k 2003/04/11 C:\cygwin\bin\cygssl.dll - os=4.0 img=1.0 sys=4.0
"cygssl.dll" v0.0 ts=2003/4/11 20:37
47k 2003/03/09 C:\cygwin\bin\cygjbig1.dll - os=4.0 img=1.0 sys=4.0
"cygjbig1.dll" v0.0 ts=2003/3/10 7:30
54k 2002/01/27 C:\cygwin\bin\cygbz21.0.dll - os=4.0 img=1.0 sys=4.0
"cygbz21.0.dll" v0.0 ts=2002/1/27 11:07
326k 2002/06/26 C:\cygwin\bin\cygdb2.dll - os=4.0 img=1.0 sys=4.0
"cygdb2.dll" v0.0 ts=2002/6/27 3:48
945k 2003/06/18 C:\cygwin\bin\CYGICO~1.DLL - os=4.0 img=1.0 sys=4.0
"cygiconv-2.dll" v0.0 ts=2003/6/18 13:08
168k 2003/02/23 C:\cygwin\bin\cygpng10.dll - os=4.0 img=1.0 sys=4.0
"cygpng10.dll" v0.0 ts=2003/2/24 9:02
170k 2002/01/21 C:\cygwin\bin\cygpng2.dll - os=4.0 img=1.0 sys=4.0
"cygpng2.dll" v0.0 ts=2002/1/21 11:05
25k 2002/07/14 C:\cygwin\bin\cygungif-4.dll - os=4.0 img=1.0 sys=4.0
"cygungif-4.dll" v0.0 ts=2002/7/15 0:58
2984k 2003/02/07 C:\cygwin\bin\cygxerces-c22.dll - os=4.0 img=1.0 sys=4.0
"cygxerces-c22.dll" v0.0 ts=2003/2/8 4:50
849k 2003/08/11 C:\cygwin\bin\cygcrypto-0.9.7.dll - os=4.0 img=1.0 sys=4.0
"cygcrypto-0.9.7.dll" v0.0 ts=2003/8/11 18:58
176k 2003/08/11 C:\cygwin\bin\cygssl-0.9.7.dll - os=4.0 img=1.0 sys=4.0
"cygssl-0.9.7.dll" v0.0 ts=2003/8/11 18:58
60k 2003/08/09 C:\cygwin\bin\cygz.dll - os=4.0 img=1.0 sys=4.0
"cygz.dll" v0.0 ts=2003/8/9 16:28
132k 2003/07/12 C:\cygwin\bin\cygexpat-0.dll - os=4.0 img=1.0 sys=4.0
"cygexpat-0.dll" v0.0 ts=2003/7/12 21:33
30k 2003/08/11 C:\cygwin\bin\cyggdbm-4.dll - os=4.0 img=1.0 sys=4.0
"cyggdbm-4.dll" v0.0 ts=2003/8/11 12:12
15k 2003/08/11 C:\cygwin\bin\cyggdbm_compat-4.dll - os=4.0 img=1.0 sys=4.0
"cyggdbm_compat-4.dll" v0.0 ts=2003/8/11 12:13
12k 2003/08/10 C:\cygwin\bin\cyggettextpo-0.dll - os=4.0 img=1.0 sys=4.0
"cyggettextpo-0.dll" v0.0 ts=2003/8/11 8:11
69k 2003/08/10 C:\cygwin\bin\cyggettextlib-0-12-1.dll - os=4.0 img=1.0 sys=4.0
"cyggettextlib-0-12-1.dll" v0.0 ts=2003/8/11 8:10
134k 2003/08/10 C:\cygwin\bin\cyggettextsrc-0-12-1.dll - os=4.0 img=1.0 sys=4.0
"cyggettextsrc-0-12-1.dll" v0.0 ts=2003/8/11 8:10
949k 2003/09/20 C:\cygwin\bin\cygwin1.dll - os=4.0 img=1.0 sys=4.0
"cygwin1.dll" v0.0 ts=2003/9/21 6:31
Cygwin DLL version info:
DLL version: 1.5.5
DLL epoch: 19
DLL bad signal mask: 19005
DLL old termios: 5
DLL malloc env: 28
API major: 0
API minor: 94
Shared data: 3
DLL identifier: cygwin1
Mount registry: 2
Cygnus registry name: Cygnus Solutions
Cygwin registry name: Cygwin
Program options name: Program Options
Cygwin mount registry name: mounts v2
Cygdrive flags: cygdrive flags
Cygdrive prefix: cygdrive prefix
Cygdrive default prefix:
Build date: Sat Sep 20 16:31:15 EDT 2003
CVS tag: cr-0x9b
Shared id: cygwin1S3
1539k 2003/06/16 C:\cygwin\OPT\BIND\BIN\cygdns-8.dll - os=4.0 img=1.0 sys=4.0
"cygdns-8.dll" v0.0 ts=2003/6/16 22:34
321k 2003/06/16 C:\cygwin\OPT\BIND\BIN\cygisc-4.dll - os=4.0 img=1.0 sys=4.0
"cygisc-4.dll" v0.0 ts=2003/6/16 19:38
105k 2003/06/16 C:\cygwin\OPT\BIND\BIN\cygisccc-0.dll - os=4.0 img=1.0 sys=4.0
"cygisccc-0.dll" v0.0 ts=2003/6/16 22:32
293k 2003/06/16 C:\cygwin\OPT\BIND\BIN\cygisccfg-0.dll - os=4.0 img=1.0 sys=4.0
"cygisccfg-0.dll" v0.0 ts=2003/6/16 22:35
136k 2003/06/16 C:\cygwin\OPT\BIND\BIN\cyglwres-1.dll - os=4.0 img=1.0 sys=4.0
"cyglwres-1.dll" v0.0 ts=2003/6/16 21:01
41k 2002/05/14 C:\cygwin\usr\X11R6\bin\cygPropList-0.dll - os=4.0 img=1.0 sys=4.0
"cygPropList-0.dll" v0.0 ts=2002/5/14 13:13
673k 2003/09/20 C:\cygwin\usr\X11R6\bin\cygdps-1.dll - os=4.0 img=1.0 sys=4.0
"cygdps-1.dll" v0.0 ts=2003/9/20 16:37
184k 2003/09/20 C:\cygwin\usr\X11R6\bin\cygdpstk-1.dll - os=4.0 img=1.0 sys=4.0
"cygdpstk-1.dll" v0.0 ts=2003/9/20 16:37
176k 2003/09/20 C:\cygwin\usr\X11R6\bin\cygfontconfig-1.dll - os=4.0 img=1.0 sys=4.0
"cygfontconfig-1.dll" v0.0 ts=2003/9/20 16:38
340k 2003/09/20 C:\cygwin\usr\X11R6\bin\cygfreetype-9.dll - os=4.0 img=1.0 sys=4.0
"cygfreetype-9.dll" v0.0 ts=2003/9/20 16:38
520k 2003/09/20 C:\cygwin\usr\X11R6\bin\cygGL-1.dll - os=4.0 img=1.0 sys=4.0
"cygGL-1.dll" v0.0 ts=2003/9/20 16:35
593k 2003/09/20 C:\cygwin\usr\X11R6\bin\cygGLU-1.dll - os=4.0 img=1.0 sys=4.0
"cygGLU-1.dll" v0.0 ts=2003/9/20 16:36
111k 2003/09/20 C:\cygwin\usr\X11R6\bin\cygICE-6.dll - os=4.0 img=1.0 sys=4.0
"cygICE-6.dll" v0.0 ts=2003/9/20 16:28
25k 2003/09/20 C:\cygwin\usr\X11R6\bin\cygoldX-6.dll - os=4.0 img=1.0 sys=4.0
"cygoldX-6.dll" v0.0 ts=2003/9/20 16:27
1511k 2003/09/20 C:\cygwin\usr\X11R6\bin\cygOSMesa-4.dll - os=4.0 img=1.0 sys=4.0
"cygOSMesa-4.dll" v0.0 ts=2003/9/20 16:35
40k 2003/09/20 C:\cygwin\usr\X11R6\bin\cygpsres-1.dll - os=4.0 img=1.0 sys=4.0
"cygpsres-1.dll" v0.0 ts=2003/9/20 16:37
54k 2003/09/20 C:\cygwin\usr\X11R6\bin\cygSM-6.dll - os=4.0 img=1.0 sys=4.0
"cygSM-6.dll" v0.0 ts=2003/9/20 16:28
1073k 2003/09/20 C:\cygwin\usr\X11R6\bin\cygX11-6.dll - os=4.0 img=1.0 sys=4.0
"cygX11-6.dll" v0.0 ts=2003/9/20 16:27
68k 2003/09/20 C:\cygwin\usr\X11R6\bin\cygXcursor-1.dll - os=4.0 img=1.0 sys=4.0
"cygXcursor-1.dll" v0.0 ts=2003/9/20 16:39
84k 2003/09/20 C:\cygwin\usr\X11R6\bin\cygXext-6.dll - os=4.0 img=1.0 sys=4.0
"cygXext-6.dll" v0.0 ts=2003/9/20 16:28
99k 2003/09/20 C:\cygwin\usr\X11R6\bin\cygXft-1.dll - os=4.0 img=1.0 sys=4.0
"cygXft-1.dll" v0.0 ts=2003/9/20 16:39
118k 2003/09/20 C:\cygwin\usr\X11R6\bin\cygXft-2.dll - os=4.0 img=1.0 sys=4.0
"cygXft-2.dll" v0.0 ts=2003/9/20 16:39
53k 2003/09/20 C:\cygwin\usr\X11R6\bin\cygXi-6.dll - os=4.0 img=1.0 sys=4.0
"cygXi-6.dll" v0.0 ts=2003/9/20 16:30
29k 2003/09/20 C:\cygwin\usr\X11R6\bin\cygXmuu-1.dll - os=4.0 img=1.0 sys=4.0
"cygXmuu-1.dll" v0.0 ts=2003/9/20 16:29
59k 2003/09/20 C:\cygwin\usr\X11R6\bin\cygXp-6.dll - os=4.0 img=1.0 sys=4.0
"cygXp-6.dll" v0.0 ts=2003/9/20 16:31
83k 2003/09/20 C:\cygwin\usr\X11R6\bin\cygXpm-4.dll - os=4.0 img=1.0 sys=4.0
"cygXpm-4.dll" v0.0 ts=2003/9/20 16:29
34k 2003/09/20 C:\cygwin\usr\X11R6\bin\cygXrandr-2.dll - os=4.0 img=1.0 sys=4.0
"cygXrandr-2.dll" v0.0 ts=2003/9/20 16:39
49k 2003/09/20 C:\cygwin\usr\X11R6\bin\cygXrender-1.dll - os=4.0 img=1.0 sys=4.0
"cygXrender-1.dll" v0.0 ts=2003/9/20 16:38
386k 2003/09/20 C:\cygwin\usr\X11R6\bin\cygXTrap-6.dll - os=4.0 img=1.0 sys=4.0
"cygXTrap-6.dll" v0.0 ts=2003/9/20 16:39
38k 2003/09/20 C:\cygwin\usr\X11R6\bin\cygXtst-6.dll - os=4.0 img=1.0 sys=4.0
"cygXtst-6.dll" v0.0 ts=2003/9/20 16:30
34k 2003/09/20 C:\cygwin\usr\X11R6\bin\cygXv-1.dll - os=4.0 img=1.0 sys=4.0
"cygXv-1.dll" v0.0 ts=2003/9/20 16:31
Cygwin Package Information
Last downloaded files to: \\CHIMERA\cyg
Last downloaded files from: ftp://mirror.aarnet.edu.au/pub/cygwin
Package Version
_update-info-dir 00219-1
agetty 2.1-1
ash 20020731-3
astyle 1.15.3-3
autoconf 2.57a-1
autoconf-devel 2.57-2
autoconf-stable 2.13-5
automake 1.7.5a-1
automake-devel 1.7.6-2
automake-stable 1.4p5-6
base-files 2.5-1
base-passwd 1.1-1
bash 2.05b-15
binutils 20030901-1
bison 20030307-1
bzip2 1.0.2-5
ccache 2.2-1
clear 1.0-1
cmake 1.6.7-1
cron 3.0.1-11
crypt 1.0-2
curl 7.10.4-1
cygrunsrv 0.96-2
cygutils 1.2.1-2
cygwin 1.5.5-1
cygwin-doc 1.3-6
db2 2.7.7-4
db3.1 3.1.17-2
diff 1.0-1
diffutils 2.8.4-1
ed 0.2-1
ELFIO 1.0.0-1
exim 4.22-1
expat 1.95.6-2
expect 20030128-1
fetchmail 6.2.4-1
file 4.03-2
fileutils 4.1-2
findutils 4.1.7-4
flex 2.5.31-1
fortune 1.8-2
gawk 3.1.3-3
gcc 3.2-3
gcc-mingw 20020817-5
gcc2 2.95.3-10
gdb 20030919-1
gdbm 1.8.3-7
gettext 0.12.1-3
gettext-devel 0.12.1-3
grep 2.5-1
groff 1.18.1-2
gzip 1.3.5-1
indent 2.2.8-1
inetutils 1.3.2-25
keychain 1.9-1
less 381-1
libbz2_1 1.0.2-5
libcharset1 1.9.1-3
libdb2 2.7.7-4
libdb3.1 3.1.17-2
libgdbm 1.8.0-5
libgdbm-devel 1.8.3-7
libgdbm3 1.8.3-3
libgdbm4 1.8.3-7
libgettextpo0 0.12.1-3
libiconv 1.9.1-3
libiconv2 1.9.1-3
libintl 0.10.38-3
libintl1 0.10.40-1
libintl2 0.12.1-3
libkpathsea3 2.0.2-13
libltdl3 1.5-3
libncurses-devel 5.3-4
libncurses5 5.2-1
libncurses6 5.2-8
libncurses7 5.3-4
libpcre 4.1-1
libpcre0 4.4-2
libpng12 1.2.5-4
libpopt0 1.6.4-4
libreadline4 4.1-2
libreadline5 4.3-5
libtool 1.5a-1
libtool-devel 1.5-3
libtool-stable 1.4.3-2
libxerces-c21 2.1.0-1
login 1.9-7
lynx 2.8.4-7
m4 1.4-1
make 3.80-1
man 1.5j-2
mingw-runtime 3.1-1
mktemp 1.5-3
more 2.11o-1
mutt 1.4-1
ncftp 3.1.4-1
ncurses 5.3-4
newlib-man 20020801
openssh 3.7.1p1-1
openssl 0.9.7b-3
openssl096 0.9.6j-1
patch 2.5.8-8
pcre 4.4-2
pcre-doc 4.4-2
perl 5.8.0-5
pinfo 0.6.8-1
procmail 3.22-8
procps 010801-2
readline 4.3-5
rebase 2.2-3
rxvt 2.7.10-3
sed 4.0.7-3
sh-utils 2.0.15-4
sharutils 4.2.1-3
shutdown 1.4-1
ssmtp 2.38.7-4
sysvinit 2.84-4
tar 1.13.25-3
tcltk 20030901-1
tcp_wrappers 7.6-1
tcsh 6.12.00-7
termcap 20021106-2
terminfo 5.3_20030726-1
texinfo 4.2-4
textutils 2.0.21-1
time 1.7-1
tin 1.6.1-1
ttcp 19980512-1
units 1.77-1
unzip 5.50-5
vim 6.2.098-1
w32api 2.4-1
wget 1.8.2-2
which 1.5-2
whois 4.6.2-1
xerces-c-devel 2.3.0-2
XFree86-base 4.3.0-1
XFree86-bin 4.3.0-4
XFree86-etc 4.3.0-3
XFree86-fenc 4.2.0-3
XFree86-fnts 4.2.0-3
XFree86-lib 4.3.0-1
XFree86-lib-compat 4.3.0-1
XFree86-startup-scripts 4.2.0-5
XFree86-xserv 4.3.0-3
zip 2.3-5
zlib 1.1.4-4
Use -h to see help about each section
[-- Attachment #3: Type: text/plain, Size: 218 bytes --]
--
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/
^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2003-10-10 13:10 UTC | newest]
Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-10-05 3:16 cygwin-1.5.4-1 breaks fetchmail on Win9x Mark Ord
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
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).