• Welcome to OS2World OLD-STATIC-BACKUP Forum.
 

News:

This is an old OS2World backup forum for reference only. IT IS READ ONLY!!!

If you need help with OS/2 - eComStation visit http://www.os2world.com/forum

Main Menu

eCS21 "destroys" the FAT32 partition. What can I do?

Started by eilygre, 2012.01.25, 20:32:21

Previous topic - Next topic

eilygre

I have run into a problem I don't know the solution for. I have WinVista, eCS20 and eCS21 installed. I installed eCS21 about a week ago. At the same time I resized the common FAT32 partition to 50GB using GParted (Linux).
After that I could access the common partition (F:) from Vista and eCS (both versions). But if I accessed the partition from eCS21 the partition became invisible in Vista. As long as I only used eCS20 everything was fine. I therefore reformatted the partition using DFSee. Again it was visible and accessible from all partitions. But again after accessing it from eCS21 it again was invisible in Vista. I found that Vista said it was not allocated! It is not possible to format Fat32 in Vista, so I downloaded a free ware program and formatted it in Vista. Now again: accessible in Vista, and after setting letter and name in eCS it was accessible in eCS as well.
But then again, after accessing it in eCS21 it was gone in Vista.
Any ideas what to do?

Einar Lygre

Pete

Hi Einar

Not sure what is causing the volume to become invisible to Vista - but, I'm told, you can format fat32 in vista using the command line:-

format [drive letter]: /FS:FAT32


I think I would delete the partition created using GParted and then create a new Volume in eCS2.1 using LVM. Then use DFSee to give it the correct partition type code. Finally, for the fun of it, see if the above command line will fat32 format that volume.


Regards

Pete



eilygre


Hi Pete.
Thank you for your answer. It seems to solve the problem, but not in the way we should expect. When I run the format command in Vista I got an error message: The partition is to big for FAT32.  Some documentation says that 32 Gb is the maximum size for formatting in Win. The documentation also says that the partitions can be a lot bigger if it is formatted with some other tool (as I did), but the different versions of Win handles this differently. In this case I think that eCS21 does something with the partition when it is bigger than 32 Gb, but I don't know what. I reduced the partition to 30 Gb and Vista accepts the partition now, even after its visit in eCS21.

Regards

Einar

DougB

Quotet seems to solve the problem, but not in the way we should expect.

Microsoft is trying to kill FAT32, because it doesn't work very well. NTFS is far better (stolen from IBM's HPFS, but without the reliability built in, but they did add journaling). Unfortunately, we have only one reasonable option for file system compatibility, and that is FAT32. VISTA was the ultimate attempt to kill FAT32, and it will refuse to format a disk larger than 8GB (I think) as FAT32, for no good reason than described above. Win7 seems to have backed off on that, and it will format a 16GB disk as FAT32 (possibly even bigger). Windows can, apparently, work with a 512 GB FAT32 disk, if you can get it formatted that way, but I think that our FAT32 driver has trouble with large FAT32 partitions (more than about 32 GB). Using 30 GB is far more space than I would allocate (I use 15 GB on my 512 GB disk, and I actually use about 1GB of it).

The answer for OS/2 or eCS, is to use DFSEE to format the drive as FAT32. Windows, and OS/2, seem to be happy with that. Other (windows) tools might create the partition with an incompatible geometry, that OS/2 doesn't understand.

By the way, I make two suggestions about FAT32 in OS/2, or eCS. One is: Do not use the EA support. EAs are sort of nice, in a few cases, but they are far from necessary on data disks. You will find that you have far fewer compatibility problems if you turn that feature off. Second, I recommend REMing the cachef32.exe line in config.sys. FAT32 works faster, and more reliably without the cache, especially if you use it with USB devices.

abwillis

Quote from: DougB on 2012.01.26, 07:41:32
Second, I recommend REMing the cachef32.exe line in config.sys. FAT32 works faster, and more reliably without the cache, especially if you use it with USB devices.
I tried turning off cachef32.exe after seeing your recommendation in another post for that and my speed dropped off dramatically with the latest Fat32 (to a Fat32 USB harddrive).  I then went out to the Fat32 yahoo group and found discussion that they had dramatically increased the speed with cachef32. 

Pete

Hi Einar

Different versions of windows have different fat32 max volume sizes.

I seem to recall that win2000 has 40Gb and xp has 32Gb - not sure about vista but guess it is the same as xp.

Probably the best answer is to use a tool like dfsee to overcome the volume size problem imposed on fat32 formatting in windows by windows :-)


No idea what eCS2.1 could do to upset the fat32 volume so that windows cannot use it though. I don't use fat32 myself anymore as I do not need to share data between ecs and windows but have had 40Gb fat32 volumes working fairly happily in the past.

I'm not familiar with GParted and wonder if using that tool to resize the fat32 volume was the initial cause of your problems - hence my suggestion to delete and recreate the fat32 volume using LVM.


Regards

Pete

Andi

I've FAT32 partitions with 250GB and 350GB on external USB drives which seem to work fine. Occasionally I share files between Win and eCS with that. I format either with DFSee or h2format (http://www.heise.de/software/download/h2format/40825)

DougB

I recently decided to try making windows (XP, and 7) hibernate, rather than shut down. That allowed Air boot to boot to eCS, with no apparent problems, then I could shut down eCS, and reboot to windows, which resumed normally. HOWEVER, If either system ever changed anything on the shared FAT32 drive, it would cause trouble. It seems that windows does not close out the file system, and keeps it in memory (which is written to disk, during hibernation, and restored again after). So, it may not update the file directory on the disk until after it starts up again. meanwhile, if you changed something in eCS, that changed the directory, but that was overwritten by windows on restart, your changes were lost, or worse. If you ever removed a file, using eCS, windows would get all upset because it has a directory entry for a file that isn't there anymore. Of course, this can happen in lots of different combinations, and the results are unpredictable (usually file system corruption). It seems to be necessary to do a complete shut down in windows, before using eCS. Perhaps that will give you some idea about what might have happened, and it may explain why not using the cache, in eCS, works much better. USB drives would be closed out when you remove them properly, which would alleviate the problem.

There may be a way to tell windows to write changes immediately, but I haven't stumbled across that yet.

eilygre

I don't think I will investigate more time on this since I have a solution I can live with, but I like to say that there never was a problem when I booted between Vista and eCS20. I could delete files and add files without any problem. But when I booted eCS21 the partition was gone in Vista and that even if I didn't do anything in eCS21 but open the partition to see what files were in there. I didn't open any files. Rebooting to eCS21or eCS20 and the partition was there with all its files, but, as I said, not in Vista. The IFS are identical in eCS20 and 21.

RobertM

Some of the information on how to disable the cache for certain drives can be located here:
Disable FAT32 Write Cache Windows 7


|
|
Kirk's 5 Year Mission Continues at:
Star Trek New Voyages
|
|