SCOUG Logo


Next Meeting: Sat, Sep 21th, 2019
Meeting Directions


Be a Member
Join SCOUG

Navigation:


Help with Searching

20 Most Recent Documents
Search Archives
Index by date, title, author, category.


Features:

Mr. Know-It-All
Ink
Download!




SCOUG:

Home

Email Lists

SIGs (Internet, General Interest, Programming, Network, more..)

Online Chats

Business

Past Presentations

Credits

Submissions

Contact SCOUG

Copyright SCOUG



warp expowest
Pictures from Sept. 1999


The views expressed in articles on this site are those of their authors.

warptech
SCOUG was there!


Copyright 2019, Southern California OS/2 User Group. ALL RIGHTS RESERVED.

SCOUG, Warp Expo West, and Warpfest are trademarks of the Southern California OS/2 User Group. OS/2, Workplace Shell, and IBM are registered trademarks of International Business Machines Corporation. All other trademarks remain the property of their respective owners.

The Southern California OS/2 User Group
P.O. Box 26904
Santa Ana, CA 92799-6904, USA

June 2004


 Dear Mr. Know-It-All 

Mr. Know-It-All has the answers to even the really tough questions.


Question:

I have a 1GB FAT partition with a 12MB EA DATA. SF file. This seems extremely large to me. Is there something wrong with the partition and can I fix it?

Answer:

Yes. There is something wrong. As you probably know, on a FAT partition, OS/2 stores the EA data in the EA DATA. SF file. OS/2 stores an index to the EA data in an otherwise unused field of the directory entry. When creating a new EA, if there is no unused space in EA DATA. SF, OS/2 will append the EA data to end of EA DATA. SF. For unknown reasons, OS/2 sometimes gets confused about where EA DATA. SF ends and the new EA is stored far beyond the end of the existing EA data. The result is an EA DATA. SF file that is much larger than it needs to be.

To fix this problem you need to find the errant EA and move it elsewhere. If nothing else is corrupted, OS/2 will release the free space at the end of EA DATA. SF.

To find the errant EA, you can to use that SWISS-ARMY KNIFE of disk-tools, DFSee , and a couple of scripts. One DFSee command script and one REXX script.

  • The DFSee script writes a listing of all the files and directories in the partition to the log file FindBigEAIndex.log. The log reports the index of the EA within EA DATA. SF for each file that has EA data.

    If you want to check a drive other than C:, edit the script to point to the FAT drive you want to check.

    Run the DFSee script as:

      DFSee -b run FindBigEAIndex.dfs # q
    

  • The REXX script (provided here in a zipped file) reads the contents of the log file and lists the 10 largest EA index values. The REXX script was tested with DFSee version 6.08, so it might need minor updates if the list command format changes in future versions.

    Run the script as:

      FindBigEAIndex <FindBigEAIndex.log
    
    The output will look something like
    Top 10
      \0000063D.DIR\LTR\ has EA index 2144
      \000006BD.DIR\0110RP1.MMO has EA index 2143
      \00000405.DIR\TLIBWORK.TRK has EA index 2100
      \00000405.DIR\BITMAP.C has EA index 2099
      \000006BD.DIR\F0006TL2.DWP has EA index 2075
      \0000065D.DIR\TIFFSIZE.CMD has EA index 2074
      \000006BD.DIR\0005TL01.FAX has EA index 2058
      \0000053D.DIR\PWBED.EXE has EA index 2053
      \000006BD.DIR\0005MB02.FAX has EA index 2052
      \000006BD.DIR\0004RH01.FAX has EA index 2050
    
    The first item listed is probably the cause of the large EA DATA. SF file.

Unfortunately, the DFSee version 6.08 list command can not report the true pathnames. This may change in future versions. If you don't recognize the file, you may need to use the dir command to determine the full pathname. If there are only a few occurrences of the name this will not be much of a problem. Otherwise, you may want to use the output of the DFSee command:

  list -f
to determine the full names. Ask Mr. KIA if you need help deciphering the command output.

With DFSee version 6.08, the reported EA index value is not the true relative cluster number, so it is possible that the largest EA index value will not correspond to the largest EA cluster value. However, it usually will. A future version DFSee will probably support reporting the true relative cluster number, so this will become a non issue.

Once you have determined the full pathname use the EAUTIL commands:

  eautil pathname tmp.ea /s
  eautil pathname tmp.ea /j
to detach and reattach the EAs. The tmp.ea file will be destroyed, so if you happen to have a file tmp.ea that you do not want destroy, use a different file name. If all goes well, EA DATA. SF become much smaller. If not, boot to your maintenance system and run:
  chkdsk /f
on the drive. If EA DATA. SF still resists resizing, there are a couple of other options. If you need to discuss these, contact Mr. KIA directly.


Curious or in doubt, you can ask Mr. Know-It-All
OS/2 is his specialty and sharing solutions is his passion
Mr. Know-It-All lives in Southern California.


The Southern California OS/2 User Group
P.O. Box 26904
Santa Ana, CA 92799-6904, USA

Copyright 2004 the Southern California OS/2 User Group. ALL RIGHTS RESERVED.

SCOUG, Warp Expo West, and Warpfest are trademarks of the Southern California OS/2 User Group. OS/2, Workplace Shell, and IBM are registered trademarks of International Business Machines Corporation. All other trademarks remain the property of their respective owners.