А что tcopy не копирует файлы более 2 Gb ?

[init01]

В общем сейчас начальник озадачил, что не смоглося у него вчера скопировать с ленты файл размером гигабайт в 10. Говорит, что доходит до 2 Gb и всё. Причём последний блок, запись которого превысит переписываемый файл в 2 Gb, разрывает, и дописывает к файлу кусок блока до 2 Gb, а оставшийся кусок выкидывает.

Сам я не пробовал - завтра попробую попробовать - но в начальнику верю.
Пошарился в интернете сейчас - ничего интересного не нашёл.
И вообще не помню, чтобы у меня такие проблемы возникали, может просто не встречались большие файлы?

В общем озадачил он меня поискать может какая-то новая версия tcopy есть, либо достать исходник его, он отдаст программистам - может они найдут куда там возможность копирования lagrefile дописать.

Я не знаю на чём он пробовал, либо RedHat, либо Solaris, а я завтра на Solaris 8 буду пробовать. А сейчас просто теоретичеcки хочу поинтересоваться, чтобы завтра подготовленным быть, если реально такая проблема существует.

[and3008]

От софта, конечно зависит, но и от файловой системы тоже. Они имеют разные ограничения.
http://en.wikipedia.org/wiki/Comparison_of_file_systems

[init01]

В общем, поскольку не программирую уже больше 10 лет, трудно понять что именно надобно сотворить.
В исходнике tcopy
http://src.opensolaris.org/source/xref/ ... py/tcopy.c
нет тех функций, к примеру D_FILE_OFFSET_BITS, которые требуют отредактировать в этих документах
http://www.gnu.org/software/coreutils/f ... -data-type
http://www.sun.com/software/whitepapers ... efiles.pdf

И вообще не смотря на то, что проблема типа стара, я не нашёл ни в одном форуме или блоге, чтобы хоть кто-то описывал, что решил эту проблему. Я думаю за эти годы уже саму tcopy можно было переделать 300 раз.

В общем-то хочется понять что же требуется?
- либо отредактировать функции как для 64-разрядной системы, но ссылки оставить на 32-разрядные библиотеки;
- либо наоборот отредактировать оставить функции, но ссылки сделать на 64-разрядные библиотеки и установить эти бибилиотеки;
Потому что если редактировать всё, то не проще ли взять и скопировать tcopy из 64-разрядной системы?

Заранее благодарен!
Пните в нужном направлении, а то ваще туплю.

[init01]

Ещё несколько вопросов:
1. Почему в этом исходнике open() от 32-битной системы, а off64_t от 64-битной?
2. Надо всего лишь поменять open() на open64() и откомпилировать с помощью gcc -c -D_FILE_OFFSET_BITS=64 tcopy.c и всё? А какие-нибудь линковки нужны будут?

[and3008]

Судя по этой "смелой" конструкции: if (nfile && filen > nfile) break; программа может работать как угодно, потому что перменная nfile явно не инициализируется и потом в коде нигде не используется.

Ну и еще имеется ряд интересных мест, вызывающих как минимум удивление.

Другие реализиации tcopy такого глубокомысленного кода не имеют. Возможно в этом причина.

tcopy - древняя софтина и довольно простая. Допилите, как считаете нужным. Задача для ученика средней школы в общем-то.

[init01]

Да, всё получилось!

В исходнике поменял в двух местах open() на open64() и откомпилировал:
gcc -D_LARGEFILE64_SOURCE -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 tcopy2.c -o tcopy2

И на CentOS 5.2. и на Solaris 8 всё откомпилировалось без ошибок.

Но долго не удавалось проверить - не было доступа к ленточным устройствам.

Сегодня получил доступ на Solaris 8 и удалось скопировать с ленты на диск 10-гигабайтный файл.
Правда он всё равно что-то в конце гадостливое сказал на прощание:

file 1: records 223462 to 223463: size 512
file 1: records 223464 to 223523: size 64512
file 1: record 223524: size 52992
file 1: record 223525: size 4
file 1: record 223526: size 512
file 1: records 223527 to 223529: size 64512
file 1: record 223530: size 49824
file 1: record 223531: size 4
file 1: records 223532 to 223635: size 512
file 1: eof after 223635 records: 10195176924 bytes
Write EOF: Inappropriate ioctl for device

[and3008]

Файл закрыли не по правилам. Не по феншую в общем.
В общем, если интересно, допилите код закрытия файла. Надо доки просто прочитать внимательней про открытие файла, запись и закрытие.