hi everyone. i googled and searched through the forums with no luck. my questions:

-how can i convert my external hard drive from ntfs to fat 32 in linux?

- i read on a few boards that if i do in fact convert to fat32, then i may not be able to transfer files onto my external larger than 3 gigs (something like that). is there any truth to that and if so, how can i get around it?

i just installed linux (ubuntu edgy eft) and just discovered that i can only read my files, but not write to my disk because it is in ntfs format. i already removed all files from my external so there's no issue in reformatting it with me. i've searched all over for the answer, but most have to do with converting from fat32 to ntfs, and not the other way around.

any help would be greatly appreciated!

1) You can use the mkfs utility to create a Win32 FAT file system on a disk partition. The file system type is called vfat in Linux. Here is an example that would create a Win32 FAT file system on /dev/sda1.
It seems that I always have to include the -I parameter or the mkfs utility will refuse to format the partition.

2) The limit of file size on any given file system is determined by the maximum number of block maps allowed times the size of the blocks. On Unix-like file systems the block maps are called inodes. There is a structure on Win32 FAT file systems that does the same thing. These block maps are all allocated when the file system is formatted. In terms of limiting the size of files on the file system let's say that the file system only allowed 1024 blocks to be mapped to a file and those blocks were 1024 bytes then you would be limited to 1 MB in file size. So the key to allowing larger file sizes is to increase either or both of the number of blocks allowed per file and the size of those blocks. These parameters can be set in the Windows Disk Administrator and in the Linux mkfs utility. See the man page for the parameters to the mkfs utility when you format the partition.

Keep in mind that if you allow a lot of blocks to be mapped to any individual file then you will use more disk space making room for those block maps (inodes). If you allow larger block sizes then you will waste more disk space when you store small files. These issues fall under the heading of file system tuning. There are a lot of things that you can do to "tune" a file system to meet your requirements. Any tuning involves making trade offs. If you want large files then you will want to create a file system with large blocks. However, when you store small files on that file system you will waste whatever part of a block that is not used for each file. That could be as much as the block size minus one byte because the file system could require an entire block just to store one byte of data. (I am deliberately ignoring the fact that file/user data for very small files can be stored in inodes in Unix-like file systems because I want to keep the explanation simple yet thorough.)

So file system tuning can be interesting. Most people ignore it because the default values set by disk utilities are often good enough most of the time. It is only when you have a requirement that cannot be met using the default file tuning values that you have to look into this sort of active tuning.

fat32 limits is 4gig minus 2 bytes for maximum file size. But that follows the info from stress junkie's post. Windows can read files this size but cannot write them that large from last I known.

Brian

You would be better served to keep the NTFS filesystem as was stated you can not write a file to FAT 32 that is larger than 4GB. Check out the NTFS-3G Read/Write Driver
for your distro.
I use it with Fedora Core 6 with no problems on internal and external usb NTFS formatted drives.

I just got done converting from ntfs to FAT32 and I regret it: http://www.linuxquestions.org/questi...=1#post2587429 I hear writing to ntfs works well under Linux...I'll try it out this week, probably that 3G driver mentioned in this post. FAT32 cat hit 2TB(or better yet Linux can make a 2TB FAT32 hardrive and windows cannot).

i know this is a late response but first off, thanks for thos of you who replied. I still haven't switched to fat32, mainly because I haven't had time. Although if I did, I don't think the 4gb limit would be a problem for me - I don't think I've ever transferred that much data at one time.

I am planning on using partition magic (when and if I decide to go to FAT32) on my Windows XP laptop so that I can make that change.

This too is a late response but maybe it can help someone.

I initially started off with a Seagate FreeAgent USB HD. It was formated for NTFS. But my Linux boxes would not work with it. Oh, they coud see it and mount it but that's about all. So I reformatted it for ext3. But then my Debian/Lenny couldn't write to it. So what to do?

I purchased an enclosure for a spare HD I had. Cost: 20 bucks and of course I already had the HD. After a lot of research, like you, I felt the 4Gb limit should pose no problem. I can't think of any file I have at the moment that exceeded that limit. Or that I can't break up into less than the 4Gb limit.

So I formatted my USB enclosure with the spare HD for Fat32. No problem from any of my Linux boxes recognizing nor mounting and copying to this USB HD. Maybe if and when I want to copy movies, which are usually larger, this will be a problem. But for now, the Fat32 format serves me well. And I can move this USB HD to my Windows PC and copy from and to it.

By the way, it was my 'discovery' that thumb flash drives are also formatted for Fat32 that led me to do the same with my USB HD. If I had know this I would have formatted the Seagate USB HD to Fat32 and be done with. Oh well, we all learn the hard way. It's really the best way. Now I know. Next up: NTFS with Linux. Now that's going to be a hair puller and teeth gnasher.

Not if you use the NTFS-3G driver. Works beautifully for me.

Doubt it, most rippers break the VOBs into 1GB chunks. I'm surprised Debian had trouble with ext3? I had no idea and I'm thinking of going to Kubuntu soon.

There must have been something else going on if Debian couldn't read ext3 as that is the native Linux filesystem that the Debian installer even formats to.