Possible bug in fopen...

[Anonymous]

I'm not sure if this is a bug or not...  

I'm running win200/sp4 on an amd system with 256mb ram.  

When I use fopen("filename.ext","r") from the stdio.lib to open a file that happens to be locked by another application it freezes my application and slams cpu usage right over to 100%.  The only exit from that state appears to be to use task manager to shut down my application.

It behaves normally when the file being opened is not locked.

Can anyone confirm this problem... or am I missing something again?

[Pelle]

I have tried it on Win2K, no SP, NTFS - at least this seems to work...

Pelle

[Anonymous]

I have tried it on Win2K, no SP, NTFS - at least this seems to work...

Pelle

Just tried it again on win2k/sp4.  The system has a number of smaller FAT32 partitions and one big NTFS one... I still get the same thing.

Opening an available file, the behavior is exactly as expected.

Opening a file that is in use by another process *should* return, null, and report an error saying the file is locked... Win error #32.  Instead it seems to jump into a tight loop (waiting for the file?) with 100% cpu usage... set off my system's heat alarm while I was fetching coffee!

I have your latest version, even tried re-installing it... I still I get the same thing. So I doubt the lib is corrupted.

Hmmmmmmmmmm.....  :?:

[Anonymous]

Hmmmmmmmmmm.....  :?:

Hi Pelle,
I think I found it... turns out it's because the exception handling was scrambling the filename... Giving fopen a bad pointer...

Sorry for the inconvenience.