Custom Query (69 matches)
Results (22 - 24 of 69)
| Ticket | Resolution | Summary | Owner | Reporter |
|---|---|---|---|---|
| #14 | fixed | Finish fat32format port from Win32 to OS/2 and fix some fat32.ifs traps caused by this port | ||
| Description |
Now fat32format is mostly ported to OS/2 (now not yet finished, present in 0.10 branch of fat32.ifs). Also, fat32.ifs is modified accordingly (added missing MOUNT_ACCEPT and modified MOUNT_VOL_RELEASED, MOUNT_RELEASED flags for FS_MOUNT, etc.). FORMAT entry is added to ufat32.dll, and "format x: /fs:fat32" is mostly working. But when OS/2 booted from fat32 (OS/2 bootable flash), and trying to format another partition to fat32, a trap occurs. |
|||
| #19 | fixed | Handle the case of disk driver, supporting strat1 only | ||
| Description |
It appears that fat32.ifs requires the disk driver with strat2 support, and it uses it in the cache code to queue the i/o requests. But it assumes that strat2 is supported, and we'll get a trap in FS_MOUNT in case it isn't. The drivers supporting strat1 only, do exist, for example, it is hd4disk.add driver for PAE ramdisk. It uses it because strat1 is simpler, and faster. Actually, hpfs.ifs works almost 10 times faster with strat1 switch given to hd4disk.add. So, we need to handle gracefully the case of the disk driver, supporting strat1 only. -- We can just refuse to mount if the disk driver is strat1 only. This should be easy, but the full support for using strat1 only is harder to implement (need to change the cache logic) |
|||
| #70 | fixed | IBMWorks database fails to open | ||
| Description |
Using FAT32.IFS release 336 and opening the addressbook (aka phone) feature of IBMWorks the application opens with an apparently empty database. It works fine in R290 and shows a populated database the database is not damaged by the failure |
|||
