idFTP и большие файлы

← →
yuriks (2006-10-25 12:14) [0]

Для закачки файла с FTP сервера использую idFTP.

Для отображения хода выполнения закачки использую OnWork

procedure TForm1.FTPWork(ASender: TObject; AWorkMode: TWorkMode;
AWorkCount: Integer);

количество считанных байт - AWorkCount
но оно Integer а не Int64
то-есть не подходит для больших файлов (> 2Gb)

Как решить проблемку ?

← →
Dmitrij_K (2006-10-25 12:17) [1]

переписать модуль

← →
Сергей М. © (2006-10-25 12:25) [2]

> Dmitrij_K (25.10.06 12:17) [1]

Это еще зачем ?)

AWorkCount - это же не тотальный размер файла, а размер данных, участвовавших в текущей итерации чтения/записи данных

← →
Сергей М. © (2006-10-25 12:48) [3]

> yuriks (25.10.06 12:14)

IdFTP не имеет опубликованного свойства-события OnWork.

?

← →
yuriks (2006-10-25 12:48) [4]

> Сергей М.
> AWorkCount - это же не тотальный размер файла, а размер
> данных, участвовавших в текущей итерации чтения/записи данных

только не "в текущей итерации " а в текущей "сесии"
то-есть сумарный !
Когда он переваливает за 2Gb лезут отрицательные числа !

← →
Сергей М. © (2006-10-25 12:49) [5]

> yuriks (25.10.06 12:48) [4]

Ответь на вопрос в [3] ..

← →
yuriks (2006-10-25 12:52) [6]

Он в нем наследуемый
TIdTCPConnection.OnWork Event

← →
Сергей М. © (2006-10-25 12:55) [7]

> yuriks (25.10.06 12:52) [6]

он-то наследуемый)

А вот ты как умудрился назначить этому защищенному св-ву-событию свой обработчик ? Ты же не наследовал TIdFTP, судя по приведенному коду ...

← →
yuriks (2006-10-25 13:01) [8]

Просто выбрал в Object Inspector - Events - OnWork

← →
Сергей М. © (2006-10-25 13:20) [9]

А... ну да, понял... Корявая справка к Indy9 не упоминает событие OnWork в кач-ве опубликованных.

Ну тады поясни, откуда ты взял, что "суммарный" ?

← →
yuriks (2006-10-25 13:25) [10]

на его значения смотрел + выводил значения на форму

← →
Сергей М. © (2006-10-25 13:27) [11]

И чему при этом равно значение св-ва TIdTCPConnection.RecvBufferSize ?

← →
yuriks (2006-10-25 13:42) [12]

значение FTP.IOHandler.RecvBufferSize = 32768
оно не меняется

а AWorkCount растет постоянно на это значение!

← →
Сергей М. © (2006-10-25 13:48) [13]

Так.

Во избежание недоразумений давай определимся: я веду речь о 9-ке, а ты ?

← →
yuriks (2006-10-25 13:53) [14]

10
но я думаю это не важно

← →
Сергей М. © (2006-10-25 14:02) [15]

Концептуально действительно не важно.
Но у меня нет под рукой исх-ков 10-ки.

← →
Сергей М. © (2006-10-25 14:45) [16]

Не смотря на [15] смею утверждать. что ни один "нормальный" FTP-клиент не будет запрашивать к передаче "за один прием" такой большой объем данных.

← →
yuriks (2006-10-25 14:55) [17]

Но почему же не будет ?!
Например iso-шка DVD диска.

← →
Сергей М. © (2006-10-25 14:57) [18]

> yuriks (25.10.06 14:55) [17]

Ерунду ты сейчас сморозил)

← →
yuriks (2006-10-25 15:02) [19]

не понял?

← →
Сергей М. © (2006-10-25 15:06) [20]

Ну что там м.б. не понятно ? для FTP-клиента существуют просто файлы, а их содержимое (будь там хоть "iso-шка", хоть "хрено-шка") FTP-клиенту по-барабану, потому как читай спецификацию FTP.

← →
yuriks (2006-10-25 15:10) [21]

> Не смотря на [15] смею утверждать. что ни один "нормальный"
> FTP-клиент не будет запрашивать к передаче "за один прием"
> такой большой объем данных.

Вот я и говорю что для меня "нормально" качать как ти сказал "за один прием" один файл размером > 2Gb !

← →
yuriks (2006-10-25 15:11) [22]

Ладно, забудь.
Решу по другому !

← →
Anatoly Podgoretsky © (2006-10-25 15:14) [23]

> что ни один "нормальный" FTP-клиент не будет запрашивать
> к передаче "за один прием" такой большой объем данных.

Не вижу никаких проблем, часто качаю по 4-8 гб за раз.

← →
Сергей М. © (2006-10-25 15:15) [24]

> для меня "нормально" качать как ти сказал "за один прием"

Ну и нахрен тебе тогда OnWork-событие, спрашивается ?)

Оно ж как раз и существует для прогресс-индикации, как это обозначено в справке.

Ну и какая нахрен прогресс-индикация м.б., если recv() запросит сразу весь многогигабайтный объем данных ?

думай головой-то... думай ... чешим репу-то)...

← →
Сергей М. © (2006-10-25 15:15) [25]

> Anatoly Podgoretsky © (25.10.06 15:14) [23]

ты бы хоть въехал что ли в сабж для начала)...

← →
Anatoly Podgoretsky © (2006-10-25 15:16) [26]

Сергей М. © (25.10.06 15:15) [24]
Нормальная движется, но медленнее, чем на 8 мб файле.

← →
Anatoly Podgoretsky © (2006-10-25 15:17) [27]

Это тебе надо въехать прежде чем делать такие необдуманые заявления.

← →
yuriks (2006-10-25 15:18) [29]

Сергей М., по моему как раз ты и не вьезжаеш !

> yuriks (25.10.06 15:18) [29]

Сколько раз у тебя вызывается OnWork ?

← →
yuriks (2006-10-25 15:27) [31]

Например, если размер файла 2,5 Gb = 2684354560 b
то OnWork будет вызыватся 2684354560 / 32768 = 81920 раз

А значения AWorkCount будут такими
32768
65536
98304
...
2147450880
-2147483648
-2147450880
...

> yuriks (25.10.06 15:27) [31]

Ну и ?
Вот тебе и итерация - OnWork вызывается в цикле.

Даже если "глюк" в этом индейском компоненте, ты берешь эти самые 32к (дифолт) , суммируешь с Progressbar.position - вот тебе и прогресс !

В чем проблема-то ?

> Ему, автору, прогресс-позишн нужно иметь в момент OnWork
> ..

Ну и что? Прогресс бар никак не связан ни с байтами, ни с гигабайтами, если размерности в 2 гигабайта не хватает, то перейти к размерности 2 терабайта.

> Progressbar.position - вот тебе и прогресс !

Нельзя, размер Integer, читай про переход к террабайтам, для этого единица должна быть не байт, а килобайт, если 2 террабайт не хватит, тогда переходим к пентабайтам, а единица равна 1 мегабайт

> Anatoly Podgoretsky © (25.10.06 16:43) [34]

> Нельзя, размер Integer

Можно.
И для этого тот самый параметр AWorkCount: Integer нахрен не нужен, хоть Integer он хоть Int64.

Значит согласен с моим предложением работать не с байтами, а с килобайтами, соответственно можно за раз брать столько гигабайт, сколько нужно.

> Anatoly Podgoretsky © (25.10.06 19:01) [36]

Да я и не возражал)

Здесь суть в том, что в теле метода TIdFTP.Get() организован цикл, в каждой итерации которого "закачивается" очередная "порция" файла размером не больше IOHandler.RecvBufferSize (Integer). И по идее параметр AWorkCount должен информировать о размере этой текущей "порции", а не аккумулировать предыдущие размеры. Об этом и в справке говорится. Т.е. акумуляция в AWorkCount - это ошибка разработчиков, но она вовсе не мешает организации прогресс-индикации транспорта файла - параметр AWorkCount для этого попросту не нужен .. либо можно выделять из него лишь дельту, которая никогда не превысит предельное положительное значение для Integer, и аккумулировать эти дельты в своей собственной Int64-переменной.

> Да я и не возражал)

Значит не так понял, а все равно обсуждение пошло кривовато. Флеймообразно, черт ногу сломает.

Кстати можно поговорить ошибка ли это и так ли переводится термин, с моей точки зрения нормально, это не количество переданых байт, а количество выполненых единиц работы. Вот только использую везде где можно Integer, вместо Int64, авторы сознательно загоняют себя в угол.
А вот насчет AWorkCount - не нужно это да, количество единиц работы это показатель в попугаях, который не применить, если только не чесать левое ухо правой рукой. Вместо AWorkCount, правильнее ABytesTransfered типа Int64 и если замахнуть на 22 век, то еще AUnitSize
Но пока Int64 хватает, что бы измерить всемирный трафик за день или чуть более, он гдето порядка 500 пентабайт ежедневно. За три года возрос в 17 раз.

idFTP и большие файлы Найти похожие ветки