А, не, вроде починила. Удалила строчку из config.php, и оно поехало, даже на повторную попытку запуска обновлялки сказало, что всё и так окей. А судя по логам, скрипт не мог получить доступ к файлу .rnd, хотя в консоли вообще никаких сообщений об ошибках не было, просто написали, что сервер остаётся в режиме обслуживания.

Сломала сервер при обновлении == Я ведь ещё засомневалась, а не снять ли мне образ впски ==

Если верить прокси, то клиент дропбокса научился скачивать файлы в несколько потоков OO

Только что я наконец поняла весь замес с этим взломом Телеграмки. Я вот этой программой не пользовалась и даже подумать не могла, что там для авторизации используется смска, а не пароль, и двухфакторная авторизация подключает именно пароль, а не смс, как было раньше. Дуров вообще долбойоп? И почему он просто не сделал логон через галочку «Даю честное пионерское, что я – именно этот юзернейм».

Прочитала тут...

Jabber умер, потому что ватсапы, телеграмы, облачная синхронизация, аудио/видео звонки, удобная передача любого контента, снова облачная синхронизация, возможность запускать на многих устройствах.

http://juick.com/2830529#2
А вот как это выглядит в жизни.

– Я тебе хочу картинку перекинуть. У тебя есть вацапа?
– Не, у меня телеграмка.
– А у Васи есть вацапа?
– Не, у него вибра.
– Ну хотя бы у Пети есть вацапа?
– У Пети вообще какая-то китайская хрень.

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

Бугага. Раньше:

– ICQ умер.
– Почему?
– Бинарный протокол.

Сейчас:

– Jabber умер.
– Почему?
– Небинарный протокол.

При чём во втором случае мелькает много знакомых лиц, виденных в случае первом.

Копирую, значит, тоталкоммандером файлик в рабочую папку. Решила проверить, нет ли такого в подкаталогах. Alt+F7, «Файло.doc», поехали! Нет таких файлов. Как нет? Вот же он! Ещё раз – тот же результат. Вышла на уровень выше, вдруг он в том же каталоге не ищет – та же фигня. Почесала голову, убрала расширение в строке поиска – нашёлся только что скопированный файл. Мда.

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

Или вот ещё прикол. Поставила я, значит, ownCloud на ещё один компьютер. Клиент запустился, сконфигурировался, бодро показывал, что проверяет изменения в каталогах и готовится к синхронизации, а потом загорелся зелёненьким индикатором. Смотрю, а в папке пусто. Я, значит, закидываю туда файл. Файл клиент видит (я расширение поставила, так что у файла был индикатор), показывает, что проверяет изменения, готовится к синхронизации, а потом снова загорелся зелёным. Папка, разумеется, пустая, файл даже не отправлен. Три перезагрузки (по разным причинам) спустя, клиент неожиданно очнулся и принялся закачивать файлы. Качал долго, но в итоге скачал. Почти все. Пришлось снова пинать его скриптиком, и уже через полчасика он наконец узрел на сервере файлы, которые ещё не скачал. После этого вроде бы заработал.
Я это всё к чему пишу? Наверное, Артс был прав, и во всём виновата устаревшая и неработоспособная XP. Хотя постойте! Это же Windows 7, и даже со всеми обновлениями! Может быть на десятке повезёт?

Для толстолобиков: предыдущий пост не содержит наезд на Дропбокс, а содержит печаль по поводу плохой памяти.

Решила синхронизировать одну машину с Дропбоксом. На ней я не логинилась уже полгода, так что ожидала, что это займёт время. Несколько часов спустя клиент продолжал шуршать диском и что-то качать. Думала, всё, пипец клиенту. Но тут случайно заглянула в одну папку и узрела то, о чём почти забыла. У меня есть несколько папок, которые хранят кое-какие файлы, которые я храню на сервере, но не синхронизирую с клиентами. Вот на этой машине выборочная синхронизация настроена не была, потому всё это время клиент усиленно тянул при гига файлов >< И почти вытянул, но я его остановила ><

У меня ощущение, что ownCloud вместо FindFirstChangeNotification() использует какие-то свои костыли для проверки изменений в синхронизируемой папке. Плохо.

Написала скриптик, который пишет некий файл с текущей датой (это вместо рандомных данных). Закинула в планировщик, каждые три минуты файл пишется в папку ownCloud, подпинывая клиент. Синхронизация не прекращается. Первый костыль.

Дважды бугага. Добавила файлик новый, скачались изменённые.

Бугага, синхронизация сломалась. Изменила пару файлов на другой машине, на этой на вкладке «Server Activity» изменения есть, на вкладке «Sync Protocol» никаких сообщений о скачке этих файлов. Ладно, будем разбираться.

При логоне через SSH система сообщает:

To delete this message of the day: rm -rf /etc/motd.tail

Делаю (чтобы сохранить для истории):

mv /etc/motd.tail ~/tmp/

Сообщение не пропадает. Смотрю:

ls /etc/motd*

Ничего не найдено. Чешу голову, делаю как было написано в сообщении, сообщение пропадает.
Что это было?

Клиент ownCloud после перезапуска забывает как авторизоваться на прокси. Может больше часа буксовать прежде чем очнуться. Ну и файлы баз прямо в корне синхронизируемой папки – это, конечно, нечто. Хорошо хоть их имена начинаются на точку, а в Windows прикручен атрибут Hidden.

Пришло письмо от Дропбокса.

We noticed that you're running the Dropbox desktop application (client) on Windows XP. We're writing to let you know that as of August 29th, 2016, Dropbox will no longer support this version of Windows.

Да, пора мигрировать на более вменяемый сервис. Тестирование ownCloud идёт полным ходом. Сифайл запланирован.

Не синхронизируются альтернативные потоки NTFS. Не то чтобы очень нужно, но даже BTSync научился.

А вот ещё прикол. Смотрю, в трее зелёная иконка, типа, синхронизировано. Открываю папку, а там половины файлов нет. Смотрю лог, а там, оказывается, просто файл какой-то отвалился по таймауту, и программа взяла паузу. А чтобы юзер не пугался, показала, что всё в порядке.