From: Max T. W. <ma...@mt...> - 2005-06-26 22:26:57
|
In tracking a problem mentioned over in mingw-msys, I ran across the following that seems to be relevant: http://homepages.nildram.co.uk/~phekda/richdawe/djgpp/2.04/fchdir.txt It outlines a fairly comprehensive set of changes needed to implement fchdir properly and it touches: open __opendir_as_fd read write close llseek ftruncate fchmod fchown ioctl fcntl lockf llockf fstat select fsync fchdir fdopen fopen freopen fread getc fgetc fgets ungetc fwrite putc fputc fputs fflush fclose ftell fseek rewind feof ferror setvbuf fpurge There are a few others that nominally call one of the above to do the work and given their assumptions some of these do not need to be changed, but all should be reviewed. This does not look like it is subject to a quick fix and could easily impact the whole MSys schedule. If it is going to be implemented like this, it will probably need to be done in stages: - Create a CVS branch for testing changes. This will contain key changes like those to 'open' that are needed to activate the rest of the changes and do NOT belong in the public release until the whole set of changes has been certified as being usable. - Make 'infrastructure' changes that will be needed by other changes. These can, and probably should, be done to the HEAD branch with the understanding that they will have no observable effect until the key changes mentioned above are merged back into the main branch. - Make supporting changes to routines to use the new infrastructure. Again this probably can be done in head since the actual impact will not be seen until the key changes are made. - Test the hell out of it. This probably means employing a standard test suite, rebuilding everything under the sun to use the new capability and making sure it all works. - Merge the key changes back into HEAD. I suspect that a number of people will need to work on this to get it done quickly or we may end up 'borrowing' the djgpp code and adapting it to MSys. Comments PLEASE! |
From: Earnie B. <ea...@us...> - 2005-06-26 23:05:01
|
On 10:26:32 pm 2005-06-26 "Max T. Woodbury" <ma...@mt...> wrote: > In tracking a problem mentioned over in mingw-msys, I ran across the > following that seems to be relevant: > > http://homepages.nildram.co.uk/~phekda/richdawe/djgpp/2.04/fchdir.txt > > It outlines a fairly comprehensive set of changes needed to implement > fchdir properly and it touches: > > open __opendir_as_fd read write close > llseek ftruncate fchmod fchown ioctl > fcntl lockf llockf fstat select > fsync fchdir fdopen fopen > freopen fread getc fgetc fgets > ungetc fwrite putc fputc fputs > fflush fclose ftell fseek rewind > feof ferror setvbuf fpurge > > There are a few others that nominally call one of the above to do the > work and given their assumptions some of these do not need to be > changed, but all should be reviewed. > I don't mind that you review any of these but the SUSv3 specifications is what you need to use for comparison. > This does not look like it is subject to a quick fix and could easily > impact the whole MSys schedule. If it is going to be implemented like > this, it will probably need to be done in stages: > IIRC, you are using win98 with FAT32. Changes you would make need to keep that in consideration. > - Create a CVS branch for testing changes. This will contain key > changes like those to 'open' that are needed to activate the rest > of the changes and do NOT belong in the public release until the > whole set of changes has been certified as being usable. > > - Make 'infrastructure' changes that will be needed by other changes. > These can, and probably should, be done to the HEAD branch with the > understanding that they will have no observable effect until the > key changes mentioned above are merged back into the main branch. > You'll need to explain this better. I'm not sure what you mean. Earnie |
From: Max T. W. <ma...@mt...> - 2005-06-27 00:20:35
|
Earnie Boyd wrote: > > On 10:26:32 pm 2005-06-26 "Max T. Woodbury" <ma...@mt...> wrote: > > In tracking a problem mentioned over in mingw-msys, I ran across the > > following that seems to be relevant: > > > > http://homepages.nildram.co.uk/~phekda/richdawe/djgpp/2.04/fchdir.txt > > > > It outlines a fairly comprehensive set of changes needed to implement > > fchdir properly and it touches: > > > > open __opendir_as_fd read write close > > llseek ftruncate fchmod fchown ioctl > > fcntl lockf llockf fstat select > > fsync fchdir fdopen fopen > > freopen fread getc fgetc fgets > > ungetc fwrite putc fputc fputs > > fflush fclose ftell fseek rewind > > feof ferror setvbuf fpurge > > > > There are a few others that nominally call one of the above to do the > > work and given their assumptions some of these do not need to be > > changed, but all should be reviewed. > > > > I don't mind that you review any of these but the SUSv3 specifications is > what you need to use for comparison. Fine. I'll google it. > > This does not look like it is subject to a quick fix and could easily > > impact the whole MSys schedule. If it is going to be implemented like > > this, it will probably need to be done in stages: > > IIRC, you are using win98 with FAT32. Changes you would make need to keep > that in consideration. Yes. I will not be able to do this alone. At a minimum, I'll need to have someone else test things. I'm going to have to learn a lot more about SourceForge as well I think. They have a 'compiler farm'. Does it include MicroS* thingies? If I really have to, I can scrape up a spare drive for my laptop and put NT on it. I believe XT needs 128MB of memory or more and this poor beast only has 80. > > - Create a CVS branch for testing changes. This will contain key > > changes like those to 'open' that are needed to activate the rest > > of the changes and do NOT belong in the public release until the > > whole set of changes has been certified as being usable. > > > > - Make 'infrastructure' changes that will be needed by other changes. > > These can, and probably should, be done to the HEAD branch with the > > understanding that they will have no observable effect until the > > key changes mentioned above are merged back into the main branch. > > You'll need to explain this better. I'm not sure what you mean. The document mentioned adding bits and support functions. These have to go in before they can be used. However they should not cause problems for anything that doesn't use them. Still, once they are added, a review should be done to make sure that that assumption is correct. For example, adding a 'directory' bit to the 'fd' structure (I'm guessing at the name here - just lazy - I think you can figure out what I mean) and adding code that tests for it will have no effect until there is some piece of code that sets that bit. Put that one piece in the test branch where it can't be picked up by someone by accident. The rest can be in HEAD where it will be picked up and compiled. That makes sure that the new code at least compiles on various systems even if it is never executed. Max |
From: Earnie B. <ea...@us...> - 2005-06-27 00:39:34
|
On 12:20:04 am 2005-06-27 "Max T. Woodbury" <ma...@mt...> wrote: > Earnie Boyd wrote: > > > > On 10:26:32 pm 2005-06-26 "Max T. Woodbury" <ma...@mt...> > wrote: > > > In tracking a problem mentioned over in mingw-msys, I ran across > > > the following that seems to be relevant: > > > > > > http://homepages.nildram.co.uk/~phekda/richdawe/djgpp/2.04/fchdir > .txt > > > > > > It outlines a fairly comprehensive set of changes needed to > > > implement fchdir properly and it touches: > > > > > > open __opendir_as_fd read write > > > close llseek ftruncate fchmod fchown > > > ioctl fcntl lockf llockf fstat > > > select fsync fchdir fdopen fopen > > > freopen fread getc fgetc > > > fgets ungetc fwrite putc fputc > > > fputs fflush fclose ftell fseek > > > rewind feof ferror setvbuf fpurge > > > > > > There are a few others that nominally call one of the above to > > > do the work and given their assumptions some of these do not > > > need to be changed, but all should be reviewed. > > > > > > > I don't mind that you review any of these but the SUSv3 > > specifications is what you need to use for comparison. > > Fine. I'll google it. > > > > This does not look like it is subject to a quick fix and could > > > easily impact the whole MSys schedule. If it is going to be > > > implemented like this, it will probably need to be done in > > stages: > > IIRC, you are using win98 with FAT32. Changes you would make need > > to keep that in consideration. > > Yes. I will not be able to do this alone. At a minimum, I'll need > to have someone else test things. I'm going to have to learn a lot > more about SourceForge as well I think. They have a 'compiler farm'. > Does it include MicroS* thingies? > There are flag bits to test for which system you're coding for. You'll need to filter the code based on the system type you're executing on. > If I really have to, I can scrape up a spare drive for my laptop and > put NT on it. I believe XT needs 128MB of memory or more and this > poor beast only has 80. > NT 4 or Windows 2000 would be sufficient if they had NTFS file systems. > > > - Create a CVS branch for testing changes. This will contain key > > > changes like those to 'open' that are needed to activate the > > > rest of the changes and do NOT belong in the public release > > > until the whole set of changes has been certified as being > > > usable. > > > - Make 'infrastructure' changes that will be needed by other > > > changes. These can, and probably should, be done to the HEAD > > > branch with the understanding that they will have no > > > observable effect until the key changes mentioned above are > > merged back into the main branch. > > You'll need to explain this better. I'm not sure what you mean. > > The document mentioned adding bits and support functions. These have > to go in before they can be used. However they should not cause > problems for anything that doesn't use them. Still, once they are > added, a review should be done to make sure that that assumption is > correct. > > For example, adding a 'directory' bit to the 'fd' structure (I'm > guessing at the name here - just lazy - I think you can figure out > what I mean) and adding code that tests for it will have no effect > until there is some piece of code that sets that bit. Put that one > piece in the test branch where it can't be picked up by someone by > accident. The rest can be in HEAD where it will be picked up and > compiled. That makes sure that the new code at least compiles on > various systems even if it is never executed. > It sounds as if you expect it to not be coded already which would be a wrong assumption. MSYS has more than a few lines of code. You'll have to determine what is missing. A good place to start is looking at the winsup/cygwin/cygwin.din file which contains the list of exported functions. Earnie |
From: Max T. W. <ma...@mt...> - 2005-06-27 01:41:09
|
Earnie Boyd wrote: > > On 12:20:04 am 2005-06-27 "Max T. Woodbury" <ma...@mt...> wrote: > > Earnie Boyd wrote: > > > > > > I don't mind that you review any of these but the SUSv3 > > > specifications is what you need to use for comparison. > > > > Fine. I'll google it. > > > > > IIRC, you are using win98 with FAT32. Changes you would make need > > > to keep that in consideration. > > > > Yes. I will not be able to do this alone. At a minimum, I'll need > > to have someone else test things. I'm going to have to learn a lot > > more about SourceForge as well I think. They have a 'compiler farm'. > > Does it include MicroS* thingies? > > > > There are flag bits to test for which system you're coding for. You'll > need to filter the code based on the system type you're executing on. Yep. I've seen those. Are there ones for file system type or is the assumption NT == NTFS and !NT == FATxx. > > If I really have to, I can scrape up a spare drive for my laptop and > > put NT on it. I believe XT needs 128MB of memory or more and this > > poor beast only has 80. > > > > NT 4 or Windows 2000 would be sufficient if they had NTFS file systems. I have NT 4 and XP in hand, just not used, but I do not have a 2K at hand. If I'm going to play with 'em I'll try to put XP up under VMWare. > > > You'll need to explain this better. I'm not sure what you mean. > > > > The document mentioned adding bits and support functions. These have > > to go in before they can be used. However they should not cause > > problems for anything that doesn't use them. Still, once they are > > added, a review should be done to make sure that that assumption is > > correct. > > > > For example, adding a 'directory' bit to the 'fd' structure (I'm > > guessing at the name here - just lazy - I think you can figure out > > what I mean) and adding code that tests for it will have no effect > > until there is some piece of code that sets that bit. Put that one > > piece in the test branch where it can't be picked up by someone by > > accident. The rest can be in HEAD where it will be picked up and > > compiled. That makes sure that the new code at least compiles on > > various systems even if it is never executed. > > > > It sounds as if you expect it to not be coded already which would be a > wrong assumption. MSYS has more than a few lines of code. You'll have to > determine what is missing. A good place to start is looking at the > winsup/cygwin/cygwin.din file which contains the list of exported functions. From the djgpp document outlines quite a few changes to existing routines. I searched for a few of the more important ones to see if they fit the pattern described. All the external interfaces I checked for were there but the quick look at the code showed no awareness of directories in the key places. So I expect that there will be more than a little code to add to stuff that is already there and that it can be safely added in HEAD as long as the piece that would activate the sequence was sequestered in a testing branch, simply not checked in or isolated with a #if ... #endif pair until all the testing is done. (Argh - run on sentence - apology.) And yes MSys has a magnificent amount of code. Much more than I'd care to try to write by myself. However, I read other peoples code fairly quickly. That was the first thing I learned when I started programming. (And it wasn't nice, clean, well formatted and well structured code like yours either. It was a bastard version of 1960s style FORTRAN with rampant GOTOs written by an 'old hand' who learned 'real programming' as a mathematician in the early 50s that I started on!) |
From: Christopher F. <me...@cg...> - 2005-06-27 02:50:11
|
On Sun, Jun 26, 2005 at 09:40:43PM -0400, Max T. Woodbury wrote: >And yes MSys has a magnificent amount of code. Much more than I'd care >to try to write by myself. However, I read other peoples code fairly >quickly. That was the first thing I learned when I started >programming. (And it wasn't nice, clean, well formatted and well >structured code like yours either. It was a bastard version of 1960s >style FORTRAN with rampant GOTOs written by an 'old hand' who learned >'real programming' as a mathematician in the early 50s that I started >on!) I'm a little lost here. It sounds like you're talking about adding fchdir to msys. If so, adding this to cygwin was a pretty trivial undertaking so it shouldn't be that hard to do for msys. I wouldn't use the example of djgpp as a basis for determining what is possible for a cygwin derivative. cgf |
From: Max T. W. <ma...@mt...> - 2005-06-27 03:40:42
|
Christopher Faylor wrote: > > On Sun, Jun 26, 2005 at 09:40:43PM -0400, Max T. Woodbury wrote: > >And yes MSys has a magnificent amount of code. Much more than I'd care > >to try to write by myself. However, I read other peoples code fairly > >quickly. That was the first thing I learned when I started > >programming. (And it wasn't nice, clean, well formatted and well > >structured code like yours either. It was a bastard version of 1960s > >style FORTRAN with rampant GOTOs written by an 'old hand' who learned > >'real programming' as a mathematician in the early 50s that I started > >on!) > > I'm a little lost here. It sounds like you're talking about adding > fchdir to msys. If so, adding this to cygwin was a pretty trivial > undertaking so it shouldn't be that hard to do for msys. I wouldn't use > the example of djgpp as a basis for determining what is possible for a > cygwin derivative. It's just a touch complicated. 'fchdir' is there already. It just can't be used since you can not open a file handle on a directory. Adding the ability to open a file handle on a directory touches a lot of code. From the djgpp document, it definitely looks doable, and I or almost any other programmer who is willing to dig into MSys could do it. The questions are who and how long and what will the impact on the rest of the project be. Meanwhile I'm trying to politely blow my own horn and imply that I should be one of the 'who' without coming right out and saying that. Of course I just 'blew my cover' by saying that. Max |
From: Christopher F. <me...@cg...> - 2005-06-27 05:21:45
|
On Sun, Jun 26, 2005 at 11:40:17PM -0400, Max T. Woodbury wrote: >Christopher Faylor wrote: >>On Sun, Jun 26, 2005 at 09:40:43PM -0400, Max T. Woodbury wrote: >>>And yes MSys has a magnificent amount of code. Much more than I'd care >>>to try to write by myself. However, I read other peoples code fairly >>>quickly. That was the first thing I learned when I started >>>programming. (And it wasn't nice, clean, well formatted and well >>>structured code like yours either. It was a bastard version of 1960s >>>style FORTRAN with rampant GOTOs written by an 'old hand' who learned >>>'real programming' as a mathematician in the early 50s that I started >>>on!) >> >>I'm a little lost here. It sounds like you're talking about adding >>fchdir to msys. If so, adding this to cygwin was a pretty trivial >>undertaking so it shouldn't be that hard to do for msys. I wouldn't >>use the example of djgpp as a basis for determining what is possible >>for a cygwin derivative. > >It's just a touch complicated. 'fchdir' is there already. It just >can't be used since you can not open a file handle on a directory. >Adding the ability to open a file handle on a directory touches a lot >of code. From the djgpp document, it definitely looks doable, and I or >almost any other programmer who is willing to dig into MSys could do >it. You *can* open directories on NT. In cygwin, the inability to do so on 9x is worked around by allowing the open to succeed but setting a "nohandle" flag on the fhandler. cgf |
From: Earnie B. <ea...@us...> - 2005-06-27 11:08:21
|
On 2:49:51 am 2005-06-27 Christopher Faylor <me...@cg...> wrote: > On Sun, Jun 26, 2005 at 09:40:43PM -0400, Max T. Woodbury wrote: > > And yes MSys has a magnificent amount of code. Much more than I'd > > care to try to write by myself. However, I read other peoples code > > fairly quickly. That was the first thing I learned when I started > > programming. (And it wasn't nice, clean, well formatted and well > > structured code like yours either. It was a bastard version of > > 1960s style FORTRAN with rampant GOTOs written by an 'old hand' who > > learned 'real programming' as a mathematician in the early 50s that > > I started on!) > > I'm a little lost here. It sounds like you're talking about adding > fchdir to msys. If so, adding this to cygwin was a pretty trivial > undertaking so it shouldn't be that hard to do for msys. I wouldn't > use the example of djgpp as a basis for determining what is possible > for a cygwin derivative. > I'm lost as well. Fchdir is already a part of msys. Fchdir wasn't working for Max when he built an MSYS dependent findutils. But the distributed find.exe doesn't use fchdir anyway. I'll take a look later this AM. Earnie |
From: Max T. W. <ma...@mt...> - 2005-06-27 14:15:20
|
Christopher Faylor wrote: > > On Sun, Jun 26, 2005 at 11:40:17PM -0400, Max T. Woodbury wrote: > >Christopher Faylor wrote: > >>I'm a little lost here. It sounds like you're talking about adding > >>fchdir to msys. If so, adding this to cygwin was a pretty trivial > >>undertaking so it shouldn't be that hard to do for msys. I wouldn't > >>use the example of djgpp as a basis for determining what is possible > >>for a cygwin derivative. > > > >It's just a touch complicated. 'fchdir' is there already. It just > >can't be used since you can not open a file handle on a directory. > >Adding the ability to open a file handle on a directory touches a lot > >of code. From the djgpp document, it definitely looks doable, and I or > >almost any other programmer who is willing to dig into MSys could do > >it. > > You *can* open directories on NT. In cygwin, the inability to do so on > 9x is worked around by allowing the open to succeed but setting a > "nohandle" flag on the fhandler. Sorry, my bad. I think I said file handle earlier when I meant file descriptor. In any case a check of both fhandler.cc and syscalls.cc show no such flag per se. I think something needs to be done about line 498 of syscalls.cc but that still needs a bit more checking. What is puzzling is the fact that an 'open( "..")' might be working in one context while 'open( ".", <something>)' is failing. As noted in many comments in the code, 9x seems to report 'permission denied' when it means 'sharing violation'. There is also an O_DIRECTORY flag that I'll need to look up. Oh, and in Cygwin, did 'nohandle' mean 'directory' or did it have other uses? Max |
From: Max T. W. <ma...@mt...> - 2005-06-27 19:13:44
|
Earnie Boyd wrote: > > On 2:49:51 am 2005-06-27 Christopher Faylor <me...@cg...> wrote: > > On Sun, Jun 26, 2005 at 09:40:43PM -0400, Max T. Woodbury wrote: > > > And yes MSys has a magnificent amount of code. Much more than I'd > > > care to try to write by myself. However, I read other peoples code > > > fairly quickly. That was the first thing I learned when I started > > > programming. (And it wasn't nice, clean, well formatted and well > > > structured code like yours either. It was a bastard version of > > > 1960s style FORTRAN with rampant GOTOs written by an 'old hand' who > > > learned 'real programming' as a mathematician in the early 50s that > > > I started on!) > > > > I'm a little lost here. It sounds like you're talking about adding > > fchdir to msys. If so, adding this to cygwin was a pretty trivial > > undertaking so it shouldn't be that hard to do for msys. I wouldn't > > use the example of djgpp as a basis for determining what is possible > > for a cygwin derivative. > > > > I'm lost as well. Fchdir is already a part of msys. Fchdir wasn't working > for Max when he built an MSYS dependent findutils. But the distributed > find.exe doesn't use fchdir anyway. I'll take a look later this AM. You were going to send/post the config.log? |
From: Earnie B. <ea...@us...> - 2005-06-27 22:53:52
|
On 7:13:22 pm 2005-06-27 "Max T. Woodbury" <ma...@mt...> wrote: > Earnie Boyd wrote: > > > > On 2:49:51 am 2005-06-27 Christopher Faylor <me...@cg...> wrote: > > > On Sun, Jun 26, 2005 at 09:40:43PM -0400, Max T. Woodbury wrote: > > > > And yes MSys has a magnificent amount of code. Much more than > > > > I'd care to try to write by myself. However, I read other > > > > peoples code fairly quickly. That was the first thing I > > > > learned when I started programming. (And it wasn't nice, > > > > clean, well formatted and well structured code like yours > > > > either. It was a bastard version of 1960s style FORTRAN with > > > > rampant GOTOs written by an 'old hand' who learned 'real > > > > programming' as a mathematician in the early 50s that I > > > started on!) > > > I'm a little lost here. It sounds like you're talking about > > > adding fchdir to msys. If so, adding this to cygwin was a > > > pretty trivial undertaking so it shouldn't be that hard to do > > > for msys. I wouldn't use the example of djgpp as a basis for > > > determining what is possible for a cygwin derivative. > > > > > > > I'm lost as well. Fchdir is already a part of msys. Fchdir > > wasn't working for Max when he built an MSYS dependent findutils. > > But the distributed find.exe doesn't use fchdir anyway. I'll take > a look later this AM. > > You were going to send/post the config.log? > Sending it to you privately. Interestingly though, I had to recreate the configury and when I built find it includes fchdir in the exe. The binary works for me. I'm sending along the rebuild find.exe so that you can test it on your system. Earnie |
From: Max T. W. <ma...@mt...> - 2005-06-27 20:19:04
|
"Max T. Woodbury" wrote: > > In any case a check of both fhandler.cc and syscalls.cc show no such > flag per se. I think something needs to be done about line 498 of > syscalls.cc but that still needs a bit more checking. What is puzzling > is the fact that an 'open( "..")' might be working in one context while > 'open( ".", <something>)' is failing. As noted in many comments in the > code, 9x seems to report 'permission denied' when it means 'sharing > violation'. There is also an O_DIRECTORY flag that I'll need to look up. > Sloppy on my part. That should be O_DIROPEN used dir.cc:131 and 3 places in syscalls.cc. Used to set FILE_FLAG_BACKUP_SEMANTICS which is passed to CreateFileA in fhandler.cc and is set when the file attributes indicate a directory. No other use in the whole rt/src directory tree. It does seem to get stuffed in the fh flags so it could be the bit that is needed for other tests. Hmm. This might be relevant - the 'share' attribute is - FILE_SHARE_READ | FILE_SHARE_WRITE Maybe that should be adjusted if O_RDONLY is requested? Let's try that and see. It'll be a couple hours to test... |
From: Max T. W. <ma...@mt...> - 2005-06-28 02:36:28
|
Earnie Boyd wrote: > > On 7:13:22 pm 2005-06-27 "Max T. Woodbury" <ma...@mt...> wrote: > > > > You were going to send/post the config.log? > > > > Sending it to you privately. Interestingly though, I had to recreate the > configury and when I built find it includes fchdir in the exe. The binary > works for me. I'm sending along the rebuild find.exe so that you can test > it on your system. For the record it blows up on W98SE. Permission denied on current directory or words to that effect. Virtually identical to what I ran aground on. I've been digging through the various ways things get 'open'ed and all the disk stuff seems to go through fhandler_base::open, including opendir. I've tried alternative 'access' and 'share' values there with no luck. I've seen open (".", O_RDONLY) fail, but opendir ends up in the same code and works. It might have to do with the form of the name. Let's see... PC_FULL and path_conv::check looks like the way to check that in syscalls.cc (_open). Can you call 'check' a second time without loosing strings and stuff? Oh well, that's just a bit more to read. I think a program to test the various directory access routines is probably the next thing to put in place if this last test fails. I've backed off on the subject line since it looks like it'll only take one small fix (even if what that fix is is not known at the moment). |
From: Max T. W. <ma...@mt...> - 2005-06-29 17:35:13
|
"Max T. Woodbury" wrote: > > Earnie Boyd wrote: > > > > On 7:13:22 pm 2005-06-27 "Max T. Woodbury" <ma...@mt...> wrote: > > > > > > You were going to send/post the config.log? > > > > > > > Sending it to you privately. Interestingly though, I had to recreate the > > configury and when I built find it includes fchdir in the exe. The binary > > works for me. I'm sending along the rebuild find.exe so that you can test > > it on your system. > > For the record it blows up on W98SE. Permission denied on current directory > or words to that effect. Virtually identical to what I ran aground on. > > I've been digging through the various ways things get 'open'ed and all the > disk stuff seems to go through fhandler_base::open, including opendir. I've > tried alternative 'access' and 'share' values there with no luck. > > I've seen open (".", O_RDONLY) fail, but opendir ends up in the same code and > works. It might have to do with the form of the name. Let's see... PC_FULL > and path_conv::check looks like the way to check that in syscalls.cc (_open). > Can you call 'check' a second time without loosing strings and stuff? Oh well, > that's just a bit more to read. > > I think a program to test the various directory access routines is probably > the next thing to put in place if this last test fails. Not quite yet but this is still in-queue. > I've backed off on the subject line since it looks like it'll only take one > small fix (even if what that fix is is not known at the moment). I tried a simple minded change to fhandler_disk<whatever>::open to make it look a bit more like opendir but it didn't work. I'm building the debug .dll at the moment. I'm probably going to need a little advice on how to use it but I'll wait on specific questions until I've tried it once. I also found that a line in /etc/config.site can be used to turn off the use of fchdir. Wasn't there a note on cleaning up config.site in this ML a while back? ma...@mt... |
From: Earnie B. <ea...@us...> - 2005-06-30 02:33:26
|
On 5:34:48 pm 2005-06-29 "Max T. Woodbury" <ma...@mt...> wrote: > "Max T. Woodbury" wrote: > > > > Earnie Boyd wrote: > > > > > > On 7:13:22 pm 2005-06-27 "Max T. Woodbury" <ma...@mt... > > wrote: > > > > > > > > You were going to send/post the config.log? > > > > > > > > > > Sending it to you privately. Interestingly though, I had to > > > recreate the configury and when I built find it includes fchdir > > > in the exe. The binary works for me. I'm sending along the > > > rebuild find.exe so that you can test it on your system. > > > > For the record it blows up on W98SE. Permission denied on current > > directory or words to that effect. Virtually identical to what I > > ran aground on. > > I've been digging through the various ways things get 'open'ed and > > all the disk stuff seems to go through fhandler_base::open, > > including opendir. I've tried alternative 'access' and 'share' > > values there with no luck. > > I've seen open (".", O_RDONLY) fail, but opendir ends up in the > > same code and works. It might have to do with the form of the > > name. Let's see... PC_FULL and path_conv::check looks like the > > way to check that in syscalls.cc (_open). Can you call 'check' a > > second time without loosing strings and stuff? Oh well, that's > > just a bit more to read. > > I think a program to test the various directory access routines is > > probably the next thing to put in place if this last test fails. > > Not quite yet but this is still in-queue. > > > I've backed off on the subject line since it looks like it'll only > > take one small fix (even if what that fix is is not known at the > moment). > > I tried a simple minded change to fhandler_disk<whatever>::open to > make it look a bit more like opendir but it didn't work. I'm > building the debug .dll at the moment. I'm probably going to need a > little advice on how to use it but I'll wait on specific questions > until I've tried it once. > > I also found that a line in /etc/config.site can be used to turn off > the use of fchdir. Wasn't there a note on cleaning up config.site in > this ML a while back? > Yes, it will be removed in the next release of MSYS. Libtool has progressed beyond the point of needing it which was to help building libraries with older version of libtool. Earnie |
From: Max T. W. <ma...@mt...> - 2005-06-30 07:29:03
|
Earnie Boyd wrote: > > On 5:34:48 pm 2005-06-29 "Max T. Woodbury" <ma...@mt...> wrote: > > "Max T. Woodbury" wrote: > > > > > > For the record it blows up on W98SE. Permission denied on current > > > directory or words to that effect. Virtually identical to what I > > > ran aground on. > > > I've been digging through the various ways things get 'open'ed and > > > all the disk stuff seems to go through fhandler_base::open, > > > including opendir. I've tried alternative 'access' and 'share' > > > values there with no luck. > > > I've seen open (".", O_RDONLY) fail, but opendir ends up in the > > > same code and works. It might have to do with the form of the > > > name. Let's see... PC_FULL and path_conv::check looks like the > > > way to check that in syscalls.cc (_open). Can you call 'check' a > > > second time without loosing strings and stuff? Oh well, that's > > > just a bit more to read. > > > I think a program to test the various directory access routines is > > > probably the next thing to put in place if this last test fails. > > > > Not quite yet but this is still in-queue. > > > > > I've backed off on the subject line since it looks like it'll only > > > take one small fix (even if what that fix is is not known at the > > moment). > > > > I tried a simple minded change to fhandler_disk<whatever>::open to > > make it look a bit more like opendir but it didn't work. I'm > > building the debug .dll at the moment. I'm probably going to need a > > little advice on how to use it but I'll wait on specific questions > > until I've tried it once. I kludged fhandler_disk::open to return success if fhandler::open failed, it is not WinNT and the path is a directory. Even with a broken file handle find.exe then worked properly. I'll check fileutils shortly. However I am not completely comfortable with this kluge. Should other things be checked like O_RDONLY? And thanks Christopher for the information on Cygwin. It seems a separate flag is not needed, just the fact that the handle is not valid (that is ~0) seems to be sufficient. > > I also found that a line in /etc/config.site can be used to turn off > > the use of fchdir. Wasn't there a note on cleaning up config.site in > > this ML a while back? > > > > Yes, it will be removed in the next release of MSYS. Libtool has > progressed beyond the point of needing it which was to help building > libraries with older version of libtool. OK. That means I will not try to use it for this kind of messing around either. |
From: Max T. W. <ma...@mt...> - 2005-07-25 20:29:47
|
"Max T. Woodbury" wrote: > > Earnie Boyd wrote: > > > > On 5:34:48 pm 2005-06-29 "Max T. Woodbury" <ma...@mt...> wrote: > > > "Max T. Woodbury" wrote: > > > > > > > > For the record it blows up on W98SE. Permission denied on current > > > > directory or words to that effect. Virtually identical to what I > > > > ran aground on. > > > > > > > > I've been digging through the various ways things get 'open'ed and > > > > all the disk stuff seems to go through fhandler_base::open, > > > > including opendir. I've tried alternative 'access' and 'share' > > > > values there with no luck. > > > > > > > > I've seen open (".", O_RDONLY) fail, but opendir ends up in the > > > > same code and works. It might have to do with the form of the > > > > name. Let's see... PC_FULL and path_conv::check looks like the > > > > way to check that in syscalls.cc (_open). Can you call 'check' a > > > > second time without loosing strings and stuff? Oh well, that's > > > > just a bit more to read. > > > > > > > > I think a program to test the various directory access routines is > > > > probably the next thing to put in place if this last test fails. > > > > > > Not quite yet but this is still in-queue. > > > > > > > I've backed off on the subject line since it looks like it'll only > > > > take one small fix (even if what that fix is is not known at the > > > > moment). > > > > > > I tried a simple minded change to fhandler_disk<whatever>::open to > > > make it look a bit more like opendir but it didn't work. I'm > > > building the debug .dll at the moment. I'm probably going to need a > > > little advice on how to use it but I'll wait on specific questions > > > until I've tried it once. > > I kludged fhandler_disk::open to return success if fhandler::open failed, > it is not WinNT and the path is a directory. Even with a broken file handle > find.exe then worked properly. I'll check fileutils shortly. However > I am not completely comfortable with this kluge. Should other things be > checked like O_RDONLY? > > And thanks Christopher for the information on Cygwin. It seems a separate > flag is not needed, just the fact that the handle is not valid (that is > ~0) seems to be sufficient. Further testing indicates that this patch introduces other problems. It may be possible to add more work-arounds, but it is not sufficient by itself to get all this working. PLEASE back this patch out, at least for now. mt...@us... |