Custom Query (69 matches)

I have files on a FAT32 drive (USB stick) that seemingly have no file time/date stamp.

In the WPS they show up with a date of 00.00.1980 and a time of 00.00.00 (in other words: all time and date fields set to zero), in a commandline directory listing it looks like this:

[L:\]dir

Volume in drive L has no label.
The Volume Serial Number is 862F:23B7.
Directory of L:\

       935.244    223 a---  alcor.zip
17.03.05 21.09        144.085    358 a---  df_ret.exe
11.08.05 11.52        544.188    224 a---  kernel.$$$
17.03.05 21.09         59.366    224 a---  kernel.sdf
11.08.05 11.52        545.512    225 a---  kerneld.$$$
17.03.05 21.09         59.617    225 a---  kerneld.sdf
28.12.16 10.28          9.476    223 a---  mouse.sym
28.12.16 10.28         32.560    357 a---  mouse.sys
 8.03.02 17.59        189.354    223 a---  shell.$$$
 8.03.02 17.59         21.279    223 a---  shell.sdf
 7.01.17  9.36     28.409.056    222 a---  usb.pcap
 7.01.17  9.36         76.931    222 a---  VBox.log
       889.307    221 a---  usb.zip
29.07.17  9.33             20    128 ----  CHKDSK.OLD
29.07.17  9.33             20    128 ----  CHKDSK.LOG
       15 file(s)  31.916.015 bytes used
                   15.774.121 K bytes free

look at files "alcor.zip" and "usb.zip": they are lacking a file date/time ...

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").
When I run a chkdsk via the drive I get this:

[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

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).