id,summary,reporter,owner,description,type,status,priority,milestone,component,version,resolution,keywords,cc 156,Opening multiple instances of FM/2 brings up a readonly attribute error message,guest,,"FM3.ini was being marked readonly. Opening up multiple instances caused a readonly error message to pop up. The file causing this was the init.c file located in the dll subdirectory of the trunk. Changes were made, nothing that should have caused this problem. It appears that we have stumbled upon a 32-bit code defect in the kernel which I can now reproduce on demand. Here's the testcase output DosQueryPathInfo J:\SLA_DEV2\FM2.DEV\test\fm3.ini returned 0 DosSetPathInfo 00160000 J:\SLA_DEV2\FM2.DEV\test\fm3.ini returned 0 DosQueryPathInfo J:\SLA_DEV2\FM2.DEV\test\fm3.ini returned 0 DosSetPathInfo 0015fffc J:\SLA_DEV2\FM2.DEV\test\fm3.ini returned 123 The hex value is the address of the FILESTATUS3 buffer. I've suspected that was the problem all along, but overlooked the location of the FILESTATUS3 buffer and kept looking at the filename buffer. Oh well. DosSetPathInfo is a 32-bit wrapper for the original 16-bit code. The way this supposed to work is that the 32-bit wrapper is supposed to ensure any 16-bit alignment rules are followed. Bad luck had is that in the 3.0.7 build, the FILESTATUS3 buffer crossed a 64K boundary and the 32-bit wrapper code does not handle this properly. Anyway, I will be committing an update to init.c that works around this. Fortunately, DosSetPathInfo is not used a lot, so there's not a lot to fix. Now that I know where the failure is located, I knew what to look for to make sure I had not just rediscovered and know issue. There was some discussion on comp.os.os2.programmer about a defect in DosSetPathInfo that was fixed by the 14.104 kernel, but it not our specific problem. Is anyone with the INI rewrite error running this kernel or 14.104a? It would be nice to know if the updated kernel fixes our problem too.",defect,closed,major,Release_3.7,fm/2 base,3.08,fixed,,