matt wrote:I was, however, under the impression that writing files in an operating system built on 32-bit address space would run into a limit. But I guess the address translation idea solves that. I don't know. To be honest, I don't think I understand the whole concept properly.
The key point is that the CPU will only be appending small pieces of new data (frames) to whatever is already in the file. So the CPU doesn't ever deal with the full file contents. The filesystem layer will need to deal with >4G size, but not with the data itself. Doing >32-bit math on a 32-bit machine is no problem, it's only dealing with the entire contents that would be problematic. And since the camera just appends a couple of frames at the time, there's no problem.
For example, I know that the 4GB limit is inherent to FAT32, so he problem was solved with filesystems like NTFS and exFAT. But from the things I've read so far (I tried looking into this a few months ago) the cameras currently capable of using exFAT cards still cannot write files over 4GB. Several people pointed to OS limitations as a reason for that.
I really think I am missing something. Can anyone point me in the right direction here? Should popping an exFAT card in your camera inherently allow you to create files over 4GB?
In an ideal world, yes it should. But programmers very rarely if ever create ideal software, so in practise even if a lower layer (the exFAT filesystem) in theory would be capable of extended features, it's 1. not neccessarily implemented, and 2. not neccessarily the case that higher layers (writing video files) are able to take advantage of such features even if they were to exist. All software must be written to explicitly support any functionality that should be offered.
On a tangential note I see that Microsoft holds patents on exFAT, which is quite bad for interoperability between cameras and open source systems in particular. Of course since Windows and Mac OS X both support exFAT "nobody" cares about that.