Custom Query (69 matches)
Results (13 - 15 of 69)
Ticket | Resolution | Summary | Owner | Reporter |
---|---|---|---|---|
#62 | fixed | CACHEF32.EXE no longer respects the /S parameter | ||
Description |
Using build 0.10.r288. CACHEF32.EXE displays the message: FAT32: Unicode translate table for codepage xxx loaded. even when the /S (silent) switch is specified. This is a regression to a long-running bug which was present in FAT32 builds 0.9.12 and earlier. This was fixed in 0.9.13 and the /S switch functioned as expected in that and later versions until the appearance of this regression. |
|||
#61 | fixed | SVN rev 299: newview.exe crashes on searching in IFS.INF | ||
Description |
I realized that IFS.INF has been enhanced with previously missing information about 32-bit entry points and enhanced system structures to support 64-bit file sizes and file offsets (which of course is a good thing). Unfortunately, the created IFS.INF is no longer searchable via newview.exe. I searched for term "FS_NAME" and newview.exe crashed. I would be good if IFS.INF would be rebuilt. Maybe Watcom's wipfc.exe has a bug. Maybe it needs to be rebuilt with ipfc.exe from the IBM OS/2 toolkit (just a guess). |
|||
#60 | fixed | SVN rev 298: exFAT formatted media shows wrong filesystem type in WPS, files do not show up on commandline | ||
Description |
1) formatted a USB stick as exFAT under Windows. It is a partitioned stick. 2) enabled exFAT support in FAT32.IFS by specifying /exfat switch 3) copied some files via WPS onto the stick.
I can see and access the files via WPS. However the drive's details view shows "FAT32" as the filesystem (it was my expectation that it would show "exFAT"). [h:\]chkdsk h: /F The current hard disk drive is: H: The type of file system for the disk is FAT32. The FAT32 file system program has been started. FAT32: Unicode translate table for CP 437 loaded. FAT32 version 0.10.r298 compiled on Jul 28 2017 The Volume Serial Number is F8D9-E086. The type of file system for the disk is exFAT. CHKDSK is checking fats :Ok. CHKDSK is checking files and directories... CHKDSK is searching for lost data. CHKDSK has searched 100% of the disk. The correct free space is set to 122759 allocation units 3928512 kilobytes total disk space. 32 kilobytes are in 1 directories. 96 kilobytes are in 3 user files. 0 bytes in 0 hidden files. 32 kilobytes are in extended attributes. 3928288 kilobytes are available for use. 32768 bytes in each allocation unit. 122766 total allocation units. 122759 available allocation units on disk. 0% of the files and directories are fragmented. This is somewhat confusing as first it is claimed that the filesystem is FAT32 whereas the second message claims it is exFAT. However the most annoying problem is that no files are listed when I do a "dir" on a commandline. This is what I get from an OS/2 commandline: [D:\]dir h: Volume in drive H has no label. The Volume Serial Number is F8D9:E086. Directory of H:\ SYS0111: The file name is too long. A 4OS2 commandline will give a different error but in any case, no files will be shown even though the WPS shows them just fine: [d:\]dir h: Volume in drive H is unlabeled Serial number is F8D9:E086 SYS0002: The system cannot find the file specified. "H:\*" 0 bytes in 0 files and 0 dirs 4.022.566.912 bytes (3.836MB) free |