Kenny said:
Daughter has TV which plays video direct from USB memory stick.
Home made AVI video came to 7GB, Windows told me not enough room
although there was over 10GB free.
Saved a WMV version of the same file which was 1.3GB but still got the
same message about not enough space, I believed FAT32 will handle files
up to 4GB.
The pen drive is FAT32 but can I change it to NTFS and will the TV still
recognise it if I do?
The TV is large screen Toshiba and pen drive is Sandisk Cruiser 16GB.
Advice appreciated.
Kenny Cargill
The only thing puzzling about your experience, is why the 1.3GB file
would not fit. That doesn't line up with any of the limits I've heard of.
Since its FAT, you can use fsutil for testing. Fsutil can create
empty files, for size testing purposes. One problem with that though,
is the geniuses at Microsoft, have fsutil generate "sparse" files when
an NTFS file system is encountered. So fsutil doesn't end up working
the same way as "mkfile" in Unix might. But on FAT file systems,
fsutil makes "real" files, no sparse stuff, and it takes an
appropriately long time to do so. If it makes sparse files on NTFS,
the command finishes virtually instantly, which means very few data
sectors are physically written. It means fsutil is unsuited for
usage as a "physical disk eraser", on NTFS.
(On FAT32, this should fail if you make the size one byte larger.)
fsutil file createnew c:\testdir\testfile.bin 4294967295
You can also use the port of "dd" for Windows, to test file system
capacity, and that one won't resort to sparse files if used on
NTFS for example. The syntax for the ported version might look like this.
This would create a 4095 megabyte file (if there was room
left on the file system for it to fit).
dd.exe if=/dev/zero of=C:\testdir\testfile.bin bs=1048576 count=4095
Done without limits, "dd" will run until it hits the file limit. This
wouldn't be a good idea on NTFS, because it will fill the entire
partition.
dd.exe if=/dev/zero of=C:\testdir\testfile.bin
I just tried that command on a FAT32 file system and the resulting
file size was 4,294,966,784 bytes, which is 512 bytes short of 4GB.
dd works in units of 512 byte sectors, which is why it stopped there.
The port of "dd" is here. I typically use version 0.5 of dd for testing.
http://www.chrysocome.net/dd
The examples above, run from a "cmd" or MSDOS window. In Windows 7,
you sometimes need to select "Run as Administrator", to get things to
work like they did in older versions of Windows. (I've had small
surprises running in the MSDOS window, under Windows 7, and it is
due to UAC.)
To open an MSDOS window, you can type "cmd" without the quotes, into
the start search box. You must cd or change directory, until you get
to the place you've got the copy of dd.exe, in order to run it.
Maybe a test like that, will uncover a different limit than the 1.3GB value.
I can't explain why that value popped up.
Paul