Началось всё с того, что мне понадобилось обменяться фото с друзьями с очередной поездки. Создали папку и расшарили её всем.
Тут я обнаружил, что у меня всего ~1.5 гб свободно из 10. Ну, думаю, надо почистить я.диск. Ранее, я залил в общую папку фото и видео с прошлой поездки. Зашёл в неё, обнаружил там несколько сотен (или, может, тысяч) файлов. Недолго думая, я выделил все файлы и удалил, думая, что все участники уже скачали данные. Место освободилось. Спустя какое-то время мне написали участники общей шары, что зачем я удалил все файлы. Начал разбираться.
И вот наглядные картинки эксперимента.
До подключения к тестовому общему ресурсу, который мне дал друг.
И после подключения:
Этож банальная жадность, чтоб люди покупали дополнительное место, но я готов заплатить, если считаться будут только мои файлы и это будет честно. А если я подключусь к папке, которая будет превышать моё доступное пространство?
Считаю, что пользователям Яндекс.Диска нужно знать о такой особенности, а Яндексу предпринять меры по улучшению качества своего сервиса. Надеюсь этот пост будет полезным.
ps. Множество объяснений моей позиции в комментариях, прошу потратить время на их прочтение. Если так заведено у всех — это не всегда значит, что это правильно.
Комментарии (14)
TheRipper
14.07.2015 02:46Уже не помню где я это слышал, но тема в том что общие шары могут как бы работать поперек лимитов на место.
Если их содержимое привязывать только к пользователю-создателю-шары, то можно было бы с помощью дополнительных пользователей расширять себе место на Диске.
Если учитывать создателей файлов, то квота тоже увеличивается, хоть и только на read. При этом можно, например, сделать пользователя-бота, который будет залитые в общую шару файлы перезагружать от своего имени :)
Но это так, фантастика. Может быть, могли бы и не ограничивать.
mafet Автор
14.07.2015 03:02Ну да, ботов можно насоздавать, но это же надо уметь, чтоб было удобно! А если умеешь, то можно расширить своё хранилище и сейчас без проблем — свой индекс файлов и папок с автоматическим распределением по аккаунтам без использования шары. Если готов работать с кластером ботов, то это не будет сложной задачей.
То есть сейчас схема, используемая Яндексом просто защищает их от создания нечестными пользователями удобного хранилища, которое будет пополняться ботами, при одном read-only владельце, при этом доставляя неудобства всем остальным честным пользователем.
При том, что сложность написания схемы с ботами-загрузчиками сопоставима со схемой написания распределённой системы хранилищ с применением ботов, которая описана в первом абзаце.
vvovas
14.07.2015 06:51Я в свое время писал кластер ботов, он был даже мультиоблачным — дропбокс, скайдрайв, яндекс и еще несколько. Причем в каждом по несколько аккаунтов. Потом правда надобность в таком хранилище отпала.
Andoryu
14.07.2015 03:29Тоже столкнулся с не очень понятным (и не очень приятным) поведением Я.Диска, только немного в другой ситуации.
У меня свободно около 2гб из 17, и я не могу принять приглашение на доступ в расшаренную папку от другого человека размером (условно) 10гб, видимо потому, что у меня нехватает места.
rule
Дропбокс работает точно так-же. Как по мне — всё честно. Общая папка становится частью всех ваших папок, значит она должна считаться. А все файлы в ней тоже общие, по идее если вы отключите «расшаривание», то чужие файлы не пропадут, так как они уже стали вашими. просто у каждого будет своя копия.
Как по мне — всё логично.
mafet Автор
А в чём логика? Если так ещё у кого-то, то это не значит, что это правильно. Зачем нужны кучи облачных хранилищ, если у всех всё одинаково, надо быть лучше других, чтоб быть более конкурентоспособными!
5 гб залитых файлов для облачной компании, расшаренной хоть между 100 пользователями остаются всё теми же 5 гб на дисках этой компании.
При отключении от такой папки, хозяину (или даже всем участникам) общего ресурса должно придти предложение, сохранить эти файлы у себя в счёт своего диска или они станут недоступны для хозяина (или любому из участников). Пока все участники не отказались от сохранения этих файлов у себя, данные должны храниться какое-то время по таймауту. При этом, если данные никто не забрал, должно прийти уведомление тем, кто ещё не принял решение о том, что данные скоро будут удалены. Если же кто-то из участников всё же принял решение о использовании своего места для данных отключившегося пользователя, данные вновь становятся доступны для всех участников шары и данные переходят новому хозяину. До тех пор, тем, кто отказался от шары, повторная синхронизация и скачивание через веб должны быть недоступны. При этом в любом случае, данные не должны удаляться с диска любого из участников шары.
Эту логику не так сложно сделать с точки зрения ПО.
Это я описал кейс отключения от шары, так, чтоб подсчёт был честен, при этом я мог бы не удалять данные из-за того, что в общей папке залито слишком много для моего «диска» чужих данных.
OnYourLips
Общие папки используются как инструмент синхронизации документов.
Логично, что при удалении файла с одной машины, это действие синхронизируется, и файлы удаляются везде.
Что касается расчёта объема, то тут тоже все правильно: все эти файлы в общей папке становятся вашими (у файлов нет владельца, только автор последнего изменения).
mafet Автор
Ну владелец на самом деле должен быть в недрах яндекса, иначе если кто-то зальёт детское порно в общую папку, что — под откос пойдут все участники папки? И вопрос тут не про удаление или изменение, а про подсчёт занятой квоты.
mafet Автор
И да, логично, что автор последнего изменения — уже владелец. Яндекс.диск — это не git, где изменения инкрементальные. В нём нет версионности.
rule
более того, если одинаковые файлы лежат у разных пользователей, сервер может хранить только одну копию.
Это оптимизация компании. Компания пытается снизить накладные расходы/себестоимость и получить максимальную выгоду. Это смысл компании.
Всё логично и правильно. Вам же считают общем данных именно в том количестве, в котором у вас есть к ним доступ.
mafet Автор
Это уже непрозрачно для пользователя. Я ничего против не имею, если облачный сервис будет оптимизировать таким образом затраты на хранение одинаковых данных, более того, уверен, что они так и делают, но даже взять квоты в частности в linux. Учитываться в них будут только те файлы, которые залил я.
mafet Автор
И да, согласно вашему изменённому комментарию, если считают доступные данные, то нужно ввести тарификацию по скачиваемому объёму данных. Это тоже ок (ведь при синхронизации тратятся ресурсы облачной компании), если разумная стоимость, если данные не были загружены мной или данные загружаются на новое, вновь подключенное под моей учётной записью устройство, если даже это было переподключение с повторной загрузкой данных. Только это совсем другая модель тарификации.
rule
Придумал отличную аналогию: Вы с соседом скачали один фильм. Трафик вам и соседу засчитали по отдельности. Но на серверах компании оно может где-то там закэшировалось. В итоге по интернет каналу компании прошел этот фильм только один раз.
mafet Автор
Да я не против, чтоб провайдер кешировал что-то, но я против, если сосед залил в общую папку с ним, а моя квота места в этой папке была захвачена моя без моего ведома и согласия.