home *** CD-ROM | disk | FTP | other *** search
/ OS/2 Shareware BBS: 28 Fixes4x / 28-Fixes4x.zip / hpfsfp10.zip / readme.txt < prev    next >
Text File  |  1999-09-08  |  2KB  |  34 lines
  1. Noticing some rather stange behavior with directories/folders after
  2. applying FP11 to OS/2 Warp 4, I decided to do a little research.
  3.  
  4. Did a search in IBMLink and got 4 hits on this problem dated 1993-1997.
  5.  
  6. They all involve failures when a program tries to access directories/folders
  7. but does not allow for the directory/folder having the Archive bit set as
  8. well Directory bit.
  9.  
  10. Unfortunately, there are several applications out there that have the
  11. problem, the application is no longer supported by its vendor, and the
  12. source is not available. One of the symptoms is disappearing folders
  13. even though the folder still exists.
  14.  
  15. In all but one of the reported cases, the real problem was in the
  16. application code and not the OS/2 file system. It appears to me that
  17. FP11 changes the way that OS/2 maintains the archive attribute on
  18. directories, and we now have a bunch of applications out there with
  19. incorrect coding. The case that involved an IBM fix dealt with HPFS386
  20. setting the Archive bit when it did an update to the ACL or EA of a
  21. directory entry.
  22.  
  23. Pursuing this thread, I decided to replace the FP11 HPFS.IFS and UHPFS.DLL
  24. with the corresponding modules from FP10. Don't know what I may have broken,
  25. but I have been running for since early this morning, and "dirfix all test"
  26. doesn't show any Archive bits set in directory entries. I have also noticed
  27. that I am not getting the WPS resets that I was getting on a fairly regular
  28. basis (maybe there is also some OS/2 code that is having the same problem?).
  29.  
  30. The dirfix.cmd in this archive can be used as a tool to determine if you
  31. have the problem and to reset the errant Archive attributes.
  32.  
  33. IBM has reported that this issue is scheduled to be resolved in FP12.
  34.