Custom Query (69 matches)
Results (13 - 15 of 69)
| Ticket | Resolution | Summary | Owner | Reporter |
|---|---|---|---|---|
| #23 | fixed | makefile updates to add clean and base directory makefile | ||
| Description |
I decided I wanted an easier clean so have added clean to the make files and created a base directory makefile. |
|||
| #24 | fixed | Trap in FS_FSINFO because of NULL "pBootFSInfo" pointer in pVolInfo | ||
| Description |
Recently I had a trap in FAT32.IFS and I tracked it down to routine "FS_FSINFO" in file "fat32.c". The trap occurred in version 0.9.13 version but the code is still unchanged in the current version 0.10.x. The trap occurred in this line of code: pAlloc->cUnitAvail = pVolInfo->pBootFSInfo->ulFreeClusters; The trap occurs because at this point, pBootFSInfo is NULL. The trap happened because OS2DASD/OS2LVM got confused of if a (removable) USB stick was present or not and the said USB stick was formatted with FAT32 filesystem. |
|||
| #25 | fixed | Binaries started from FAT32, become corrupted, if booted from FAT32 | ||
| Description |
When playing with our Team Boot/2 bootable fat32 flash disk, I noticed the following problem: when I booted from a fat32 volume (usually, flash disk), and trying to start binaries like format.com, wget.exe, from the same FAT32 volume, I get the error like "The file format.com cannot be run in OS/2 session". If I look into the binary, I now see it being zeroed, if I view it in the hex viewer. But some binaries don't get corrupted, like shutdown.exe. I sometimes see that shutdown.exe fail to start, but after some number of attempts, it gets started, but didn't become corrupted. As it is known, the binaries are opened by the kernel Loader component, with read-write access, so it could be potentially overwritten, and it got really overwritten. What is interesting, I tried to start binaries from a non-bootable FAT32 medium, and I did not had any case when it got corrupted. |
|||
