_open not doing the right thing
Author |
Message |
Josh Gibb #1 / 10
|
 _open not doing the right thing
Hi, I'm porting some code from another system and have writting a function as follows: int FileOpen(char *FileName,int access,int share) { return(_open(FileName,access | share)); Quote: }
Now this should be a very straight forward function, but, after working through a problem I found some files set to read only. Odd thing is that one function that calls this func 3 times to get three file handles gets 2 files as RO, and 1 as RW. Stepping the code shows the exact same parameters for access & share for all 3 files. WTF could be happening? TIA
|
Sun, 29 Jun 2003 19:38:10 GMT |
|
 |
Doug Harrison [MVP #2 / 10
|
 _open not doing the right thing
Quote:
>Hi, >I'm porting some code from another system and have writting >a function as follows: >int FileOpen(char *FileName,int access,int share) >{ > return(_open(FileName,access | share)); >} >Now this should be a very straight forward function, but, after >working through a problem I found some files set to read only. >Odd thing is that one function that calls this func 3 times to get >three file handles gets 2 files as RO, and 1 as RW. Stepping >the code shows the exact same parameters for access & share >for all 3 files. >WTF could be happening?
I have no idea, but _open doesn't take sharing flags. Look into _sopen. -- Doug Harrison [VC++ MVP] Eluent Software, LLC http://www.eluent.com Tools for Visual C++ and Windows
|
Mon, 30 Jun 2003 04:06:26 GMT |
|
 |
Josh Gibb #3 / 10
|
 _open not doing the right thing
_open does indeed take sharing flags relating to the OS it comes from. That is a moot point anyway, as the three calls that are made within two functions - both called from the same parent function in the same code block - are opening the file with the same params. Just that two get RO & one gets RW? It's bizarre. I've actually modified the FileOpen call to hardcode the flags as well, but still no joy. Think I might be spending another day slaving over what should be a straight forward operation. Gee, thanks Microsoft!!! :-( Quote:
> >Hi, > >I'm porting some code from another system and have writting > >a function as follows: > >int FileOpen(char *FileName,int access,int share) > >{ > > return(_open(FileName,access | share)); > >} > >Now this should be a very straight forward function, but, after > >working through a problem I found some files set to read only. > >Odd thing is that one function that calls this func 3 times to get > >three file handles gets 2 files as RO, and 1 as RW. Stepping > >the code shows the exact same parameters for access & share > >for all 3 files. > >WTF could be happening? > I have no idea, but _open doesn't take sharing flags. Look into > _sopen. > -- > Doug Harrison [VC++ MVP] > Eluent Software, LLC > http://www.eluent.com > Tools for Visual C++ and Windows
|
Mon, 30 Jun 2003 05:19:24 GMT |
|
 |
Igor Tandetni #4 / 10
|
 _open not doing the right thing
Do those two files, by any chance, have "read-only" attribute set? -- With best wishes, Igor Tandetnik
Quote: > _open does indeed take sharing flags relating to the OS it comes > from. That is a moot point anyway, as the three calls that are made > within two functions - both called from the same parent function in > the same code block - are opening the file with the same params. > Just that two get RO & one gets RW? It's bizarre. I've actually > modified the FileOpen call to hardcode the flags as well, but still > no joy. > Think I might be spending another day slaving over what should > be a straight forward operation. > Gee, thanks Microsoft!!! :-(
> > >Hi, > > >I'm porting some code from another system and have writting > > >a function as follows: > > >int FileOpen(char *FileName,int access,int share) > > >{ > > > return(_open(FileName,access | share)); > > >} > > >Now this should be a very straight forward function, but, after > > >working through a problem I found some files set to read only. > > >Odd thing is that one function that calls this func 3 times to get > > >three file handles gets 2 files as RO, and 1 as RW. Stepping > > >the code shows the exact same parameters for access & share > > >for all 3 files. > > >WTF could be happening? > > I have no idea, but _open doesn't take sharing flags. Look into > > _sopen. > > -- > > Doug Harrison [VC++ MVP] > > Eluent Software, LLC > > http://www.eluent.com > > Tools for Visual C++ and Windows
|
Mon, 30 Jun 2003 05:39:26 GMT |
|
 |
Doug Harrison [MVP #5 / 10
|
 _open not doing the right thing
Quote:
>_open does indeed take sharing flags relating to the OS it comes >from.
Not in VC++. You need _sopen to specify sharing modes. Quote: >That is a moot point anyway as the three calls that are made >within two functions - both called from the same parent function in >the same code block - are opening the file with the same params. >Just that two get RO & one gets RW? It's bizarre. I've actually >modified the FileOpen call to hardcode the flags as well, but still >no joy.
Well, _open is used by stdio, and I seriously doubt there is a bug in such commonly used functions. Quote: >Think I might be spending another day slaving over what should >be a straight forward operation. >Gee, thanks Microsoft!!! :-(
If you don't figure it out, post the exact sequence of calls you are making, with all arguments exactly as you've written them. -- Doug Harrison [VC++ MVP] Eluent Software, LLC http://www.eluent.com Tools for Visual C++ and Windows
|
Mon, 30 Jun 2003 07:33:54 GMT |
|
 |
Josh Gibb #6 / 10
|
 _open not doing the right thing
Are you asking in the files that are created, or the flags I am sending to _open? Either way, yes the 'read-only' attrib is set on the actual files, but they are requested to be normal files in the call to create them. As I said, two are read-only, and one is read-write. The flags send into _open are exactly the same for all three files. I'm going to do a bit more hunting first before sending by code, as it is rather large. I've got to see if there are any other things that is making Windows spit it's dummy between the calls to the file open calls. Point to note though, this code is a straight recompile of code working on another OS - the code is fine and has been for the last three years. Josh Quote:
> Do those two files, by any chance, have "read-only" attribute set? > -- > With best wishes, > Igor Tandetnik
> > _open does indeed take sharing flags relating to the OS it comes > > from. That is a moot point anyway, as the three calls that are made > > within two functions - both called from the same parent function in > > the same code block - are opening the file with the same params. > > Just that two get RO & one gets RW? It's bizarre. I've actually > > modified the FileOpen call to hardcode the flags as well, but still > > no joy.
|
Mon, 30 Jun 2003 12:27:41 GMT |
|
 |
Josh Gibb #7 / 10
|
 _open not doing the right thing
Thanks, but the sharing is not actually required in this case and this is just a stub for making compilation compatible. I would also doubt that stdio functions have a bug in them, but, and I probably should've mentioned this, it is sitting in an MFC application, so who knows what other niceties I have been given for free. I'll post some code soon if I can't track down the problem - there is a lot of code so I will be needing to minimize it whilst keeping the bug before posting. Thanks, Josh Quote:
> >_open does indeed take sharing flags relating to the OS it comes > >from. > Not in VC++. You need _sopen to specify sharing modes. > >That is a moot point anyway as the three calls that are made > >within two functions - both called from the same parent function in > >the same code block - are opening the file with the same params. > >Just that two get RO & one gets RW? It's bizarre. I've actually > >modified the FileOpen call to hardcode the flags as well, but still > >no joy. > Well, _open is used by stdio, and I seriously doubt there is a bug in > such commonly used functions. > >Think I might be spending another day slaving over what should > >be a straight forward operation. > >Gee, thanks Microsoft!!! :-( > If you don't figure it out, post the exact sequence of calls you are > making, with all arguments exactly as you've written them.
|
Mon, 30 Jun 2003 12:35:33 GMT |
|
 |
Josh Gibb #8 / 10
|
 _open not doing the right thing
Ok, here's the latest. Confession: Found an ugly hairy 'size-of-a-bastetball' bug in the function that calls the open function. The permissions were being sent through in the wrong argument. That sorta explains the read only files and fixes the problem. Strangeness: The reason I did not pick up on this was because of the RW file being created, and that the flags sent through in that call were exactly the same for the RO file? This shouldn't be the case, but with several hundred thousand lines of code still to test I won't linger on the more ethereal aspects of VC coding. Thanks for your input people, Josh Quote:
> Thanks, but the sharing is not actually required in this case > and this is just a stub for making compilation compatible. > I would also doubt that stdio functions have a bug in them, > but, and I probably should've mentioned this, it is sitting > in an MFC application, so who knows what other niceties > I have been given for free. > I'll post some code soon if I can't track down the problem - > there is a lot of code so I will be needing to minimize it whilst > keeping the bug before posting. > Thanks, Josh
> > >_open does indeed take sharing flags relating to the OS it comes > > >from. > > Not in VC++. You need _sopen to specify sharing modes. > > >That is a moot point anyway as the three calls that are made > > >within two functions - both called from the same parent function in > > >the same code block - are opening the file with the same params. > > >Just that two get RO & one gets RW? It's bizarre. I've actually > > >modified the FileOpen call to hardcode the flags as well, but still > > >no joy. > > Well, _open is used by stdio, and I seriously doubt there is a bug in > > such commonly used functions. > > >Think I might be spending another day slaving over what should > > >be a straight forward operation. > > >Gee, thanks Microsoft!!! :-( > > If you don't figure it out, post the exact sequence of calls you are > > making, with all arguments exactly as you've written them.
|
Mon, 30 Jun 2003 14:45:17 GMT |
|
 |
Igor Tandetni #9 / 10
|
 _open not doing the right thing
I mean the attributes as known to a file system. You know, right-click on a file, choose Properties, there are three checkboxes: Read-only, Hidden, Archive near the bottom of the property sheet. What I'm asking is whether Read-only checkbox is checked on the two files that refuse to be opened other than as RO. From your answer I gather that they are indeed marked as Read-Only, while the third file, that can be opened as RW, is not so marked. If this is the case, I don't understand your problem at all. Read-only attribute is there for a purpose, you know, said purpose being not to allow opening the file for writing. Clear it (see SetFileAttributes or _chmod) if you need to write to those files. -- With best wishes, Igor Tandetnik
Quote: > Are you asking in the files that are created, or the flags I am > sending to _open? > Either way, yes the 'read-only' attrib is set on the actual files, > but they are requested to be normal files in the call to create > them. As I said, two are read-only, and one is read-write. > The flags send into _open are exactly the same for all three > files. > I'm going to do a bit more hunting first before sending by > code, as it is rather large. I've got to see if there are any > other things that is making Windows spit it's dummy > between the calls to the file open calls. > Point to note though, this code is a straight recompile of > code working on another OS - the code is fine and has > been for the last three years. > Josh
> > Do those two files, by any chance, have "read-only" attribute set? > > -- > > With best wishes, > > Igor Tandetnik
> > > _open does indeed take sharing flags relating to the OS it comes > > > from. That is a moot point anyway, as the three calls that are made > > > within two functions - both called from the same parent function in > > > the same code block - are opening the file with the same params. > > > Just that two get RO & one gets RW? It's bizarre. I've actually > > > modified the FileOpen call to hardcode the flags as well, but still > > > no joy.
|
Tue, 01 Jul 2003 03:33:24 GMT |
|
 |
Josh Gibb #10 / 10
|
 _open not doing the right thing
Hi Igor, I think you might have been misdirected on what I am doing. These are new files that I am creating, not existing ones, so I am deciding what attribs the files should have. It's almost like I'm calling _umask between file creations given that the flag sent to _open are identical, but I'm not, which is why it is so wierd. Josh Quote:
> I mean the attributes as known to a file system. You know, right-click on a > file, choose Properties, there are three checkboxes: Read-only, Hidden, > Archive near the bottom of the property sheet. What I'm asking is whether > Read-only checkbox is checked on the two files that refuse to be opened > other than as RO. > From your answer I gather that they are indeed marked as Read-Only, while > the third file, that can be opened as RW, is not so marked. If this is the > case, I don't understand your problem at all. Read-only attribute is there > for a purpose, you know, said purpose being not to allow opening the file > for writing. Clear it (see SetFileAttributes or _chmod) if you need to write > to those files. > -- > With best wishes, > Igor Tandetnik
> > Are you asking in the files that are created, or the flags I am > > sending to _open? > > Either way, yes the 'read-only' attrib is set on the actual files, > > but they are requested to be normal files in the call to create > > them. As I said, two are read-only, and one is read-write. > > The flags send into _open are exactly the same for all three > > files. > > I'm going to do a bit more hunting first before sending by > > code, as it is rather large. I've got to see if there are any > > other things that is making Windows spit it's dummy > > between the calls to the file open calls. > > Point to note though, this code is a straight recompile of > > code working on another OS - the code is fine and has > > been for the last three years. > > Josh
|
Tue, 01 Jul 2003 10:15:44 GMT |
|
|
|