Я обнаружил, что lseek под Linux вернет ошибку, если вы будете искать за пределами максимально поддерживаемого размера файла для файловой системы, в которой находится файл, без необходимости записывать какие-либо данные.Вы можете выполнить простой двоичный поиск, чтобы получить максимальный поддерживаемый размер файла.Обычно это первая степень двойки, которая вызывает ошибку поиска -1, поэтому просто смещайте влево 0x1 в цикле, пока fseek не вернет ошибку, а затем попытка получить результирующее значение -1, вероятно, быстро доставит вас туда.Просто убедитесь, что вы скомпилировали свой код с -D_FILE_OFFSET_BITS = 64 или используете устаревший -D_LARGEFILE64_SOURCE и используете lseek64.
Это, похоже, не работает под Windows или OS X. Кажется, что lseek не делает границпроверка в этих реализациях.До сих пор лучшее, что я смог сделать в c ++, - это посмотреть на строку типа файловой системы, возвращаемую GetVolumeInformation в Windows, или на 64-битную версию fstatfs в OS X, и вернуть теоретический предел и надеюсь, что я не побежал клюбые ранее неизвестные файловые системы.Убедитесь, что в OS X вы определяете _DARWIN_USE_64_BIT_INODE при компиляции.Использование NSURL и получение значения ресурса NSURLVolumeMaximumFileSizeKey, как упомянуто ниже, похоже, требует реализации Objective-c и не работает для моих нужд.
Создание большого файла каждый раз, когда вы монтируете новую файловую систему, VIA USB не былприемлемое решение.Мои попытки сделать это привели к длительным зависаниям, поскольку ОС молча обнуляла сектора между ними.Я не мог даже обрезать или отсоединить файл, пока операция не была закончена.Насколько вы были бы злы, если вы подключили USB-накопитель, чтобы загрузить на него файл только для того, чтобы приложение, которое вы используете, зависало на 10 минут, пока оно пыталось проверить максимальный размер файла?Как приложение справится с ситуацией, когда диск был почти заполнен, когда он был впервые подключен?
Было бы очень хорошо, если бы fstatfs вернул эту информацию.