Старая и наболевшая проблема, которая не позволяет в полной мере использовать облако Битрикс24.
Проблемы Битрикс Диска неоднократно обсуждались уже на форумах техподдержки, например здесь:
Проблемы, прежде всего, связаны с каким то "особенным" пониманием того как должно работать Облако и как в облаке должна проходить синхронизация файлов. При том, что подобного рода проблем не возникает при работе с облачными хранилищами типа Дропбокс, Бокс и прочих. При этом многие компании с которыми приходиться так или иначе общаться не готовы переходить на хранилище Битрикс.Диск именно по причине большого количества ошибок, непродуманных алгоритмов работы. Так как работа превращается в мучение и примерно 30% рабочего времени уходит на устранение проблем!
Итак, начнем...
Опыт нашей эксплуатации функционала Битрикс24.Диск (коробочная версия, виртуальная машина, Десктопные приложения у пользователей, текущая версия 4.0.18.34) почти уже за год окончательно разочаровал нас в способности компании Битрикс исправить ошибки работы синхронизации с облачным хранилищем. От версии к версии ошибки не исправляются, а только плодятся новые. Причем вариант "приспособиться" к работе не работает, так как с выходом каждой новой версии продукта ошибки только плодятся.
Опыт эксплуатации показал, что все, что можно сделать с файлами в группах корректно - это залить файлы в папку группы. Любые попытки сколько-нибудь активной работы с файлами приводят к полной неразберихе как на сервере так и у пользователей. При работе с файлами локально (на компьютере пользователя через проводник) постоянно высыпаются ошибки.
Вот лишь некоторые из ошибок:
1. Проблемы с переименованием файлов.
При переименовании файла (если, например было Документ.doc а стало Документ1.doc) совершенно непонятно как поведет себя система, может быть так, что на сервере будет оба файла, а у пользователя только один. Тоже самое может быть с переименованием папок. Может быть в итоге две папки и старая и новая, а может быть и одна. Причем у разных пользователей может быть по разному: у кого то два, у кого то один.
Были случаи когда в пустой папке пользователь создавал одну папку: Документы, у него на компьютере была одна папка: Документы, а на диске на сервере было две папки: Новая папка и Документы. Разбираемся в чем дело. По логике вещей понимаем, что приложение по правой кнопке мыши "Создать папку" создает по умолчанию новую папку с именем : Новая папка и дает возможность редактирования имени. Так вот если пользователь создал папку и не сразу указал ее правильное (нужное) имя, то на сервере будет создано две папки: Новая папка и, например, папка: Бухгалтерия.
Причем если использовать РАЗНЫЕ файловые менеджеры, то может получиться РАЗНЫЙ результат. Поведение для проводника может быть одно, а для Windows Commander – другое.
Более того, непродуманность данных алгоритмов приводит к потере данных!
Пример: В папке у пользователя есть файл: Договор.doc, пользователь решил его переименовать в Договор_черновик.doc, происходит следующее:
на сервере появляется два файла:
Договор.doc
Договор_черновик.doc
Затем кто-то зашел непосредственно на сервер и увидел два файла и решил удалить черновик. Что произойдет? У первого Пользователя удалится Договор_черновик.doc.
Есть, например, такая проблема: После того, как пользователь отредактировал Договор_черновик.doc и сохранил его как Договор.doc то по идее надо удалить файл: Договор_черновик.doc. Идем на сервер, удаляем на сервере файл: Договор_черновик.doc.
Через какое то время файл Договор_черновик.doc снова появляется, так как система не понимает что ей делать: на компьютере у пользователя она видит два файла: Договор_черновик.doc и Договор.doc и подсасывает на сервер снова файл: Договор_черновик.doc
2. При переносе файла из папки в папку непрогнозируемое поведение системы.
Бывает так, что файл переносится только локально у пользователя, причем в новой папке на сервере перенесенный файл появляется, а из старой папки не удаляется, что создает глобальную путаницу как в версиях файлах, так и у пользователей. Дальше больше: если зайти на портал и удалить файл принудительно из старой папки, то он удаляется, а потом, может появиться снова в старой папке, причем подсасывается от кого-то из пользователей у кого физический данный файл в папке в настоящий момент находится. Причем спрогнозировать поведение невозможно: иногда удаление файла непосредственно на сервере приводит к удалению файла у всех пользователей, а иногда на сервере файл удаляем, у двух пользователей файл удаляется локально, а у третьего не удаляется, и потом через какое то время файл подсасывается на сервер с компьютера третьего пользователя и затем с сервера подсасывается обратно на компьютеры остальных пользователей, где он ранее был удален.
3. Ложные синхронизации с компьютерами "спящих" пользователей.
Есть категория пользователей, которые пользуются компьютером, например, раз в неделю. Допустим вам удалось навести порядок в папке группы, пересортировать файлы, разложить их по правильным папкам, удалить ненужные, переименовать правильно нужные и т.д. И вот компьютер включил пользователь, который пользуется им раз в неделю и всё!!!!! Что будет происходить - непрогнозируемо!!! Бывали случаи, когда с компьютера этого пользователя на сервер подсасывалась старая структура папок и файлов, которых уже не было на сервере, после того как там навели порядок и все нужно делать по новой, вычищать старые файлы, удалять старые папки и т.д. Точно также с компьютера "спящего" пользователя могли загрузиться старые версии файлов и тогда приходится восстанавливать актуальные версии файлов только вручную! А с учетом того, что пользователи могут быть удаленные с плохим интернет-каналом, то можно ловить все эти хвосты неделями!!! Вроде бы все проверили, навели порядок, а тут: бац! Опять через неделю каике то сопли: то папка старая появилась, которая давно была удалена, то файл затерся старой версией.
4. Невозможность установить владельцем групповой папки конкретного пользователя.
После того как все попытки навести порядок в документах ни к чему не приводят - постоянно появляются старые (удаленные) файлы единственной идеей, которая приходит в голову, является идея сделать у кого то на компьютере эталон папки группы и синхронизировать этот эталон с сервером, чтобы тот в свою очередь залил эталон на компьютеры пользователей (удалил ненужное, добавил нужное и т.д.), но установить на папку группы владельцем конкретного пользователя - невозможно! И начиниается все по новой: ложные синхронизации от "спящих" пользователей и т.д.
5. Проблемы при отключении пользователя от папки группы.
Единственным вариантом как навести все-таки порядок хотя бы на сервере (окончательный вариант) - это отключить всех пользователей от диска группы, навести там порядок, затем всех подключить. Так вот, если в старых версиях такой вариант работал: пользователя отключаем, папка группы пропадает у него с диска. То теперь, в новой версии, отключение пользователя от папки группы приводит к тому, что папка группы становится локальной папкой пользователя (для каждого пользователя) и эта локальная папка пользователя начинает синхронизироваться в локальные папки каждого пользователя. То есть, если, например диск группы у вас 20Гб и 10 пользователей, то ВСЕ!!! Это СМЕРТЬ!!! У каждого из 10 пользователей появляется локальная папка "Группа Вася" на 20 Гб и все эти папки в общем размере 20*10 = 200 Гб начинают литься на сервер! И пока это все не зальется ничего нельзя сделать! Помогает только чуть ли не переустановка Битрикс.Дескотоп с удалением всего, что можно!
6. Создание ложных папок у пользователей. Часто бывают ситуации, когда например была папка "Заказы", потом ее переименовали в "Заказы и продажи" и через какое то время появилась снова папка Заказы, но уже с именем, например "Заказыi14782564" причем попытки ее удалить непосредственно на сервере приводят к тому, что она откуда то неизменно появляется!
7. Появление файлов вида Filename_username@portal_host. Файлы появляются спонтанно. То есть никто ничего не трогает ни на сервере ни локально и "вдруг" замечаешь, что в какой то папке все файлы которые до этого были: Filename1 Filename2 стали вдруг Filename1_username@portal_host Filename2_username@portal_host причем бывает так, что в папке находятся только эти файлы и больше ничего нет, а бывает так, что в папке находятся и оригинальные файлы и файлы с username@portal_host причем начинаешь смотреть их - и оригинал и дубликат имеют и одинаковый размер и одинаковые штампы времени. Такое поведение замечено при синхронизации «тяжелых» файлов. По всей видимости процесс «сверки» файлов и процесс закачивания не дружат между собой. И происходит следующее: Например, вы создали папку с документами на 20 Гб. Потом в эту папку добавили «тяжелый» файл, который закачивается на компьютер пользователя скажем 30 минут. В процессе закачивания файла система пытается провести «сверку» файлов и поскольку система в этот момент «занята» тем, что качает «тяжелый» файл, то «сверка» заканчивается ошибкой! И в результате система «помечает» все 20Гб как несинхронизированные файлы (файлы, которые система считает как конфликтующие копии на локальном компьютере) дописывая к файлам username@portal_host.
ЭТО КАТАСТРОФА!!! Так как при следующей синхронизации система ЗАНОВО скачает вам с сервера все 20Гб и сохранит при этом файлы как с оригинальными именами, так и файлы с дописанными хвостами username@portal_host. Мало того, что это минимум на сутки скачивания, так еще и вместо 20Гб у вас будет на локальном диске занято 40 Гб, а файлы с именами username@portal_host вам придется удалять ручками из каждой папки (если их не одна, а 1000) руками!
8. Ошибки и зависания при синхронизации. Часто наблюдается картина, что происходит ошибка синхронизации, которая указывается в виде: При синхронизации файла произошла ошибка, попробуйте повторить попытку позднее. И дальше создаются новые файлы, добавляется что-то, редактируется, но файлы с ошибкой не синхронизируются. Помогает только либо перезапуск Десктопного приложения, либо отключение Диска в настройках приложения и включения его снова, либо выход из приложения, очистка кеша и повторный запуск приложения. Это же касается другой ситуации, когда просто по неизвестной причине файл не синхронизировался в течение 1-2 минут (обычно это средний срок синхронизации). В анимированной иконке файла стоит вместо зеленой «галочки» синий «кругляшек» и не в течение 5, 10, одного часа и даже одного дня файл не синхронизируется. Помогает только перезапуск. А теперь представьте картину, если у вас работает 20 пользователей и у всех такие проблемы, то работать нельзя в принципе! Потому как админ только и делает, что перезапускает десктопное приложение целый день.
Теперь по части вопросов и выводов:
1. Складывается ощущение, что компания Битрикс вообще не тестирует продукт, особенно новые его версии, алгоритм явно сырой, так как при работе, скажем Dropbox таких проблем не возникает. Все эти ошибки можно отловить на коллективе из 4-5 человек, имитируя активную работу с файлами при работе в нескольких группах с объемом хранилища до 10Гб со средним каналом типичным для небольшого офиса 10Мбит.
2. Существуют ли какие то "стабильные" версии Битрикс24.Диск, на которых есть хотя бы понятные ошибки и понятные способы борьбы с ними? Например, можно было бы давать временные Полные права (права владельца папки группы) одному из пользователей, чтобы он раз в неделю (или каждый день) наводил порядок на диске группы и чтобы эталоном (то, что загрузится на сервер и потом разольется всем) была папка группы у этого человека на диске. Сейчас включение полных прав пользователю ничего не решает. Ошибки диагностируются как при переносе файлов из папки в папку, так и при переименовании файлов или папок.
3. Существуют ли какие то "специальные" рекомендации как все можно настроить исходя из тех алгоритмов, которые мы бы хотели у себя видеть? Например подключение владельцем диска группы - модератора группы? К примеру, безумно неудобно когда ни один из пользователей не обладает правами на удаление файла из группы (только через удаление на сервере). Но мы нашли некое решение: в папке группы есть папка Корзина, если пользователь хочет удалить файл, то он переносит его в папку Корзина, а потом уже папка Корзина вычищается с сервера. Но и это работает не всегда! Например в каких то версиях "перенос" файла через проводник Битрикс воспринимал как удаление файла из папки X и создание файла в папке Y. В результате у пользователя файла в папке X не было, а на сервере и у всех пользователей два одинаковых файла было и в папке X и в папке Y. Причем, если делать тоже самое через Total Commander (клавиша F6), то все переносилось корректно! Но и такая схема в последних версиях перестала работать!
4. Почему компания Битрикс не использует понятные алгоритмы OpenSource решений, которые для облачных хранилищ существуют уже как десять лет и работают вполне успешно (с возможностью отката состояния, корректной обработки конфликтующих копий и т.д. и т.п.) Долго ли компания Битрикс собирается изобретать велосипед и трепать нервы пользователям, которые ЗАПЛАТИЛИ НЕМАЛЫЕ ДЕНЬГИ ЗА ПРОДУКТ?
Понятно, что на большинство этих вопросов мы не получим ответа, но хотя бы донесите позицию рядового пользователя до руководства!!! Именно Битрикс.Диск является для вас ахиллесовой пятой! Вплоть до того, что известные нам компании, которые используют Битрикс именно по этой причине думают об альтернативных платформах. Неужели на самом деле нельзя протестировать работу алгоритмов на примере реальной компании и выработать какой-то понятный алгоритм или взять готовое решение, коих, в том числе опробованных, десятки...
У нас, как у приобретателя коммерческой лицензии нет желания ее продлевать на следующий период, если эти проблемы не будут решены!
Сделайте ПОНЯТНЫЙ алгоритм работы, с ПОНЯТНОЙ интсрукцией: как удалять файлы корректно, как переносить файлы из папки в папку, как переименовывать файлы, как сделать эталон, чтобы можно было быть уверенным, что если вы ОДИН раз навели порядок в ваших папках, то это уже 100%-ная гарантия, то именно в таком виде все разольется всем пользователям…
Мы готовы провести эксперименты, если это будет кому то интересно и указать на ошибки, но мы не можем быть тестерами системы! Сейчас мы и так тратим 30% рабочего времени на разбор данных «завалов».
И последнее, наше разочарование именно ТАКОЙ работой продукта Битрикс-Диск заставляет нас говорить об этом не только на форумах, но и обсуждать эти вопросы в сообществе специалистов. Мы, в том числе, являемся участниками разного рода опросов и конференций по IT-тематике, где будем доносить свою позицию и свое мнение о продукте Битрикс.Диск до широкого круга пользователей, с учетом того, что почти за год эксплуатации позитивных сдвигов не видно!
Если ситуация никак не меняется, значит ее не хотят менять!
Проблемы Битрикс Диска неоднократно обсуждались уже на форумах техподдержки, например здесь:
Проблемы, прежде всего, связаны с каким то "особенным" пониманием того как должно работать Облако и как в облаке должна проходить синхронизация файлов. При том, что подобного рода проблем не возникает при работе с облачными хранилищами типа Дропбокс, Бокс и прочих. При этом многие компании с которыми приходиться так или иначе общаться не готовы переходить на хранилище Битрикс.Диск именно по причине большого количества ошибок, непродуманных алгоритмов работы. Так как работа превращается в мучение и примерно 30% рабочего времени уходит на устранение проблем!
Итак, начнем...
Опыт нашей эксплуатации функционала Битрикс24.Диск (коробочная версия, виртуальная машина, Десктопные приложения у пользователей, текущая версия 4.0.18.34) почти уже за год окончательно разочаровал нас в способности компании Битрикс исправить ошибки работы синхронизации с облачным хранилищем. От версии к версии ошибки не исправляются, а только плодятся новые. Причем вариант "приспособиться" к работе не работает, так как с выходом каждой новой версии продукта ошибки только плодятся.
Опыт эксплуатации показал, что все, что можно сделать с файлами в группах корректно - это залить файлы в папку группы. Любые попытки сколько-нибудь активной работы с файлами приводят к полной неразберихе как на сервере так и у пользователей. При работе с файлами локально (на компьютере пользователя через проводник) постоянно высыпаются ошибки.
Вот лишь некоторые из ошибок:
1. Проблемы с переименованием файлов.
При переименовании файла (если, например было Документ.doc а стало Документ1.doc) совершенно непонятно как поведет себя система, может быть так, что на сервере будет оба файла, а у пользователя только один. Тоже самое может быть с переименованием папок. Может быть в итоге две папки и старая и новая, а может быть и одна. Причем у разных пользователей может быть по разному: у кого то два, у кого то один.
Были случаи когда в пустой папке пользователь создавал одну папку: Документы, у него на компьютере была одна папка: Документы, а на диске на сервере было две папки: Новая папка и Документы. Разбираемся в чем дело. По логике вещей понимаем, что приложение по правой кнопке мыши "Создать папку" создает по умолчанию новую папку с именем : Новая папка и дает возможность редактирования имени. Так вот если пользователь создал папку и не сразу указал ее правильное (нужное) имя, то на сервере будет создано две папки: Новая папка и, например, папка: Бухгалтерия.
Причем если использовать РАЗНЫЕ файловые менеджеры, то может получиться РАЗНЫЙ результат. Поведение для проводника может быть одно, а для Windows Commander – другое.
Более того, непродуманность данных алгоритмов приводит к потере данных!
Пример: В папке у пользователя есть файл: Договор.doc, пользователь решил его переименовать в Договор_черновик.doc, происходит следующее:
на сервере появляется два файла:
Договор.doc
Договор_черновик.doc
Затем кто-то зашел непосредственно на сервер и увидел два файла и решил удалить черновик. Что произойдет? У первого Пользователя удалится Договор_черновик.doc.
Есть, например, такая проблема: После того, как пользователь отредактировал Договор_черновик.doc и сохранил его как Договор.doc то по идее надо удалить файл: Договор_черновик.doc. Идем на сервер, удаляем на сервере файл: Договор_черновик.doc.
Через какое то время файл Договор_черновик.doc снова появляется, так как система не понимает что ей делать: на компьютере у пользователя она видит два файла: Договор_черновик.doc и Договор.doc и подсасывает на сервер снова файл: Договор_черновик.doc
2. При переносе файла из папки в папку непрогнозируемое поведение системы.
Бывает так, что файл переносится только локально у пользователя, причем в новой папке на сервере перенесенный файл появляется, а из старой папки не удаляется, что создает глобальную путаницу как в версиях файлах, так и у пользователей. Дальше больше: если зайти на портал и удалить файл принудительно из старой папки, то он удаляется, а потом, может появиться снова в старой папке, причем подсасывается от кого-то из пользователей у кого физический данный файл в папке в настоящий момент находится. Причем спрогнозировать поведение невозможно: иногда удаление файла непосредственно на сервере приводит к удалению файла у всех пользователей, а иногда на сервере файл удаляем, у двух пользователей файл удаляется локально, а у третьего не удаляется, и потом через какое то время файл подсасывается на сервер с компьютера третьего пользователя и затем с сервера подсасывается обратно на компьютеры остальных пользователей, где он ранее был удален.
3. Ложные синхронизации с компьютерами "спящих" пользователей.
Есть категория пользователей, которые пользуются компьютером, например, раз в неделю. Допустим вам удалось навести порядок в папке группы, пересортировать файлы, разложить их по правильным папкам, удалить ненужные, переименовать правильно нужные и т.д. И вот компьютер включил пользователь, который пользуется им раз в неделю и всё!!!!! Что будет происходить - непрогнозируемо!!! Бывали случаи, когда с компьютера этого пользователя на сервер подсасывалась старая структура папок и файлов, которых уже не было на сервере, после того как там навели порядок и все нужно делать по новой, вычищать старые файлы, удалять старые папки и т.д. Точно также с компьютера "спящего" пользователя могли загрузиться старые версии файлов и тогда приходится восстанавливать актуальные версии файлов только вручную! А с учетом того, что пользователи могут быть удаленные с плохим интернет-каналом, то можно ловить все эти хвосты неделями!!! Вроде бы все проверили, навели порядок, а тут: бац! Опять через неделю каике то сопли: то папка старая появилась, которая давно была удалена, то файл затерся старой версией.
4. Невозможность установить владельцем групповой папки конкретного пользователя.
После того как все попытки навести порядок в документах ни к чему не приводят - постоянно появляются старые (удаленные) файлы единственной идеей, которая приходит в голову, является идея сделать у кого то на компьютере эталон папки группы и синхронизировать этот эталон с сервером, чтобы тот в свою очередь залил эталон на компьютеры пользователей (удалил ненужное, добавил нужное и т.д.), но установить на папку группы владельцем конкретного пользователя - невозможно! И начиниается все по новой: ложные синхронизации от "спящих" пользователей и т.д.
5. Проблемы при отключении пользователя от папки группы.
Единственным вариантом как навести все-таки порядок хотя бы на сервере (окончательный вариант) - это отключить всех пользователей от диска группы, навести там порядок, затем всех подключить. Так вот, если в старых версиях такой вариант работал: пользователя отключаем, папка группы пропадает у него с диска. То теперь, в новой версии, отключение пользователя от папки группы приводит к тому, что папка группы становится локальной папкой пользователя (для каждого пользователя) и эта локальная папка пользователя начинает синхронизироваться в локальные папки каждого пользователя. То есть, если, например диск группы у вас 20Гб и 10 пользователей, то ВСЕ!!! Это СМЕРТЬ!!! У каждого из 10 пользователей появляется локальная папка "Группа Вася" на 20 Гб и все эти папки в общем размере 20*10 = 200 Гб начинают литься на сервер! И пока это все не зальется ничего нельзя сделать! Помогает только чуть ли не переустановка Битрикс.Дескотоп с удалением всего, что можно!
6. Создание ложных папок у пользователей. Часто бывают ситуации, когда например была папка "Заказы", потом ее переименовали в "Заказы и продажи" и через какое то время появилась снова папка Заказы, но уже с именем, например "Заказыi14782564" причем попытки ее удалить непосредственно на сервере приводят к тому, что она откуда то неизменно появляется!
7. Появление файлов вида Filename_username@portal_host. Файлы появляются спонтанно. То есть никто ничего не трогает ни на сервере ни локально и "вдруг" замечаешь, что в какой то папке все файлы которые до этого были: Filename1 Filename2 стали вдруг Filename1_username@portal_host Filename2_username@portal_host причем бывает так, что в папке находятся только эти файлы и больше ничего нет, а бывает так, что в папке находятся и оригинальные файлы и файлы с username@portal_host причем начинаешь смотреть их - и оригинал и дубликат имеют и одинаковый размер и одинаковые штампы времени. Такое поведение замечено при синхронизации «тяжелых» файлов. По всей видимости процесс «сверки» файлов и процесс закачивания не дружат между собой. И происходит следующее: Например, вы создали папку с документами на 20 Гб. Потом в эту папку добавили «тяжелый» файл, который закачивается на компьютер пользователя скажем 30 минут. В процессе закачивания файла система пытается провести «сверку» файлов и поскольку система в этот момент «занята» тем, что качает «тяжелый» файл, то «сверка» заканчивается ошибкой! И в результате система «помечает» все 20Гб как несинхронизированные файлы (файлы, которые система считает как конфликтующие копии на локальном компьютере) дописывая к файлам username@portal_host.
ЭТО КАТАСТРОФА!!! Так как при следующей синхронизации система ЗАНОВО скачает вам с сервера все 20Гб и сохранит при этом файлы как с оригинальными именами, так и файлы с дописанными хвостами username@portal_host. Мало того, что это минимум на сутки скачивания, так еще и вместо 20Гб у вас будет на локальном диске занято 40 Гб, а файлы с именами username@portal_host вам придется удалять ручками из каждой папки (если их не одна, а 1000) руками!
8. Ошибки и зависания при синхронизации. Часто наблюдается картина, что происходит ошибка синхронизации, которая указывается в виде: При синхронизации файла произошла ошибка, попробуйте повторить попытку позднее. И дальше создаются новые файлы, добавляется что-то, редактируется, но файлы с ошибкой не синхронизируются. Помогает только либо перезапуск Десктопного приложения, либо отключение Диска в настройках приложения и включения его снова, либо выход из приложения, очистка кеша и повторный запуск приложения. Это же касается другой ситуации, когда просто по неизвестной причине файл не синхронизировался в течение 1-2 минут (обычно это средний срок синхронизации). В анимированной иконке файла стоит вместо зеленой «галочки» синий «кругляшек» и не в течение 5, 10, одного часа и даже одного дня файл не синхронизируется. Помогает только перезапуск. А теперь представьте картину, если у вас работает 20 пользователей и у всех такие проблемы, то работать нельзя в принципе! Потому как админ только и делает, что перезапускает десктопное приложение целый день.
Теперь по части вопросов и выводов:
1. Складывается ощущение, что компания Битрикс вообще не тестирует продукт, особенно новые его версии, алгоритм явно сырой, так как при работе, скажем Dropbox таких проблем не возникает. Все эти ошибки можно отловить на коллективе из 4-5 человек, имитируя активную работу с файлами при работе в нескольких группах с объемом хранилища до 10Гб со средним каналом типичным для небольшого офиса 10Мбит.
2. Существуют ли какие то "стабильные" версии Битрикс24.Диск, на которых есть хотя бы понятные ошибки и понятные способы борьбы с ними? Например, можно было бы давать временные Полные права (права владельца папки группы) одному из пользователей, чтобы он раз в неделю (или каждый день) наводил порядок на диске группы и чтобы эталоном (то, что загрузится на сервер и потом разольется всем) была папка группы у этого человека на диске. Сейчас включение полных прав пользователю ничего не решает. Ошибки диагностируются как при переносе файлов из папки в папку, так и при переименовании файлов или папок.
3. Существуют ли какие то "специальные" рекомендации как все можно настроить исходя из тех алгоритмов, которые мы бы хотели у себя видеть? Например подключение владельцем диска группы - модератора группы? К примеру, безумно неудобно когда ни один из пользователей не обладает правами на удаление файла из группы (только через удаление на сервере). Но мы нашли некое решение: в папке группы есть папка Корзина, если пользователь хочет удалить файл, то он переносит его в папку Корзина, а потом уже папка Корзина вычищается с сервера. Но и это работает не всегда! Например в каких то версиях "перенос" файла через проводник Битрикс воспринимал как удаление файла из папки X и создание файла в папке Y. В результате у пользователя файла в папке X не было, а на сервере и у всех пользователей два одинаковых файла было и в папке X и в папке Y. Причем, если делать тоже самое через Total Commander (клавиша F6), то все переносилось корректно! Но и такая схема в последних версиях перестала работать!
4. Почему компания Битрикс не использует понятные алгоритмы OpenSource решений, которые для облачных хранилищ существуют уже как десять лет и работают вполне успешно (с возможностью отката состояния, корректной обработки конфликтующих копий и т.д. и т.п.) Долго ли компания Битрикс собирается изобретать велосипед и трепать нервы пользователям, которые ЗАПЛАТИЛИ НЕМАЛЫЕ ДЕНЬГИ ЗА ПРОДУКТ?
Понятно, что на большинство этих вопросов мы не получим ответа, но хотя бы донесите позицию рядового пользователя до руководства!!! Именно Битрикс.Диск является для вас ахиллесовой пятой! Вплоть до того, что известные нам компании, которые используют Битрикс именно по этой причине думают об альтернативных платформах. Неужели на самом деле нельзя протестировать работу алгоритмов на примере реальной компании и выработать какой-то понятный алгоритм или взять готовое решение, коих, в том числе опробованных, десятки...
У нас, как у приобретателя коммерческой лицензии нет желания ее продлевать на следующий период, если эти проблемы не будут решены!
Сделайте ПОНЯТНЫЙ алгоритм работы, с ПОНЯТНОЙ интсрукцией: как удалять файлы корректно, как переносить файлы из папки в папку, как переименовывать файлы, как сделать эталон, чтобы можно было быть уверенным, что если вы ОДИН раз навели порядок в ваших папках, то это уже 100%-ная гарантия, то именно в таком виде все разольется всем пользователям…
Мы готовы провести эксперименты, если это будет кому то интересно и указать на ошибки, но мы не можем быть тестерами системы! Сейчас мы и так тратим 30% рабочего времени на разбор данных «завалов».
И последнее, наше разочарование именно ТАКОЙ работой продукта Битрикс-Диск заставляет нас говорить об этом не только на форумах, но и обсуждать эти вопросы в сообществе специалистов. Мы, в том числе, являемся участниками разного рода опросов и конференций по IT-тематике, где будем доносить свою позицию и свое мнение о продукте Битрикс.Диск до широкого круга пользователей, с учетом того, что почти за год эксплуатации позитивных сдвигов не видно!
Если ситуация никак не меняется, значит ее не хотят менять!
