Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I recently purchased a 32GB USB 3 stick that was formatted FAT32. I plugged it into my computer and attempted to copy a film onto it, the file was over 4GB however and it would not let me copy the file across because of the 4GB file size limit imposed by FAT32.

After some googling I found that I could format my USB stick to have an exFAT format which would mean I could put files onto the stick greater than 4GB in size and the drive would work on both my Mac and my PC.

The problem with this solution is that my PS3 cannot detect the USB stick when it is formatted with exFAT.

I would like to know if there is a way I can have my USB stick formatted so it can have files greater than 4 GB and work on my PC, Mac and PS3.

share|improve this question

10 Answers 10

up vote 9 down vote accepted

Unfortunately, there is no way to copy a >4GB file to a FAT32 file system. And a quick google says your PS3 will only recognize FAT32 file systems.

Your only option is to use smaller files. Maybe chop them into pieces before moving them or compress them.

I would try a networked solution to file sharing.

share|improve this answer
    
Yup, this is the plan. I was hoping a stick would provide a short term solution. Thanks anyway. – Aesir Jun 23 '12 at 7:30
    
If you want to try something, it's more likely that a PS3 will support NTFS as compared to exFAT. You can try formatting your memory stick NTFS just in case the PS3 will see it. But I don't think you'll have much like. It's just what I would do in this situation if I were being stubborn. – OmnipotentEntity Jun 23 '12 at 7:32

Natively, you cannot store files larger than 4 GB on a FAT file system. The 4 GB barrier is a hard limit of FAT: the file system uses a 32-bit field to store the file size in bytes, and 2^32 bytes = 4 GiB (actually, the real limit is 4 GiB minus one byte, or 4 294 967 295 bytes, because you can have files of zero length). So you cannot copy a file that is larger than 4 GiB to any plain-FAT volume. exFAT solves this by using a 64-bit field to store the file size but that doesn't really help you as it requires a reformat of the partition.

However, if you split the file into multiple files and recombine them later, that will allow you to transfer all of the data, just not as a single file (so you'll likely need to recombine the file before it is useful). For example, on Linux you can do something similar to:

$ truncate -s 6G my6gbfile
$ split --bytes=2GB --numeric-suffixes my6gbfile my6gbfile.part
$ ls
my6gbfile         my6gbfile.part00  my6gbfile.part01
my6gbfile.part02  my6gbfile.part03
$

Here, I use truncate to create a sparse file 6 GiB in size. (Just substitute your own.) Then, I split them into segments approximately 2 GB in size each; the last segment is smaller, but that does not present a problem in any situation I can come up with. You can also, instead of --bytes=2GB, use --number=4 if you wish to split the file into four equal-size chunks; the size of each chunk in that case would be 1 610 612 736 bytes or about 1.6 GiB.

To combine them, just use cat (concatenate):

$ cat my6gbfile.part* > my6gbfile.recombined

Confirm that the two are identical:

$ md5sum --binary my6gbfile my6gbfile.recombined
58cf638a733f919007b4287cf5396d0c *my6gbfile
58cf638a733f919007b4287cf5396d0c *my6gbfile.recombined
$

This can be used with any maximum file size limitation.

Many file archivers also support splitting the file into multi-part archive files; earlier this was used to fit large archives onto floppy disks, but these days it can just as well be used to overcome maximum file size limitations like these. File archivers also usually support a "store" or "no compression" mode which can be used if you know the contents of the file cannot be usefully further losslessly compressed, as is often the case with already compressed archives, movies, music and so on; when using such a mode, the compressed file simply acts as a container giving you the file-splitting ability, and the actual data is simply copied into the archive file, saving on processing time.

share|improve this answer
    
Thanks this solves the problem. – 09stephenb May 23 '14 at 12:43
    
File splitting is as old as size limits. All that has changed over the years is the partition size limit and max file size :) – gbarry May 24 '14 at 16:02
    
@gbarry Indeed. Edited to make that point less presumptuous. – Michael Kjörling May 24 '14 at 16:07
    
This sloves the question, but not if OP wants to use it on his PS3. – redbeam_ May 27 '15 at 14:58
    
@redbeam_ This answer was originally posted on a different question which didn't include the PS3 constraint, and which was later merged with (not merely closed as duplicate of) this question. – Michael Kjörling May 27 '15 at 20:56

Expanding on Michael's idea, many compression utilities/formats support a "store" mode, where they don't actually do any compression. Most of those same utilities also support splitting into multiple archives. Combine the two, and you can split a file without wasting a bunch of time compressing it. I've used this technique myself to overcome the exact problem you're having.

One big advantage to doing it this way is that the compression format acts as a wrapper, keeping you from accidentally doing anything with only one part of the file. It also tends to be simpler for non-technical users. (Not everyone knows how to cat files, but almost everyone can open a zip.)

Of course, if you actually want to be able to work on the separate files, this doesn't work as well. This may be important if you don't have any "scratch space" to write the final file to. In that case, you should just split the file.

Here's an example of splitting a file using zip on Linux:

zip -0 -s 3g out.zip foobar

# "-0" sets the compression level to 0, or store
# "-s 3g" sets the split size to 3 GB
# Add "-r" if "foobar" is a directory
# The output will be "out.zip", and "out.z01", "out.z02", and so on...

If you're more of a GUI person, my goto has always been 7-Zip.

share|improve this answer

As answered by others splitting the file and joining works. But the easiest solution is to use ext 2/3/4 file system for your usb drive. It the native filesystem for linux. In windows use ext2fsd for reading the data. It also support write mode. Just install the free app on windows access file, no splitting , no joining.

share|improve this answer
    
Hard to see how this would help on a PS3. – ChrisInEdmonton May 27 '15 at 13:31

Another option not stated would be to use partitions. A USB flash drive is most often treated by the OS as a hard drive. Resize the FAT32 partition and make an exFAT (or other supporting filesystem) partition that is large enough to hold the file.

If you ever need to access the large file in place on the USB drive, this is probably the best solution. If all you need to do is transfer the file, and don't mind having to copy it to the hard drive to use it, the splitting solution is probably better.

This won't work if your USB drive is setup as a "super floppy," but this is increasingly uncommon. You can convert a "super floppy" into a hard drive format by using a partioning tool such as fdisk or gparted. But it will probably involve copying the files off, converting, copying them back, and then making the drive bootable again.

share|improve this answer
    
Pretty much all my drives I use with Linux have an ext partition hidden somewhere on them. It's the best way to solve all the little problems that show up using any "non-linuxy" partition. – jpfx1342 May 24 '14 at 18:37

Have you tried HFS+? It is the filesystem used on Macs. Don't laugh. It seems to work on the Xbox, so it's worth a try.

Get Past The 4GB File Limit On An External Hard Drive For The Xbox360

It might be implemented because it is also used on (some) iPods that are widely popular, so even M$ Xbox360 seems to read it. With appropriate software on PC, IF it works on the PS3, you'd get get a universal solution.

share|improve this answer
    
Thanks I have solved the problem now with a media server, but I will keep this in mind if the problem does come up again, thanks. – Aesir Sep 18 '12 at 19:38
1  
This won't work on the PS3, which does not support HFS+. – ChrisInEdmonton May 27 '15 at 13:31

This works – follow my steps:

  • Download WinRAR

  • Right click to the file that you want to copy and select "Add to archive"

  • On the bottom-left side of the popup box, write down split to volume size number, for example if your file is 4.63 GB you can write down 3 GB in the box, and click OK.

  • Wait for it to finish

  • Now copy all the files to USB

  • Now select the first file "XXX.part1", right click and click "Extract here"

  • It should extract your file.

share|improve this answer

I needed to move a 15.5gb virtual environment. I removed the partition on the usb key (32GB) and made a new one that was extn4 (linux), mounted it as 32GBkey moved the file. Booted the machine that needed the file using knoppix live (linux disc), mounted the key, moved the file.

Then umounted the key, changed the partition back to vfat.

share|improve this answer

I have found that using Adobe Bridge (if it is available to you) will bypass the 4GB limit on our servers. This can be done simply by "drag and drop" from the OS launcher into the bridge client window. Works for large (15gb+) video files where I work.

share|improve this answer

FAT32 has a hard limit for how every file is listed (32bit field for file size). However, applications that bypass this limit use more fields. In theory, this can bypass the hard limit, but requires placement of the next fields immediately following the first, and linking the end of the first to the beginning of the next as if it were part of the file (it reads that end sector, and gets another file bitfield message from the second field) which is usually handled by PC operating systems alright, but not always.

Other programs move files in chunks of 600mb to 2gb and use a flag bit, then use multiple bitfields for the chunks, though all is seen as a single file; such is the case with adobe software, especially with video files. It segments the files, and creates a bitfield for each segment for video\audio that is read by the os as a single file. These files are simply wrappers, a folder of sorts that wraps around a set of images, or samples that are quickly cached into memory for playback. The DVD standard VOB is another great example that shows where this comes from and why. Its cut into chunks of quickly cached files for playback on DVD players. They use the old UDF1 or joliet format, which borrows from HFS, but uses mostly FAT capable lists. The file size limit is roughly 2gb, mainly for caching speeds of DVD player set-top-boxes. Most often it is in 1\10th to 1\5th of that limit, and multiplexed audio and video chunks are cached together very quickly, for playback.

The answer to this problem isn't complex, but it isn't one size fits all. For the specific question, use a splitter program; WinRar, 7zip are great, and have a gui. It's a simple answer and works well. The OS (operating system) will set the file to use multiple fields, and multiple chunks, but it will be seen as one file after the merge. With many compressed video files (almost every format is a compressed format by one algorithm or another), the read speeds for FAT are fast enough to playback on most smart TV's, or minimal OS Console systems (PS3\4, XBOX, etc). Other files like ISOs etc, not as capable unless in DVD format for video, which is a heavily cached format anyway. For game ISOs, check ntfs, and a few other formats your computer can build on the USB drive, and then try it with no split actions.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.