Цитата:
Опера 12.16 - все ок
этой да все норма, а вот усб версия - переносимая...не хотит.
» Облако Mail.ru (Cloud Mail.ru)
Цитата:
этой да все норма, а вот усб версия - переносимая...не хотит.
Странный человек. Ну так возьмите/сделайте переносимую 12.16. Я почему-то уверен, что какой-нибудь там Нетскейп Навигатор тоже не сможет работать с их облаком.
не так давно работала данная опера! Теперь надо отслеживать постоянно какие браузеры не пускает и делать портабле )) Это все ведет к полному переходу поддержки только хромоногих.
Не так давно все сидели на модемах и Нетскейп Навигаторе. А Интернет Эксплорер нервно курил в сторонке. Опер и всяких там файерфоксов с хромами даже в мечтах не было. Но мир меняется, знаете ли.
Хромоногие сильно какают в систему поэтому лично мое мнение что не гуд их повсеместно внедрять )) Из хромоногих только один находил без загаживания, потчищал за собой сам после закрытия. Поэтому если юзать облако постоянно на том же гулхром то через месяц столько какашек будет на диске С )) хотя можно советовать чистить прогами разными, на дню по несколько раз )) Я сторонник использования софта с минимимом какашек в оси после работы!
Цитата:
У меня по webdav скорость обмена с Яндексом около 20 кб\с.
Вчера вечером на мейле и без вебдава скорость загрузки упала практически до нуля - около 20-40 кб/с. Потом наладилось, но чувствуется уже нагрузка на сервера возрастает.
betssaf
Фантазия развита, ничего не скажешь. Никто никуда не какает, 20-я опера дальше своей папки никуда не ходит. Хром - тот да, устанавливает службы обновлений, которые постоянно ломятся обновляться. Но оперы это никаким боком не касается.
Вот если сегодня после обеда прекратят поддержку оперы 12.16 - тогда да, можно их называть козлами. А то, что перестала работать ваша допотопная опера непонятно какой версии, то ваша личная драма, ящитаю. К тому же, не факт, что это вы там с настройками не намутили ничего.
Ну что, подождем до обеда?
Фантазия развита, ничего не скажешь. Никто никуда не какает, 20-я опера дальше своей папки никуда не ходит. Хром - тот да, устанавливает службы обновлений, которые постоянно ломятся обновляться. Но оперы это никаким боком не касается.
Вот если сегодня после обеда прекратят поддержку оперы 12.16 - тогда да, можно их называть козлами. А то, что перестала работать ваша допотопная опера непонятно какой версии, то ваша личная драма, ящитаю. К тому же, не факт, что это вы там с настройками не намутили ничего.
Ну что, подождем до обеда?
При закачивании exe файла, в web интерфейсе он имеет значок в виде треугольника с восклицательным знаком. Что это значит?
betssaf
Цитата:
IDM пока без проблем подхватывает ссылки, по крайней мере из мозиллы.
Цитата:
И чего то намутили, теперь прямые линки IDM не подхватывает. Жуть вообщем...хотел образ стянуть не браузером и клиентом а менеджером докачки
IDM пока без проблем подхватывает ссылки, по крайней мере из мозиллы.
Цитата:
Ну что, подождем до обеда?
буду делать портабле 12.16, до этого версия...долго служила верой и правдой! Хром по мимо всяких служб, гадит в профиль )) что ну очень... )) Буду до последнего на опере сидеть, пока хотя бы одна страница инета будет в ней открываться ))
Добавлено:
Цитата:
по крайней мере из мозиллы.
а из оперы не хочет! у меня не хромоногая...обычная!
betssaf
Попробовал и из под Оперы, тоже все нормально. Может в настройках что-то меняли
Попробовал и из под Оперы, тоже все нормально. Может в настройках что-то меняли
Цитата:
Может в настройках что-то меняли
она (портабле) упакована в exe! Не поменяешь никак уже )) Ее использую в режиме РЕ загрузки! Теперь уже не юзаю, майл облако не поддерживает данный билд браузера. Буду собирать портативку из версии 12.16 - пока с нее еще можно попасть ))
betssaf
Видимо проблемы в том, что у Вас портативка. Из под установленной оперы 12.16 все окей. Не знаю как с последующими версиями, они меня не особо интересуют.
Видимо проблемы в том, что у Вас портативка. Из под установленной оперы 12.16 все окей. Не знаю как с последующими версиями, они меня не особо интересуют.
dimasic 20:23 12-04-2014
Цитата:
Сегодня появился повод и я, наконец, их потестил.
Спасибо за батники! Обожаю доводить до ума чужие наработки (я так даже AutoIt изучил, пока пытался добиться нужного мне результата правкой чужого сырого скрипта).
В целом основная работа уже сделана и пользование этими батниками действительно почти удобно..."почти" - потому что нужно вручную снимать галки синхронизации в клиенте, а я лично ненавижу любые ручные действия и всегда пытаюсь их автоматизировать...и данный случай не стал исключением, всё относительно легко полностью автоматизируется при помощи правки скрытых файлов в облачной папке ".cloud" и ".cloud_ss". А с именем заливаемой папки в формате дата_время всё ещё проще, т.к. не надо заморачиваться с выводом в юникоде русского текста (если бы он был в именах папок).
dimasic, а сами не пытались автоматизировать этот этап или не получалось реализовать?
P.S. Если интересно и что-то непонятно, то завтра могу расписать по шагам...
Цитата:
ТруЪ вариант набора скриптов
Сегодня появился повод и я, наконец, их потестил.
Спасибо за батники! Обожаю доводить до ума чужие наработки (я так даже AutoIt изучил, пока пытался добиться нужного мне результата правкой чужого сырого скрипта).
В целом основная работа уже сделана и пользование этими батниками действительно почти удобно..."почти" - потому что нужно вручную снимать галки синхронизации в клиенте, а я лично ненавижу любые ручные действия и всегда пытаюсь их автоматизировать...и данный случай не стал исключением, всё относительно легко полностью автоматизируется при помощи правки скрытых файлов в облачной папке ".cloud" и ".cloud_ss". А с именем заливаемой папки в формате дата_время всё ещё проще, т.к. не надо заморачиваться с выводом в юникоде русского текста (если бы он был в именах папок).
dimasic, а сами не пытались автоматизировать этот этап или не получалось реализовать?
P.S. Если интересно и что-то непонятно, то завтра могу расписать по шагам...
Цитата:
всё относительно легко полностью автоматизируется при помощи правки скрытых файлов в облачной папке ".cloud" и ".cloud_ss"
Я ка-то давно пытался изменять эти файлы, особенно .cloud_ss. Ничего из этого тогда не вышло, т.к. при заходе в аккаунт через клиент этот файл перезаписывался на старый вариант.
Наконец-то первый тестер появился. 
Нельзя сказать, что мне непонятно, но зато безусловно интересно все, что вам удалось нарыть.
Была мысль насчет .cloud и .cloud_ss, но с ними не удалось подружиться. Первый - бинарник и структура не вполне ясна. Ну длину адреса email и сам email я, положим, нашел с полпинка, а дальше не вникал сильно - там есть имена всех файлов и папок, есть признаки их синхронизации и, видимо, хэши. Второй файл содержит список исключенных папок, но ручное его редактирование, увы, ни на что не влияет - клиент каждый раз пересоздает его заново. По крайней мере, для свежих версий клиента. Если у вас есть какие-то наработки, поделитесь.
А с русским текстом в именах папок у командных скриптов проблем и так не должно быть, консоль выдает их всегда в определенной кодировке. Если исходный cmd-файл сохранить в отличной от консольной кодировке, то да, содержащий кириллицу заданный путь с точки зрения консоли станет корявками и не сможет смонтироваться. Это можно легко победить, сохранив скрипт в нужной кодировке или поменяв кодировку консоли.
Но кодировка в другом месте вылезла - начал писать GUI-приложение для монтирования папки по такому же принципу, через subst, вот там корявки и выходят боком. Монтировать папку через MountPoint посчитал неоправданным, поэтому обращаюсь к консольной subst. Кстати, там оба шаблона подпапки (фиксированный текст и строка даты) объединены - можно использовать как текст, так и макросы даты.
Добавлено:
Цитата:
Ага-ага. Но зато его можно использовать как маркер того, что пользователь отключил синхронизацию нужной папки, и без лишних ожиданий удалять ссылку на смонтированный диск.
Нельзя сказать, что мне непонятно, но зато безусловно интересно все, что вам удалось нарыть.
Была мысль насчет .cloud и .cloud_ss, но с ними не удалось подружиться. Первый - бинарник и структура не вполне ясна. Ну длину адреса email и сам email я, положим, нашел с полпинка, а дальше не вникал сильно - там есть имена всех файлов и папок, есть признаки их синхронизации и, видимо, хэши. Второй файл содержит список исключенных папок, но ручное его редактирование, увы, ни на что не влияет - клиент каждый раз пересоздает его заново. По крайней мере, для свежих версий клиента. Если у вас есть какие-то наработки, поделитесь.
А с русским текстом в именах папок у командных скриптов проблем и так не должно быть, консоль выдает их всегда в определенной кодировке. Если исходный cmd-файл сохранить в отличной от консольной кодировке, то да, содержащий кириллицу заданный путь с точки зрения консоли станет корявками и не сможет смонтироваться. Это можно легко победить, сохранив скрипт в нужной кодировке или поменяв кодировку консоли.
Но кодировка в другом месте вылезла - начал писать GUI-приложение для монтирования папки по такому же принципу, через subst, вот там корявки и выходят боком. Монтировать папку через MountPoint посчитал неоправданным, поэтому обращаюсь к консольной subst. Кстати, там оба шаблона подпапки (фиксированный текст и строка даты) объединены - можно использовать как текст, так и макросы даты.
Добавлено:
Цитата:
.cloud_ss. Ничего из этого тогда не вышло, т.к. при заходе в аккаунт через клиент этот файл перезаписывался на старый вариант.
Ага-ага. Но зато его можно использовать как маркер того, что пользователь отключил синхронизацию нужной папки, и без лишних ожиданий удалять ссылку на смонтированный диск.
dimasic
У меня тогда сложилось такое впечатление, что эти 2 скрытых файла существуют еще где-то в резервных копиях, кроме коренной, и при заходе в аккаунт они переписываются этими копиями.
У меня тогда сложилось такое впечатление, что эти 2 скрытых файла существуют еще где-то в резервных копиях, кроме коренной, и при заходе в аккаунт они переписываются этими копиями.
dima1978
Вероятнее всего, клиент их получает из облака. И наверняка даже не файлы как таковые, а запрошенные через API данные, которые потом сохраняются в файл в корень локальной папки. Ведь пока синхронизация приостановлена, выбор синхронизируемых папок неактивен. Следовательно, клиенту для этого действия нужна связь с облаком. Не думаю, что программисты так сделали только в силу какой-то своей прихоти.
Но я не такой маньяк, чтобы анализировать обмен данными между клиентом и облаком и пытаться вникнуть в их API. Даже если предположить, что это получилось и наша чудесная программка отключает синхронизацию посредством API, без участия пользователя (и позволяет, например, не удалять несинхронизируемые папки локально), то потом они в один прекрасный день поменяют API и мы получим, в лучшем случае, неработающую программу. В худшем - потеряем данные.
Вероятнее всего, клиент их получает из облака. И наверняка даже не файлы как таковые, а запрошенные через API данные, которые потом сохраняются в файл в корень локальной папки. Ведь пока синхронизация приостановлена, выбор синхронизируемых папок неактивен. Следовательно, клиенту для этого действия нужна связь с облаком. Не думаю, что программисты так сделали только в силу какой-то своей прихоти.
Но я не такой маньяк, чтобы анализировать обмен данными между клиентом и облаком и пытаться вникнуть в их API. Даже если предположить, что это получилось и наша чудесная программка отключает синхронизацию посредством API, без участия пользователя (и позволяет, например, не удалять несинхронизируемые папки локально), то потом они в один прекрасный день поменяют API и мы получим, в лучшем случае, неработающую программу. В худшем - потеряем данные.
dimasic
Цитата:
Да, именно это я и хотел сказать.
Цитата:
Согласен, поэтому вариант с манипуляцией или правкой этими файлами видимо не подходит в связи с этим.
Цитата:
Вероятнее всего, клиент их получает из облака.
Да, именно это я и хотел сказать.
Цитата:
то потом они в один прекрасный день поменяют API и мы получим, в лучшем случае, неработающую программу.
Согласен, поэтому вариант с манипуляцией или правкой этими файлами видимо не подходит в связи с этим.
dimasic
Цитата:
Ну да, так и есть. И именно благодаря этому списку файлов-папок (по видиму с хэшами) клиент и понимает, что .cloud_ss был исправлен и похоже восстанавливает резервную копию с облака. Я долго думал что можно с этим сделать, а потом попробовал поэкспериментировать с удалением .cloud.
И оказалось, что если .cloud просто отсутствует (удален), то без проблем принимается .cloud_ss и все перечисленные в нём папки отключатся от синхронизации. Я вчера около 2-ух часов тестил этот метод при различных условиях и всё работает идеально.
И это вполне логично, раз на разных компах можно иметься разный набор синхронизируемых папок для одного логина, то основные настройки какие именно папки не синхронизируется должны лежать на ПК, а не в облаке.
Закрываем клиент (какой-нибудь консольной утилитой) или убиваем его процесс (и потом чем-нибудь обновляем трей для избавления от мертвой иконки клиента), удаляем .cloud, вносим нашу папку в .cloud_ss, и в самом конце батника можно снова запустить облачный клиент (если нужно).
Суть думаю ясна, там в unmount.cmd всего несколько строчек дописать нужно, чтобы он стал полностью автоматическим.
Цитата:
Вообще-то про проблему с русским текстом, необходимым выводить в юникоде я писал в контексте .cloud&.cloud_ss, потому что в .cloud_ss русский текст хранится именно в юникоде и выводить его туда нужно не в 866/1251, а именно в юникоде (это сложно, но насколько помню возможно)
Цитата:
Первый - бинарник и структура не вполне ясна. Ну длину адреса email и сам email я, положим, нашел с полпинка, а дальше не вникал сильно - там есть имена всех файлов и папок, есть признаки их синхронизации и, видимо, хэши.
Ну да, так и есть. И именно благодаря этому списку файлов-папок (по видиму с хэшами) клиент и понимает, что .cloud_ss был исправлен и похоже восстанавливает резервную копию с облака. Я долго думал что можно с этим сделать, а потом попробовал поэкспериментировать с удалением .cloud.
И оказалось, что если .cloud просто отсутствует (удален), то без проблем принимается .cloud_ss и все перечисленные в нём папки отключатся от синхронизации. Я вчера около 2-ух часов тестил этот метод при различных условиях и всё работает идеально.
И это вполне логично, раз на разных компах можно иметься разный набор синхронизируемых папок для одного логина, то основные настройки какие именно папки не синхронизируется должны лежать на ПК, а не в облаке.
Закрываем клиент (какой-нибудь консольной утилитой) или убиваем его процесс (и потом чем-нибудь обновляем трей для избавления от мертвой иконки клиента), удаляем .cloud, вносим нашу папку в .cloud_ss, и в самом конце батника можно снова запустить облачный клиент (если нужно).
Суть думаю ясна, там в unmount.cmd всего несколько строчек дописать нужно, чтобы он стал полностью автоматическим.
Цитата:
А с русским текстом в именах папок у командных скриптов проблем и так не должно быть, консоль выдает их всегда в определенной кодировке.
Вообще-то про проблему с русским текстом, необходимым выводить в юникоде я писал в контексте .cloud&.cloud_ss, потому что в .cloud_ss русский текст хранится именно в юникоде и выводить его туда нужно не в 866/1251, а именно в юникоде (это сложно, но насколько помню возможно)
Цитата:
И оказалось, что если .cloud просто отсутствует (удален), то без проблем принимается .cloud_ss и все перечисленные в нём папки отключатся от синхронизации. Я вчера около 2-ух часов тестил этот метод при различных условиях и всё работает идеально.
Ого. Лихо. До такого я не допер. Внутрь смотрел, какие там байты изменяются при изменении имен файлов и отключении синхронизации папок, правил _ss и смотрел на его восстановление. Но удалять файлы по одному - это высший пилотаж.
Ну что ж, благие вести. Убрали ссылку, taskkill/tasklist, правим .cloud_ss, удаляем .cloud - и снова запускаем клиента. Задача не выглядит слишком сложной.
Цитата:
И это вполне логично, раз на разных компах можно иметься разный набор синхронизируемых папок для одного логина, то основные настройки какие именно папки не синхронизируется должны лежать на ПК, а не в облаке.
Логично, но не факт. В .cloud при отключении синхронизации вносятся изменения. Следовательно, при наличии этого файла измененный .cloud_ss создается именно из .cloud. То есть зависимость получается хитрая: .cloud_ss каждый раз пересоздается на основе .cloud; нету .cloud - он создается из облака, НО с учетом возможного наличия .cloud_ss. Не вполне понятно, зачем так сделано. По-идее, если пользователь потерял .cloud вместе со всеми хешами, то он сам дурак. Интересно, исходя из каких соображений они дублирующиеся настройки в двух файлах хранят...
Цитата:
Вообще-то про проблему с русским текстом, необходимым выводить в юникоде я писал в контексте .cloud&.cloud_ss, потому что в .cloud_ss русский текст хранится именно в юникоде и выводить его туда нужно не в 866/1251, а именно в юникоде (это сложно, но насколько помню возможно)
Да, точно. Не обращал внимания на кодировку. Ну да это решаемо так или иначе.
В дополнение к прошлому посту: я ещё не упомянул об одной особенности, что если в облачной папке на HDD, после размонтирования и удаления нашей залитой папки, не останется никаких других папок, то при запуске клиента он обнуляет .cloud_ss. Это ничем не опасно, кроме того что если не предпринять мер, то при последующем запуске начнется слив всех папок из облака на HDD.
Причем такое только после "двойного убийства" процесса:
мы слили первую папку -> убили процесс клиента -> удалили .cloud+добавили папку в .cloud_ss -> запустили клиент (обнулился .cloud_ss если нет других папок в облачной папке) -> слили 2ую папку -> убили процесс клиента -> удалили .cloud+добавили папку в .cloud_ss (а он-то обнуленный и мы добавили в него первую строчку) -> запустили клиент, клиент прочитал одну строчку, подумал что у нас всего одна папка не должна синхронизироваться и получили слив всех остальных папок на HDD))
Варианта решения этой проблемы целых два, на выбор (первый вариант на мой взгляд - лучший):
1) Корректно закрывать клиент, НЕ через убийство процесса. Я раньше находил какую-то консольную утилиту для корректного закрытия программ, но сейчас не помню её названия, на старом компе она где-то валялась, может как-нибудь поищу. Да и даже в AutoIt, если не ошибаюсь (потому что, в отличии от батников, AutoIt я в совершенстве не знаю) помнится была функция для корректного закрытия программ, можно скомпилить exe-ник.
2) Создавать параллельно (можно временно) любую пустую папку с любым именем, тогда .cloud_ss не обнуляется.
P.S.
Во втором варианте с убийством процесса и созданием временной папки мне не нравится, что после убийства остаётся мертвая иконка в трее и всё равно приходится прибегать к внешним утилитам для обновления трее, чтобы избавиться от трупов иконок.
Причем такое только после "двойного убийства" процесса:
мы слили первую папку -> убили процесс клиента -> удалили .cloud+добавили папку в .cloud_ss -> запустили клиент (обнулился .cloud_ss если нет других папок в облачной папке) -> слили 2ую папку -> убили процесс клиента -> удалили .cloud+добавили папку в .cloud_ss (а он-то обнуленный и мы добавили в него первую строчку) -> запустили клиент, клиент прочитал одну строчку, подумал что у нас всего одна папка не должна синхронизироваться и получили слив всех остальных папок на HDD))
Варианта решения этой проблемы целых два, на выбор (первый вариант на мой взгляд - лучший):
1) Корректно закрывать клиент, НЕ через убийство процесса. Я раньше находил какую-то консольную утилиту для корректного закрытия программ, но сейчас не помню её названия, на старом компе она где-то валялась, может как-нибудь поищу. Да и даже в AutoIt, если не ошибаюсь (потому что, в отличии от батников, AutoIt я в совершенстве не знаю) помнится была функция для корректного закрытия программ, можно скомпилить exe-ник.
2) Создавать параллельно (можно временно) любую пустую папку с любым именем, тогда .cloud_ss не обнуляется.
P.S.
Во втором варианте с убийством процесса и созданием временной папки мне не нравится, что после убийства остаётся мертвая иконка в трее и всё равно приходится прибегать к внешним утилитам для обновления трее, чтобы избавиться от трупов иконок.
19w85
Цитата:
Это очень интересный факт. А после правки файла cloud_ss и запуска мейловского клиента, файл cloud создается по новой из хеша облака?
Цитата:
И оказалось, что если .cloud просто отсутствует (удален), то без проблем принимается .cloud_ss и все перечисленные в нём папки отключатся от синхронизации.
Это очень интересный факт. А после правки файла cloud_ss и запуска мейловского клиента, файл cloud создается по новой из хеша облака?
dima1978
Цитата:
Да, создаётся именно из облака, потому что запуск клиента без интернета не приводит к его созданию.
Цитата:
А после правки файла cloud_ss и запуска мейловского клиента, файл cloud создается по новой из хеша облака?
Да, создаётся именно из облака, потому что запуск клиента без интернета не приводит к его созданию.
Цитата:
Варианта решения этой проблемы целых два, на выбор (первый вариант на мой взгляд - лучший):
Второй вариант можно оставить дополнительно к первому, чтобы уж наверняка. Если у кого-то клиент используется только для заливки в облако и корневая папка при этом держится пустой, то временно создаваемая папка никому помешать не сможет. Добавить проверку пустоты корня и создание временной папки при необходимости - плевое дело.
Я взялся переписывать в GUI-приложение, чтобы одной кнопкой все делалось из одного интерфейса и чтобы получить дополнительные рюшечки типа висения в трее. Ну и функционал работы с UTF-8 можно встроить, плюс удобное изменение шаблона файла, плюс надеюсь на более аккуратное взаимодействие с клиентом облака, без убийств. Программист я не так чтоб очень, продвигается дело не быыстро, но прежний функционал практически готов. Сейчас поэкспериментирую с .cloud_ss, в случае удачи это будет прорыв. ))
dimasic
Цитата:
Вы взяли на себя работу целой компании, которая до сих пор никак не может допилить свой клиент до нормального функционала
Цитата:
Я взялся переписывать в GUI-приложение, чтобы одной кнопкой все делалось из одного интерфейса и чтобы получить дополнительные рюшечки типа висения в трее.
Вы взяли на себя работу целой компании, которая до сих пор никак не может допилить свой клиент до нормального функционала
dimasic
Цитата:
Ну что тут сказать...очень жаль...
Не знаю как другие, а я лично очень не люблю ненужные иконки в трее (а некоторый софт ещё и с неотключаемыми иконками в трее идёт, вообще кошмар) и уж всё относящееся к облаку у меня точно подпадает в категорию "ненужные".
В целом меня полностью устраивают батники (и для других задач и для текущей тем более) и я в любой момент могу что-то доработать/усовершенствовать или поменять "под себя" для большего удобства.
P.S. А это GUI-приложение сможет скрывать иконку мэйловского клиента? Тогда может и было бы немного интересно...а то захламлять трей я уж точно не хочу.
Цитата:
Я взялся переписывать в GUI-приложение, чтобы одной кнопкой все делалось из одного интерфейса и чтобы получить дополнительные рюшечки типа висения в трее.
Ну что тут сказать...очень жаль...
Не знаю как другие, а я лично очень не люблю ненужные иконки в трее (а некоторый софт ещё и с неотключаемыми иконками в трее идёт, вообще кошмар) и уж всё относящееся к облаку у меня точно подпадает в категорию "ненужные".
В целом меня полностью устраивают батники (и для других задач и для текущей тем более) и я в любой момент могу что-то доработать/усовершенствовать или поменять "под себя" для большего удобства.
P.S. А это GUI-приложение сможет скрывать иконку мэйловского клиента? Тогда может и было бы немного интересно...а то захламлять трей я уж точно не хочу.
Цитата:
Корректно закрывать клиент, НЕ через убийство процесса. Я раньше находил какую-то консольную утилиту для корректного закрытия программ, но сейчас не помню её названия
Так клиент всегда закрывается нормально, но только через трей. Я замечал мне помнится, что даже если убить процесс клиента, то эти 2 заветных файла все равно восстанавливаются с прежними настройками.
Да им всего-то надо было сделать, чтобы несинхронизируемые папки не удалялись с локального диска. Из-за этой странной фичи надо предназначенные для синхронизации файлы или ручками копировать в папку, или так же ручками изгаляться с хардлинками. Копировать - долго и много места занимает. Хардлинки - ссыкотно: выглядят-то они как настоящие файлы, а ну как совсем все удалится!
Сейчас еще такая штука в голову пришла. А если попробовать с помощью ссылок разворачивать данные из облака не в корневую папку клиента, а куда-то еще, в пустую папку? Прочитать .cloud_ss и включить синхронизацию с заданной папкой. Он увидит, что папки нет, и начнет качать из облака. Надо будет исследовать такую возможность, насколько это реально.
UTF8 уже читаю и пишу. .cloud_ss почти сдался.
Добавлено:
19w85
Цитата:
Чего жаль? Кто вам сказал, что оно будет всегда в трее висеть и не будет воспринимать ключей командной строки? Трей - это на потом. Может, даже не будет никакого трея. Просто маленькая гуевая утилитка с удобными настройками. Ну вот захотелось мне так, увлекся и батники отложил в сторону. ) Добрался до изменения .cloud_ss и вот-вот доберусь до перезапуска процесса. А там посмотрим, можно будет и батники до ума довести. Текущие наработки позволяют писать в список исключенных файлов русские имена в UTF8, и этот функционал можно вынести в консольный перекодировщик для любителей черных окошек.
dima1978
Цитата:
В реестре есть ключик validfinish, при корректном завершении клиента он устанавливается в единичку, при работающем или убитом процессе он нолик. Очень может быть, что этот ключ и влияет на описанное вами поведение. Можете в порядке эксперимента попробовать жестко прибить клиент и выставить ключ в 1.
Сейчас еще такая штука в голову пришла. А если попробовать с помощью ссылок разворачивать данные из облака не в корневую папку клиента, а куда-то еще, в пустую папку? Прочитать .cloud_ss и включить синхронизацию с заданной папкой. Он увидит, что папки нет, и начнет качать из облака. Надо будет исследовать такую возможность, насколько это реально.
UTF8 уже читаю и пишу. .cloud_ss почти сдался.
Добавлено:
19w85
Цитата:
Ну что тут сказать...очень жаль...
Чего жаль? Кто вам сказал, что оно будет всегда в трее висеть и не будет воспринимать ключей командной строки? Трей - это на потом. Может, даже не будет никакого трея. Просто маленькая гуевая утилитка с удобными настройками. Ну вот захотелось мне так, увлекся и батники отложил в сторону. ) Добрался до изменения .cloud_ss и вот-вот доберусь до перезапуска процесса. А там посмотрим, можно будет и батники до ума довести. Текущие наработки позволяют писать в список исключенных файлов русские имена в UTF8, и этот функционал можно вынести в консольный перекодировщик для любителей черных окошек.
dima1978
Цитата:
Так клиент всегда закрывается нормально, но только через трей. Я замечал мне помнится, что даже если убить процесс клиента, то эти 2 заветных файла все равно восстанавливаются с прежними настройками.
В реестре есть ключик validfinish, при корректном завершении клиента он устанавливается в единичку, при работающем или убитом процессе он нолик. Очень может быть, что этот ключ и влияет на описанное вами поведение. Можете в порядке эксперимента попробовать жестко прибить клиент и выставить ключ в 1.
dima1978
Цитата:
Плохо следите за ходом разговора. Речь шла об автоматизации батниками: размонтировании папки, убийстве клиента, удаление папки и последующем запуске клиента, всё автоматически - какой ещё трей? Батник делает всё автоматически и в трей он лазить не умеет, чтобы там закрывать =)
dimasic
Цитата:
Это точно, копирование - неудобно, поэтому мне так и понравилась вся эта тема с созданием линков на папки, т.к. не важно на каком HDD (на другом физическом или логическом разделе) находится целевая папка, благодаря ссылке её не нужно никуда перемещать + дополнительная безопасность от удаления.
Цитата:
А смысл? Чтобы сразу на нужный HDD сохранить? (я другого применения не вижу)
Цитата:
Если даже батники это позволяет, то чего уж говорить о другом, с бОльшими возможностями
Добавлено:
dimasic
Цитата:
Проверил, не влияет этот ключ ни на что
Цитата:
Так клиент всегда закрывается нормально, но только через трей. Я замечал мне помнится, что даже если убить процесс клиента, то эти 2 заветных файла все равно восстанавливаются с прежними настройками.
Плохо следите за ходом разговора. Речь шла об автоматизации батниками: размонтировании папки, убийстве клиента, удаление папки и последующем запуске клиента, всё автоматически - какой ещё трей? Батник делает всё автоматически и в трей он лазить не умеет, чтобы там закрывать =)
dimasic
Цитата:
Копировать - долго и много места занимает. Хардлинки - ссыкотно: выглядят-то они как настоящие файлы, а ну как совсем все удалится!
Это точно, копирование - неудобно, поэтому мне так и понравилась вся эта тема с созданием линков на папки, т.к. не важно на каком HDD (на другом физическом или логическом разделе) находится целевая папка, благодаря ссылке её не нужно никуда перемещать + дополнительная безопасность от удаления.
Цитата:
А если попробовать с помощью ссылок разворачивать данные из облака не в корневую папку клиента, а куда-то еще, в пустую папку?
А смысл? Чтобы сразу на нужный HDD сохранить? (я другого применения не вижу)
Цитата:
UTF8 уже читаю и пишу. .cloud_ss почти сдался.
Если даже батники это позволяет, то чего уж говорить о другом, с бОльшими возможностями
Добавлено:
dimasic
Цитата:
В реестре есть ключик validfinish, при корректном завершении клиента он устанавливается в единичку, при работающем или убитом процессе он нолик. Очень может быть, что этот ключ и влияет на описанное вами поведение. Можете в порядке эксперимента попробовать жестко прибить клиент и выставить ключ в 1.
Проверил, не влияет этот ключ ни на что
Страницы: 123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566
Предыдущая тема: Ссылки на COPY.COM
Форум Ru-Board.club — поднят 15-09-2016 числа. Цель - сохранить наследие старого Ru-Board, истории становления российского интернета. Сделано для людей.