* 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; 12+ 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] 12+ 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; 12+ 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] 12+ 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; 12+ 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] 12+ 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; 12+ 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] 12+ 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; 12+ 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] 12+ 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; 12+ 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] 12+ 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; 12+ 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] 12+ 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; 12+ 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] 12+ 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; 12+ 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] 12+ 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; 12+ 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] 12+ 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; 12+ 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] 12+ 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; 12+ 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] 12+ messages in thread
end of thread, other threads:[~2003-10-10 13:10 UTC | newest] Thread overview: 12+ 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
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).