Но если необходимо переместить большую директорию (или просто переиеновать), например 1T, это может занять 3.5 часа
Получается, что move рекурсивно переносит по одному файлу в новое место, вместо того, чтобы сделать rename этих файлов
Есть ли возможность перенести данные внутри одного контейнера быстро?
2) Скорость rclone move в Amazon S3 / Amazon Cloud Drive / Ceph
Подскажите, кто знает, а в Amazon функция move в пределах одного контейнера работает аналогично Openstack Swift (Selectel) или позволяет выполняить мгновенные rename?
Я сам пользователь и занялся этой темой потому что стал замечать, что у меня стали пропадать письма.
Для полной отписки есть кнопка полной отписки и личный кабинет пользователя, где пользователь сам решает что подписывать и что отписывать.
Сейчас у меня установленно приложение mail.ru. И там есть кнопка отписаться, зная о вашем баге мне приходится кликать в мобильной версии по ссылке «оптисаться» из текста письма, а не пользоваться кнопкой приложения. Тем самым открывать браузер и тратя свое время. Меня еще что-то держит в этом сервисе, так как я в нем с 11 лет.
Я прекрасно понимаю, что сервис большой и поменять свой алгоритм просто очень сложно, но его можно оправдывать до бесконечности забывая о важных вещах:
1) Заголовок отписаться был придуман именно для отписки. В mail.ru это заголовок добавляет дополнительную кнопку «в спам» и пишет на ней «отписаться».
2) Любую подписку пользователь может оформить снова, mail.ru же решает за пользователя что такое сделать нельзя (приходится искать в папке «спам» нужное письмо и восстановливать, не каждый еще до этого додумается).
3) Пользователь нажимая «отписаться» желает отписаться от конкретной рассылки, а не от всех.
В данный момент я на всех своих серверах просто убрал этот заголовок по условию для mail.ru. Это не самое удобное для пользователя, но зато письма случайно в спам уже никто не отправляет.
Он ожидает отписаться от уведомлений по конкретному товару, а не по всему каталогу.
Вот выдуманный, но достаточно реалистичный пример:
Есть сайт, продает продукцию Apple по очень выгодным ценам. Товары кончаются очень быстро.
Пользователь заходит и подписывается на появление iPhone 7 нужного цвета на базе.
А еще там есть новые Mac Book. На который он тоже подписался, чтобы успеть купить раньше остальных и по выгодной цене.
После получение письма, что iPhone7 доступен, довольный пользователь нажимает отписаться и ждет появление Mac Book.
После того, как он отписался от iPhone 7 mail.ru добавляет весь каталог в спам. А ожидаемый Mac Book пользователь не получит, он не ожидал такого.
При этом самому интернет магазину никто не мешает сделать две кнопки «отписаться» от выбранного товара либо кнопка для отказа от всех подписок с сайта.
Под единичной рассылкой я подразумевал одного адресата подписанного на что-то уникальное, например на изменение товара в нашем каталоге.
Например: появление товара на складке. Товаров может быть сотни тысяч, пользователей может быть сотни тысяч. Конечно на поступление одного товара может подписаться неограниченное число пользователей.
В письме есть ссылка на отписку и служебный заголовок для отписки. Переход по этой ссылке отпишет от данного типа уведомления. Но данное действие не должно отписывать пользователя от других товаров, на которые он подписан.
Вы предусмотрели что целевых рассылок может быть сотни тысяч?
Предлагаете для каждой единичной рассылки делать свой адрес?
Я могу быть подписан на изменение цен 10 товаров в интернет магазине. Могу 3 из них купить и оставить подписку на 7 оставшихся товаров.
Я могу следить за статусом изменения сдачи кваритры. Есть много других примеров.
Для каждого товара делать отдельный email адрес и уж тем более поддомен не кажется хорошей идеей. Если будет надо я нажму «спам». Но если я хочу получать с этого адресата другие рассылки я нажму «отписаться».
Вы это уже исправили?
В своей статье я привел примеры и сделал тесты, по которым было отправлено одно письмо на мою почту и при нажатии «отписаться» оно моментально без предупреждений переносилось в спам, а последующие письма я переставал получать (они попадали в спам).
Найден еще один баг: если открыть несколько окон с сообщением (myApp.alert('Message')), а затем закрыть одно из них — пропадает подложка сообщений (затемняющий фон).
Еще более неприятным стало то, что метод myApp.hidePreloader() — скрывает все такие окна с сообщениями.
Framework7 очень хорош. Однако в предлагаемых шаблонах IOS и Material есть неприятная вещь — это скролл, залезающий под фиксированные панели. Если содержимого очень много, может получиться так, что при прокрутке страницы: скролла вообще не будет видно до определенного момента. Вот пример (для наглядности верхнюю панельку сделал полупрозрачной), баг наблюдался в Android и в IOS в хроме.
Это могло стать причиной выбора другого фрейморка, так как хочется остановиться на лучшем и работать уже с ним.
Мне очень понравилась событийная модель этого фреймворка, поэтому я нашел решение этой проблемы в замене padding на margin в стилях к контенту с фиксированными панельками, так же необходимо изменить свойство height: calc(100% — NNpx), где NNpx — резамеры вертикальных отступов margin.
Спасибо за развернутый ответ. Действительно дизайн jQuery UI ужасен. Но его дизайн совсем не нужно использовать в реальных проектах. Что касается новых разработок, то если разобраться, то тот же Angular UI решает иные задачи и иногда работает в связке с jQuery UI (может быт это и плохо, не уверен, на официальном сайте Angular UI представлены модули с использованием jQuery UI). Вероятно дело в том, что jQuery UI это исключительно набор инструментов для решения типовых задач. Это не фреймворк и сравнивать его с Angular (полноценным фреймворком) или Reactjs (языком шаблонов) некорректно. Конечно же, эта статья написана исключительно для тех, кто использует соответствующий плагин (виджет). Практически всегда желательно использовать тот плагин, который официально поддерживается вашим фреймворком.
Вот один из примеров модуля Angular, основанного на том же jQuery UI — https://angular-ui.github.io/ui-sortable/
Не понимаю, чем вам не нравится решение использовать datepicker для выбора промежутков дат?
Посоветуйте, пожалуйста, другое решение для datepicker, если знаете.
Попробуйте посмотреть заголовки письма, может быть там указан не url, а email для отписки. Если там действительно указан email, то интересно посмотреть так же папку "отправленные", попало ли туда письмо, отправленное на email адрес для отписки.
Предыдущий оратор абсолютно правильно написал:
"Я бы таким, кто правильно формирует рассылки и позволяет так удобно отписаться наоборот репутацию поднимал.". Это может быть утрировано — но вектор мысли абсолютно верный.
Я провел анализ и предупредил всех, кто делает рассылку с этим заголовком, что с Mail.ru это не рекомендуется. Я и у своего сервиса убрал этот заголовок. Меня крайне разочаровало, когда я после отписки не смог даже восстановить пароль, оказалось все письма попадали в спам без моего решения о том, что это спам.
Разделение на "@e.xxxx.ru и t.xxxx.ru" чтобы приходили письма — это скорее предложение-костыль от mail.ru. Это полезно в некоторых случаях, я это прекрасно понимаю. Но в данном случае, это к попаданию в спам не имеет ровно никакого отношения.
Странно слышать от специалиста Mail.ru такие рассуждения, не желая улучшить качество сервиса и прислушаться к людям, пользовтаелям и программистам.
Кнопка отписаться — должна предпринимать попытку "Отписаться".
Кнопка "Спам" — должна отправлять письмо в спам.
Вопрос заключался в том: что делать пользователю с рассылкой дальше? Никакая подписка заново не поможет, так как письма уже в спаме. Пользователь может и не узнать, что теперь все письма от этого сайта надо искать в спаме.
Это скорее был риторический вопрос, так как эта кнопка не должна помещать письма в спам вообще.
Разделение на разные домены часто используется в спам рассылках, так как такое мнение, что разделение это единственно верное решение — является заблуждением.
Абсолютное заблуждение, что "если добавить в спам первого отправителя @e.xxxx.ru, то второй отправитель t.xxxx.ru не должно попадать в спам". Он может тоже попасть в спам-лист ровно так же как может и не попасть совсем независимо от этого.
Почтовые сервисы должны уметь хорошо идентифицировать спам, идущий из генерируемых поддоменов и не полагаться на такое разделение рассыльщиками.
Дело в том — что это добровольное дело каждого рассыльщика: если он хочет разделять — пусть разделяет, если не хочет — пусть не разделяет.
Можно проводить разовые эксперементальные рассылки с других поддоменов, это действительно придает некоторую защищенность репутации основного домена — но это уже другая тема беседы.
На момент написания статьи при отписке через "List-Unsubscribe" письмо отправляется спам (вероятно и все последующие письма от домена этого отправителя). Пока это не исправят, пользоваться этим нет смысла. Отписка через "List-Unsubscribe" в вашем исполнении (в исполнении mail.ru) так же вредит отправителю, как и кнопка спам.
Подробнее обсуждается в статье: https://habrahabr.ru/post/280141/
1) Скорость rclone move в Openstack Swift (Selectel)
Для переменовывания директории использую команду:
Примерна скорость: 5G/min
Но если необходимо переместить большую директорию (или просто переиеновать), например 1T, это может занять 3.5 часа
Получается, что move рекурсивно переносит по одному файлу в новое место, вместо того, чтобы сделать rename этих файлов
Есть ли возможность перенести данные внутри одного контейнера быстро?
2) Скорость rclone move в Amazon S3 / Amazon Cloud Drive / Ceph
Подскажите, кто знает, а в Amazon функция move в пределах одного контейнера работает аналогично Openstack Swift (Selectel) или позволяет выполняить мгновенные rename?
Для полной отписки есть кнопка полной отписки и личный кабинет пользователя, где пользователь сам решает что подписывать и что отписывать.
Сейчас у меня установленно приложение mail.ru. И там есть кнопка отписаться, зная о вашем баге мне приходится кликать в мобильной версии по ссылке «оптисаться» из текста письма, а не пользоваться кнопкой приложения. Тем самым открывать браузер и тратя свое время. Меня еще что-то держит в этом сервисе, так как я в нем с 11 лет.
Я прекрасно понимаю, что сервис большой и поменять свой алгоритм просто очень сложно, но его можно оправдывать до бесконечности забывая о важных вещах:
1) Заголовок отписаться был придуман именно для отписки. В mail.ru это заголовок добавляет дополнительную кнопку «в спам» и пишет на ней «отписаться».
2) Любую подписку пользователь может оформить снова, mail.ru же решает за пользователя что такое сделать нельзя (приходится искать в папке «спам» нужное письмо и восстановливать, не каждый еще до этого додумается).
3) Пользователь нажимая «отписаться» желает отписаться от конкретной рассылки, а не от всех.
В данный момент я на всех своих серверах просто убрал этот заголовок по условию для mail.ru. Это не самое удобное для пользователя, но зато письма случайно в спам уже никто не отправляет.
Вот выдуманный, но достаточно реалистичный пример:
Есть сайт, продает продукцию Apple по очень выгодным ценам. Товары кончаются очень быстро.
Пользователь заходит и подписывается на появление iPhone 7 нужного цвета на базе.
А еще там есть новые Mac Book. На который он тоже подписался, чтобы успеть купить раньше остальных и по выгодной цене.
После получение письма, что iPhone7 доступен, довольный пользователь нажимает отписаться и ждет появление Mac Book.
После того, как он отписался от iPhone 7 mail.ru добавляет весь каталог в спам. А ожидаемый Mac Book пользователь не получит, он не ожидал такого.
При этом самому интернет магазину никто не мешает сделать две кнопки «отписаться» от выбранного товара либо кнопка для отказа от всех подписок с сайта.
Например: появление товара на складке. Товаров может быть сотни тысяч, пользователей может быть сотни тысяч. Конечно на поступление одного товара может подписаться неограниченное число пользователей.
В письме есть ссылка на отписку и служебный заголовок для отписки. Переход по этой ссылке отпишет от данного типа уведомления. Но данное действие не должно отписывать пользователя от других товаров, на которые он подписан.
Предлагаете для каждой единичной рассылки делать свой адрес?
Я могу быть подписан на изменение цен 10 товаров в интернет магазине. Могу 3 из них купить и оставить подписку на 7 оставшихся товаров.
Я могу следить за статусом изменения сдачи кваритры. Есть много других примеров.
Для каждого товара делать отдельный email адрес и уж тем более поддомен не кажется хорошей идеей. Если будет надо я нажму «спам». Но если я хочу получать с этого адресата другие рассылки я нажму «отписаться».
В своей статье я привел примеры и сделал тесты, по которым было отправлено одно письмо на мою почту и при нажатии «отписаться» оно моментально без предупреждений переносилось в спам, а последующие письма я переставал получать (они попадали в спам).
Еще более неприятным стало то, что метод myApp.hidePreloader() — скрывает все такие окна с сообщениями.
Это могло стать причиной выбора другого фрейморка, так как хочется остановиться на лучшем и работать уже с ним.
Мне очень понравилась событийная модель этого фреймворка, поэтому я нашел решение этой проблемы в замене padding на margin в стилях к контенту с фиксированными панельками, так же необходимо изменить свойство height: calc(100% — NNpx), где NNpx — резамеры вертикальных отступов margin.
Вот один из примеров модуля Angular, основанного на том же jQuery UI — https://angular-ui.github.io/ui-sortable/
Посоветуйте, пожалуйста, другое решение для datepicker, если знаете.
"Я бы таким, кто правильно формирует рассылки и позволяет так удобно отписаться наоборот репутацию поднимал.". Это может быть утрировано — но вектор мысли абсолютно верный.
Я провел анализ и предупредил всех, кто делает рассылку с этим заголовком, что с Mail.ru это не рекомендуется. Я и у своего сервиса убрал этот заголовок. Меня крайне разочаровало, когда я после отписки не смог даже восстановить пароль, оказалось все письма попадали в спам без моего решения о том, что это спам.
Разделение на "@e.xxxx.ru и t.xxxx.ru" чтобы приходили письма — это скорее предложение-костыль от mail.ru. Это полезно в некоторых случаях, я это прекрасно понимаю. Но в данном случае, это к попаданию в спам не имеет ровно никакого отношения.
Странно слышать от специалиста Mail.ru такие рассуждения, не желая улучшить качество сервиса и прислушаться к людям, пользовтаелям и программистам.
Кнопка отписаться — должна предпринимать попытку "Отписаться".
Кнопка "Спам" — должна отправлять письмо в спам.
Это скорее был риторический вопрос, так как эта кнопка не должна помещать письма в спам вообще.
Абсолютное заблуждение, что "если добавить в спам первого отправителя @e.xxxx.ru, то второй отправитель t.xxxx.ru не должно попадать в спам". Он может тоже попасть в спам-лист ровно так же как может и не попасть совсем независимо от этого.
Почтовые сервисы должны уметь хорошо идентифицировать спам, идущий из генерируемых поддоменов и не полагаться на такое разделение рассыльщиками.
Дело в том — что это добровольное дело каждого рассыльщика: если он хочет разделять — пусть разделяет, если не хочет — пусть не разделяет.
Можно проводить разовые эксперементальные рассылки с других поддоменов, это действительно придает некоторую защищенность репутации основного домена — но это уже другая тема беседы.
Подробнее обсуждается в статье: https://habrahabr.ru/post/280141/