СоХабр закрыт.

С 13.05.2019 изменения постов больше не отслеживаются, и новые посты не сохраняются.

| сохранено

H Нечестный подсчёт объёма данных в Яндекс.Диске при общем доступе в черновиках

Хранение данных
Обнаружил тут неприятное поведение Яндекс.Диска при общем доступе, которое в итоге привело к потере данных.

Началось всё с того, что мне понадобилось обменяться фото с друзьями с очередной поездки. Создали папку и расшарили её всем.

Тут я обнаружил, что у меня всего ~1.5 гб свободно из 10. Ну, думаю, надо почистить я.диск. Ранее, я залил в общую папку фото и видео с прошлой поездки. Зашёл в неё, обнаружил там несколько сотен (или, может, тысяч) файлов. Недолго думая, я выделил все файлы и удалил, думая, что все участники уже скачали данные. Место освободилось. Спустя какое-то время мне написали участники общей шары, что зачем я удалил все файлы. Начал разбираться.

image
В итоге оказалось, что в случае, если я становлюсь участником общей шары, то место уменьшается на объём залитых файлов всеми участниками, а не только на тот объём, который залил непосредственно я. Так же меня возмутило то, что я не могу удалить только свои файлы, хотя это ни к чему не привело бы по итогу, даже если бы я выделил в общей папке только те файлы, которые залил только я. Так же, меня никак не предупредили, что данные других участников так же будут стёрты, что меня больше всего расстроило. По идее должен быть вопрос «Удалить все файлы или только ваши?». В итоге получается что, я должен отключиться от общего ресурса, чтоб почистить место? А если я хотел бы оставить этот доступ? Я согласен с тем, что мне надо удалить свои файлы, чтоб почистить место, но как это сделать, если файлов сотни или тысячи?

И вот наглядные картинки эксперимента.

До подключения к тестовому общему ресурсу, который мне дал друг.


И после подключения:

Этож банальная жадность. А если я подключусь к папке, которая будет превышать моё доступное пространство?

Считаю, что пользователям Яндекс.Диска нужно знать о такой особенности, а Яндексу предпринять меры по улучшению качества своего сервиса. Надеюсь этот пост будет полезным.
яндекс.диск, жадность, облачное хранилище
1235
  mafet

комментарии (14)

+9
rule ,  
Дропбокс работает точно так-же. Как по мне — всё честно. Общая папка становится частью всех ваших папок, значит она должна считаться. А все файлы в ней тоже общие, по идее если вы отключите «расшаривание», то чужие файлы не пропадут, так как они уже стали вашими. просто у каждого будет своя копия.

Как по мне — всё логично.
–5
+1 –6
mafet ,   * (был изменён)
А в чём логика? Если так ещё у кого-то, то это не значит, что это правильно. Зачем нужны кучи облачных хранилищ, если у всех всё одинаково, надо быть лучше других, чтоб быть более конкурентоспособными!

5 гб залитых файлов для облачной компании, расшаренной хоть между 100 пользователями остаются всё теми же 5 гб на дисках этой компании.

При отключении от такой папки, хозяину (или даже всем участникам) общего ресурса должно придти предложение, сохранить эти файлы у себя в счёт своего диска или они станут недоступны для хозяина (или любому из участников). Пока все участники не отказались от сохранения этих файлов у себя, данные должны храниться какое-то время по таймауту. При этом, если данные никто не забрал, должно прийти уведомление тем, кто ещё не принял решение о том, что данные скоро будут удалены. Если же кто-то из участников всё же принял решение о использовании своего места для данных отключившегося пользователя, данные вновь становятся доступны для всех участников шары и данные переходят новому хозяину. До тех пор, тем, кто отказался от шары, повторная синхронизация и скачивание через веб должны быть недоступны. При этом в любом случае, данные не должны удаляться с диска любого из участников шары.

Эту логику не так сложно сделать с точки зрения ПО.

Это я описал кейс отключения от шары, так, чтоб подсчёт был честен, при этом я мог бы не удалять данные из-за того, что в общей папке залито слишком много для моего «диска» чужих данных.
+1
OnYourLips ,  
Общие папки используются как инструмент синхронизации документов.
Логично, что при удалении файла с одной машины, это действие синхронизируется, и файлы удаляются везде.
Что касается расчёта объема, то тут тоже все правильно: все эти файлы в общей папке становятся вашими (у файлов нет владельца, только автор последнего изменения).
–1
mafet ,  
Ну владелец на самом деле должен быть в недрах яндекса, иначе если кто-то зальёт детское порно в общую папку, что — под откос пойдут все участники папки? И вопрос тут не про удаление или изменение, а про подсчёт занятой квоты.
–1
mafet ,  
И да, логично, что автор последнего изменения — уже владелец. Яндекс.диск — это не git, где изменения инкрементальные. В нём нет версионности.
0
rule ,   * (был изменён)
более того, если одинаковые файлы лежат у разных пользователей, сервер может хранить только одну копию.
Это оптимизация компании. Компания пытается снизить накладные расходы/себестоимость и получить максимальную выгоду. Это смысл компании.
Всё логично и правильно. Вам же считают общем данных именно в том количестве, в котором у вас есть к ним доступ.
0
mafet ,  
Это уже непрозрачно для пользователя. Я ничего против не имею, если облачный сервис будет оптимизировать таким образом затраты на хранение одинаковых данных, более того, уверен, что они так и делают, но даже взять квоты в частности в linux. Учитываться в них будут только те файлы, которые залил я.
0
mafet ,  
И да, согласно вашему изменённому комментарию, если считают доступные данные, то нужно ввести тарификацию по скачиваемому объёму данных. Это тоже ок (ведь при синхронизации тратятся ресурсы облачной компании), если разумная стоимость, если данные не были загружены мной или данные загружаются на новое, вновь подключенное под моей учётной записью устройство, если даже это было переподключение с повторной загрузкой данных. Только это совсем другая модель тарификации.
0
rule ,  
Придумал отличную аналогию: Вы с соседом скачали один фильм. Трафик вам и соседу засчитали по отдельности. Но на серверах компании оно может где-то там закэшировалось. В итоге по интернет каналу компании прошел этот фильм только один раз.
0
mafet ,  
Да я не против, чтоб провайдер кешировал что-то, но я против, если сосед залил в общую папку с ним, а моя квота места в этой папке была захвачена моя без моего ведома и согласия.
+2
TheRipper ,   * (был изменён)
Уже не помню где я это слышал, но тема в том что общие шары могут как бы работать поперек лимитов на место.
Если их содержимое привязывать только к пользователю-создателю-шары, то можно было бы с помощью дополнительных пользователей расширять себе место на Диске.
Если учитывать создателей файлов, то квота тоже увеличивается, хоть и только на read. При этом можно, например, сделать пользователя-бота, который будет залитые в общую шару файлы перезагружать от своего имени :)

Но это так, фантастика. Может быть, могли бы и не ограничивать.
0
mafet ,   * (был изменён)
Ну да, ботов можно насоздавать, но это же надо уметь, чтоб было удобно! А если умеешь, то можно расширить своё хранилище и сейчас без проблем — свой индекс файлов и папок с автоматическим распределением по аккаунтам без использования шары. Если готов работать с кластером ботов, то это не будет сложной задачей.

То есть сейчас схема, используемая Яндексом просто защищает их от создания нечестными пользователями удобного хранилища, которое будет пополняться ботами, при одном read-only владельце, при этом доставляя неудобства всем остальным честным пользователем.

При том, что сложность написания схемы с ботами-загрузчиками сопоставима со схемой написания распределённой системы хранилищ с применением ботов, которая описана в первом абзаце.
0
vvovas ,  
Я в свое время писал кластер ботов, он был даже мультиоблачным — дропбокс, скайдрайв, яндекс и еще несколько. Причем в каждом по несколько аккаунтов. Потом правда надобность в таком хранилище отпала.
0
Andoryu ,  
Тоже столкнулся с не очень понятным (и не очень приятным) поведением Я.Диска, только немного в другой ситуации.

У меня свободно около 2гб из 17, и я не могу принять приглашение на доступ в расшаренную папку от другого человека размером (условно) 10гб, видимо потому, что у меня нехватает места.