Upload больших файлов

Главные вкладки

Аватар пользователя fl00r fl00r 11 сентября 2006 в 15:33

Не закачиваются файлы (испытания проводились на pdf) размером превышающим 3 метра. В чем загвоздка?

Комментарии

Аватар пользователя yurg yurg 11 сентября 2006 в 15:41

В настройках php. Пункт php_max_upload_size ограничивает размер (2mb по умолчанию), а script_execution_time - время исполнения (30 sec by default). Похоже у вВас второй случай:за 30 сек скрипт просто не успевает положить файл.

Аватар пользователя B.X B.X 11 сентября 2006 в 20:20

Есть такой скрипт [url=http://sypex.net/]Sypex Dumper[/url], он обходит это ограничение. Закачивая поэтапно (не знаю как он это делает, но работает). Он создан для заливки бэкапа базы данных на сервер посредством php. Размер бэкапа неограничен (разработчики говарят о сотнях мегабайт). Если посмотреть код и реалтзовать это в Друпале, то был бы неплохой модуль.

Аватар пользователя Dan Dan 11 сентября 2006 в 22:12

Не нашёл, где написано о закачке сотен мегабайт (плохо искал?).
Если это:
"работа с базами данных любых размеров (от нескольких килобайт до сотен мегабайт), в связи с этим вся работа с файлами бекапа осуществляется по FTP, но download возможен и с помощью менеджера загрузки (Download Master, Reget и др.);",
то тут ни слова про закачку.

Аватар пользователя B.X B.X 12 сентября 2006 в 3:46

[b]"работа с базами данных любых размеров (от нескольких килобайт до сотен мегабайт)"[/b]
да именно это я и имел ввиду... учитывая то, что скрипт как раз и занимается тем, что делает бэкап или наоборот восстанавливает из бэкапа, то это как раз работа с базой данных.

Аватар пользователя marazmus marazmus 12 сентября 2006 в 8:17

Вах, какая штука клевая этот SypexDumper! Smile

Щас поставил себе на локалхост и мажордомский хостинг. Все пучком. А удобно как. Все просто, как автомат Калашникова...
Единственно, у кого на хостинге MySQL откликается не на localhost, а на какой-то ip-адрес, нужно руками поправить одну строку в кишках dumper.php. Ну, друпальцам это как пальцем... Smile

А, забыл сказать. Это всего лишь 1 файл на php, размером около 30 кбайт :). Специализированные штуки рулят...

Не хватает одной кнопки - "Backup ВСЕХ БАЗ!" Smile Но это уже зависит...

Забыл сказать - utf8 нужно указать также вручную, в теле скрипта. По умолчанию там 1251, что для друпальцев болезненно, местами...

p.s. По мере юзанья выяснил пока такое:
Нормальное восстановление Друпала получилось у меня только когда я "отбросил" из списка пакуемых при бекапе таблиц
^cache, ^locales*, ^search*
Иначе постоянно какие-то ошибки с duplicate entries.

p.p.s. На хостинге utf-8 пакуется и восстанавливается нормально. На Денвере (знаю, знаю, не кидайтесь табуретками...) восстанавливается с крякозябрами.

Аватар пользователя Dan Dan 12 сентября 2006 в 13:34

to B.X
Скрипт ничего на сервер не заливает. Делает дамп и заливает дамп он локально (или FTP).
Как это может помочь в заливке больших файлов из броузера на сервер и что предлагается реализовать для Drupal?

to marazmus
Кодировка 1251 в скрипте указана только для странички закачки. Её смена принципиальна для работы скрипта/дампа база?

Аватар пользователя marazmus marazmus 12 сентября 2006 в 14:32

Quote:
Кодировка 1251 в скрипте указана только для странички закачки. Её смена принципиальна для работы скрипта/дампа база?

Кодировка принципиальна!

Оставляем 1251 в скрипте dumper.php и делаем с его помощью дамп базы друпала, что в utf-8. Глядим внутрь дампа - все тексты в 1251 Sad
Естественно, при восстановлении имеем проблемы с кодировкой контента.

Ставим в скрипте dumper.php кодировку utf8. Дамп базы сливается в utf8, и, соответственно, восстанавливается корректно.

Так что для манипуляций с utf8-дампами нужно править dumper.php, проставляя ему utf8.

Да и коммент в скрипте прямо говорит:

// Кодировка данных базы данных
define('CHARSET', 'cp1251');

Quote:
Скрипт ничего на сервер не заливает. Делает дамп и заливает дамп он локально (или FTP).
Как это может помочь в заливке больших файлов из броузера на сервер и что предлагается реализовать для Drupal?

Извините, что вмешиваюсь.
Dan, просто попробуй - это всего лишь 30-килобайтный файл, который работает даже на Денвере (знаю, знаю...).
Логика работы такая:
1) При первом запуске dumper.php создает каталог backup "рядом" с собой (т.е. на том уровне, где он "лежит"). В этот каталог скрипт кладет свой конфиг, историю операций и [b]непосредственно сами дампы[/b]. Т.е. файл дампа формируется на серваке, и там же лежит.

Доступны две операции - бекап и восстановление.

2) При бекапе выбираем БД и тип архивации (bzip2 на максимуме дает наибольшее сжатие). Про прошествии некоторого (но по ощущениям сильно, сильно меньшего, чем через phpMyAdmin) времени скрипт рапортует о завершении. В каталоге backup можно найти файл дампа (архивированный, если была выбрана архивация). Скрипт вежливо предлагает скачать его сразу; ну или можно качнуть его по фтп самостоятельно. Короче, если места много, дампы БД можно складывать на серваке хостера Smile

3) При восстановлении скрипт "смотрит", какие файлы есть в директории backup. Соответственно, если под рукой есть дамп, можно по фтп залить его в этот каталог, а dumper внесет его в список возможных файлов для восстановления. Затем выбираем из списка нужный файл, и жмем кнопку "восстановить". Так же за сильно небольшое время БД восстановлена.

Проверено на Денвере и на хостинге мажордомы. На неделе, как куплю серважовский хостинг, всяко будет проверяться там, уже в "боевых" условиях переезда. Так как через phpMyAdmin свой 30-меговый дамп восстановить так и не смог - даже на локалхосте. А через дампер залил влегкую.

То есть путь получается такой - не через post/get, как phpMyAdmin, а путем "подбирания" файла локально - относительно скрипта. Ведь и скрипт, и дамп базы лежат как бы "локально" - в пределах одного каталога и жесткого диска. А через phpMyAdmin данные "гонятся" по http, по сути. В тонкостях могу ошибаться, не спец.

Аватар пользователя marazmus marazmus 12 сентября 2006 в 14:34

Насчет самой темы - да, базары про SypexDumper не в тему Smile
Так как автору нужна заливка файлА, а не работа с дампами.
Здесь ничего не могу сказать, не шарю.

Но дампер - штука все равно клевая Smile

Аватар пользователя fl00r fl00r 12 сентября 2006 в 14:45

Quote:

Добавлено itnovosti, Пон, 11/09/2006 - 14:41
В настройках php. Пункт php_max_upload_size ограничивает размер (2mb по умолчанию), а script_execution_time - время исполнения (30 sec by default). Похоже у вВас второй случай:за 30 сек скрипт просто не успевает положить файл.

речь идет о
upload_max_filesize
и max_execution_time

Аватар пользователя marazmus marazmus 12 сентября 2006 в 14:58

То есть, по сути, общая проблема - для любого движка, а не только для друпала.

В FAQ бы это или в вики какую...

Аватар пользователя Dan Dan 12 сентября 2006 в 15:37

"Извините, что вмешиваюсь. Dan, просто попробуй - "
Знаю. Пробовал. Очень нравиться.

"Насчет самой темы - да, базары про SypexDumper не в тему"
Я с этого и начал! Smile
SypexDumper и аплод файлов никак не связаны.

"В FAQ бы это или в вики какую…"
FAQ пишется

Аватар пользователя B.X B.X 12 сентября 2006 в 19:03

[b]"Скрипт ничего на сервер не заливает. Делает дамп и заливает дамп он локально (или FTP)."[/b]
да, с домашнего компьютера не заливает, но я про это и не говорил... просто если он с сервера может заливать такие размеры, то что мешает это сделать и с компьютера? точно также, скрипт может по частям закачивать на сайт, оттуда этот же скрипт может делать что-то ещё...
короче, просто никто этим не занимался ещё...

[b]"всяко будет проверяться там, уже в “боевых” условиях переезда"[/b]
кстати, я написал в Servage, что phpMyadmin не подходит для восстановления базы данных (и прислал им этот Сипекс Дампекс), они ответили, что разберутся и через некоторое время там появился такой подпункт "import database", не знаю, основан он на этом скрипте или нет... но на Servage уже есть что-то похожее, тоже надо закачать дамп по фтп и он сам импортирует его.

Аватар пользователя Dan Dan 13 сентября 2006 в 15:06

"просто если он с сервера может заливать такие размеры, то что мешает это сделать и с компьютера"
хм, как ты себе это представляешь?

Аватар пользователя PC_M@niac PC_M@niac 13 сентября 2006 в 15:43

В принципе такое реализуемо через Java-апплет при условии что локально установится пакет, имеющий доступ к файловой системе а для этого в свою очередь требуется подписать его уважаемым сертификатом. У меня по такому принципу пашет JavaFTP клиент на одном серваке. Т.е. при заходе по ссылке стартует апплет с двумя окнами: в левом локальные диски а в правом содержимое FTP сервера. По такой схеме можно реализовать докачку но много гиммора.

ИМХО: проще порезать файл на куски и написать скриптик, который потом эти куски на стороне сервера будет клеить.

Аватар пользователя B.X B.X 13 сентября 2006 в 16:21

[b]хм, как ты себе это представляешь?[/b]
ну например, начинается закачка... php разрешено только положенные (во многих случаях) 2МБ, он их закачивает, но дальше не прерывается, а скажем записывает параметры закачки в какой-нибудь файл, потом завершается, и опять запускается, читает этот файл и продолжает закачивание... и так до тех пор пока полностью не закачает файл...
хотя, вообще-то, чем страдать такое ерундой, лучше использовать для этой цели perl, там нет ограничений (насколько я знаю) на закачивание файла...

Аватар пользователя PC_M@niac PC_M@niac 13 сентября 2006 в 20:18

[b]2: B.X[/b]
А как, интересно, php скрипт сможет возобновить закачку не с начала файла? Он ведь не имеет доступа к локальной файловой системе а ловит только то что ему передаёт браузер в POST или GET запросе. Т.е. чтобы на php реализовать докачку, это для начала должен уметь браузер. Т.е. самый простой в реализации способ - это резать ручками а на стороне сервера клеить при помощи того-же php. Правда пользователям такой вариант врядле понравится.

Аватар пользователя Dan Dan 13 сентября 2006 в 16:27

ключевой момент - "начинается закачка…"!
см. пост выше, в частности фразу "имеющий доступ к файловой системе".

Аватар пользователя B.X B.X 13 сентября 2006 в 16:28

да, но это надо всё закачивать самостоятельно, к тому же, как быть с другими пользователями? всем давать доступ к фтп? глупо... скрипт даёт возможность именно не только для тебя, но и для остальных закачивать... да и удобно это, нажал, выбрал, прикрепил...

Аватар пользователя Dan Dan 13 сентября 2006 в 16:32

Если эта тема так интересна, можете посмотреть, как реализована закачка больших файлов в gallery.

Аватар пользователя B.X B.X 13 сентября 2006 в 20:33

что мешает на стороне сервера делать всё что угодно? например, делать паузы и запускать цикл одних и тех же действий, только с учётом того, что уже закачено? например, не обязательно же скрипт должен завершаться... он может обрабатывать этот файл (который ему передал браузер) и дальше по тем же параметрам, только закачивать с паузами, например, он этот файл может каждый раз (при начале цикла) закачивать с самого начала, но переходить к той части, которая ещё не загружена...

Аватар пользователя Dan Dan 13 сентября 2006 в 21:19

2: B.X
Повторяю, посмотри как с этим справляются различные инструменты для gallery. Там даже есть reg-файл для WinXP. Не ты первый озаботился этой проблемой (заливкой больших файлов). Прежде чем начинать обсуждение на эту (непростую) тему неплохо ознакомится с существующими инструментами. Имхо Smile

Аватар пользователя B.X B.X 13 сентября 2006 в 21:21

если честно, мне это не нужно... во всяком случае в Друпале и именно сейчас... вопрос поднял не я, просто изложил некоторые идеи, как это можно сделать, реализацию я осилить всё равно не смогу...

Аватар пользователя kiev1 kiev1 14 сентября 2006 в 1:33

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

Аватар пользователя PC_M@niac PC_M@niac 14 сентября 2006 в 19:33

[b]2: B.X[/b]

[i]...например, он этот файл может каждый раз (при начале цикла) закачивать с самого начала, но переходить к той части, которая ещё не загружена[/i]

В том-то и дело что php_max_upload_size - это максимальный размер запроса типа POST, который можно передавать скрипту PHP. Серверу не важно как скрипт будет обрабатывать файл, важно какой объём он получает в рамках одного запроса со стороны клиента. Т.е. если клиент будет передавать файл размера больше чем разрешено то скрипт не сможет достучаться до той части, которая выходит за область допустимого ибо сервер эти данные просто не примет.

Аватар пользователя B.X B.X 14 сентября 2006 в 20:12

хм... ну да, тогда только AJAX и спасёт, ведь насколько мне известно, javascript там тоже присутствует?

Аватар пользователя PC_M@niac PC_M@niac 15 сентября 2006 в 12:00

Честно говоря сильно я с AJAX не сталкивался но вот что-то не верится что JavaScript тут поможет ибо нет у него возможности достучаться до локальных файлов пользователя. Хотя может это уже как-то и обошли, но не слышал. Пока видел только решения на базе ActiveX- или Java-апплетов, которыми рулит JavaScript. Т.е. к файловой системе может достучаться апплет а скрипт ему просто говорит куда и сколько.

Аватар пользователя B.X B.X 15 сентября 2006 в 16:10

есть решение, потому что, например, сервис http://www.netvibes.com/ позволяет закачивать через себя файлы во всяком случае и 6 и 8 МБ, но наверняка и больше... он постоен на AJAX, жмёшь кнопочку upload file и просто ждёшь, когда закончит закачивание... да и все эти upload-серверы типа rapidshare.de, тоже как-то работают (хотя они как раз могут использовать perl)...

Аватар пользователя PC_M@niac PC_M@niac 16 сентября 2006 в 0:58

Думаю что просто их серваки настроены на разрешение приёма таких больших запросов ))
Я у нашего хостера спрашивал, можно-ли этот параметр увеличить, они сказали что хоть пол гига мне поставят но толку от этого не будет. Залить такой файл по POST без единой ошибки практически нереально. Сейчас стоит 32 метра а всё крупное файло лью по ftp. Для основных клиентов сделал ftp аккаунты и установил Java-ftp клиента прям на сайт.

Аватар пользователя B.X B.X 16 сентября 2006 в 5:05

[b]"но толку от этого не будет"[/b]
ну заливают ведь... и полгига и больше... всё это зависит от качества связи, тем более на некоторых таких сервисах поддерживается докачка даже...

Аватар пользователя PC_M@niac PC_M@niac 19 сентября 2006 в 11:01

Согласен, но мы пока до этого "немножечко" не доросли... к сожалению
Мне моих 32 метров вполне хватает а для больших объёмов - FTP

Аватар пользователя Ainur Ainur 15 марта 2007 в 15:00

Stanislav, какая у тебя OS?

php.ini это файл настроек php, если на локалке, на пример у меня, он лежит в корне папки windows (на сервере в /etc/php4/apache2/php.ini), на рабочем сервере, смотря что тебе позволяет делать хостер.

Аватар пользователя Shoorick Shoorick 14 мая 2008 в 12:07

Попробовал увеличить upload_max_filesize до 16M через .htaccess и через sites/default/settings.php. (FreeBSD 6.2, Apache 1.3, php 4, drupal 5)
phpinfo говорит, что переменная изменилась, однако файлы больше 2 МБ по-прежнему не заливаются.

Куда смотреть?