Pull to refresh

Comments 41

Где гарантии, что файл просто не переименовывается и при желании доступен?
Либо перемещается в другое хранилище
Всё, что попало в интернет, остаётся в нём навсегда (с)
А причем тут гарантии, если черным по белому написано «файл помечается как удаленный»?
Фразы «файл удален» нет.
Подскажите, пожалуйста, а что за проблема с удалением? Почему сразу не удаляются фотографии, как это делаю на на домашнем PC? Это техническое ограничение или «политическое»?
Фрагментация. Нельзя брать просто так и удалять файлы. Лучше купить еще несколько жестких для новых файлов.
Кто минусует — поясните свои действия.
Еще скажите не из-за фрагментации жестких дисков контент не удаляется (как первопричина)?
Ага. Напомнило фразу о том, что «ВКонтакте не удаляет порнографию со своих серверов, чтобы избежать фрагментации (с)».
Еще ВКонтакте удивляет тем, что при добавлении аудиозаписи не проверяется ее хеш с остальными хешами (довольно быстрая операция, если использовать бинарные деревья). Хотя бы таким образом можно было бы сэкономить много места и избавиться от большого количества дубликатов.
Вы уверены что не проверяет? Всегда считал, что проверяет.
Только что проверил и удалось загрузить две идентичные аудиозаписи. Так что не проверяется ничего.
А каким образом Вы проверили, что у них теперь лежит два идентичных файла? Я так понимаю, то что они доступны по двум разным урлам не показатель, может симлинки просто.
А почему вы считаете, что то, что вы видите как результат загрузки — это то, что вы загрузили? Уверен, что хеш считается, а вам просто показывают ранее загруженный файл, просто имена совпадают.
это тупо, конечно… они бы хоть реагировали на точную длину файла и прерывали загрузку по приёму первого килобайта (если он совпадает, незачем дальше мучить капитана ФСБ, который всё это прослушивает)
Это неточный метод и не дает гарантий от ложного срабатывания прерывания.
А как это можно проверить и почему вы уверены, что хеш считается?
И логичней было бы предупреждать пользователя, что он загружает один и тот же файл.

Кроме того, зачем в поиске столько дубликатов? Достаточно только тех, обладающих уникальным хешом.
Только что мною было проверено, взят уникальный файл (записан на диктофон моего телефона):
1) залит в вк файл без ID3 тегов
2) залит он же, но с прописанными тегами внутри файла.
Результат: два разных файла в поисковой выдачи ВК (еще бы! ведь второй файл отличается от первого по начинке)
3) залит тот же самый файл, что пункт 2), но с другим именем.
Результат: ТРИ разных файла в моем плей-листе и два(!) файла в общей поисковой выдаче ВК.
Вывод: файл не был залит, потому что у последних двух одинаковы хеши.
А хэш от файла одинаковый? Сомневаюсь…
От переименования тело файла, и как следствие хэш, не изменяются.
2 записи в базе, один файл на диске :-)
UFO just landed and posted this here
При delayed allocation скорость записи снижается?
И еще, если можно, уточнить про прямую связь между Delayed allocation и фрагментацией.
По-моему, они не связаны.
Сложный вопрос. Если бы файл перемещался (логически, не физически) куда-то где он недоступен из веба, тогда можно было бы говорить о первопричине, а если он остаётся доступным по прямым ссылкам, то имхо, это решение не техническое.
Ну а нельзя через некоторое время удалять файл и проводить дефрагментацию скажем один раз в полгода? Во время дефрагментации делается копия прежнего диска и она доступна, в то время как первый дефрагментируется. После этого вторая копия удаляется и дефрагментированный диск становится доступным.

Или вообще удалять файл, а на его место записывать файл такого же размера или поменьше? В этом случае фрагментация тоже имеет место, но место будет экономиться больше.
Там не во время дефрагментации, там и так все файлы хранятся на 4х дисках одновременно (если меня не подводит инсайдерская информация).
Экономия здесь не особо нужна. То, что позволили вставлять видео прямо с ютуба и других сервисов — дает намного больше экономии, чем удалять файлы, а после еще заботиться о расположении файлов и вообще, тратить на это ресурсы.
Возможно, конечно, у них сейчас что-нибудь и изменилось.
Если люди так боятся фрагментации, то можно не удалять файл, а забивать его случайными нулями. Файл по-прежнему будет доступен, но это будет уже другой файл.
Было бы желание.
А что мешает затереть нулями и оставить? Пользователей думаю это бы устроило. Раз уж так критично «не удалять»
Я буду читать комментарии. Выше написали тоже самое.
А как вы собираетесь это делать на уровне файловой системы? Я не уверен, что операция по открытию файла в виде hex, его забивка нулями и сохранение перепишет его в том же месте, скорее наоборот, иначе при сбое переписываемый файл может быть безвозвратно потерян
UFO just landed and posted this here
2 года назад провел подобный эксперимент с Вконтакте. Фото (http://cs11483.vkontakte.ru/u6574010/132798359/x_d0650011.jpg) и ныне там.
Там же котик. Фото с котиками ни один сервис не удаляет.
Очень медленно работает сборщик мусора :-)
Мой Gist, созданный и удалённый ровно год назад (17.08.11, как интересно совпало) до сих пор клонируется по прямой ссылке. Наверняка в него ещё и пушить можно.

На сайте его не видно, по http-ссылке не доступен.
Да, gist в github'е. Они похоже тоже никогда ничего не удаляют.
Вот уже год специально наблюдаю за этим гистом.
Так вам кто-то и позволит по настоящему удалять материалы из вашего личного дела, не для этого оно открывается и ведется :)
Проблема прежде всего не в физическом удалении, а в удалении из публичного доступа.
Достаточно было бы перезаписывать удалённую фотографию динамически сгенерированной мусорной фоткой такого же размера.
Sign up to leave a comment.

Articles