Сразу оговорюсь, я не разработчик - я заказчик и эксплуататор с базовыми навыками.
Есть у нас сервис для автоматизации внутренних процессов организации. И для хранения относительно большого количества фотографий мы используем Яндекс диск через WebDAV. Фотографии мы храним в папках по месяцам. И вот недавно у нас пропали результаты всех наших трудов за 3 месяца. Т.е. пропали 3 папки из корня Яндекс диска.
В корзине этих папок нет, но зато появились 3 файла фотографий с именами этих папок. В истории видно, что эти файлы были перемещены из другой папки. Да, действительно у нас в системе предусмотрена возможность переносить данные из месяца в месяц и при этом фотографии перемещаются между папками. Да, где-то внутри нашей системы была ошибка и каким-то образом 3 файла получили имена как у папок и переместились в корень. Но вот Яндекс диск взял и заменил папки файлами.
В панике начал писать в техподдержку. Описал все обстоятельства и слёзно попросил по возможности восстановить папки и их содержимое. На свой запрос получил формализованный ответ, что мы понимаем, что ситуация вас огорчила и да, сказать по правде, я немного огорчился от этой ситуации, потеряв результаты трудов за 3 месяца. Ну и дальше, что мы не принимаем участия в разработке ваших приложений, не гарантируем работоспособность сторонних решений и не несём ответственности. Ваши папки удалены и если они удалены через WebDAV, то они не появляются в корзине. Их не вернуть.
Я проверил данный кейс Яндекс диска в браузере. Вы тоже можете повторить этот финт.
Рецепт:
Создаете папку "123" в корне. Можно насыпать туда файлов.
Создаете файл "123" (без расширения) в любой папке.
Перемещаете файл в корень. Яндекс ругается, что такой ФАЙЛ уже есть и предлагает заменить.
После замены мы получаем файл в корне и лишаемся папки и возможности её восстановить.
Интересно, что у этого файла иконка папки, но при этом в списке он после всех папок и у него есть размер, как у файла. При клике открывается как файл - в моём случае картинка.
Я и этот вариант описал техподдержке, но пока мне не удалось пробиться на уровень выше менеджера, который отвечает формально. Может быть действительно вернуть файлы нет технической возможности.
Вот не знаю, баг это или фича Яндекса, но вероятность потерять данные существует. В одной точке сошлись 3 обстоятельства: особенность Яндекса, желание нашего менеджера изменить месяц и ошибка в нашем коде. Самое интересное, что наша систем работает уже несколько лет, но, как оказалось, раз в году и палка стреляет.
Комментарии (63)
Firz
01.12.2022 11:51+20Все люди делятся на тех, кто еще не делает бэкапы, кто делает бэкапы и кто делает бэкапы и периодически проверяет что из них можно восстановиться.
ramiil
01.12.2022 11:55+23Сожалею, что автор потерял свои файлы. Пусть его история будет предсотережением для тех, кто не делает бэкапы и доверяет всё облакам.
Бэкап должен быть
Бэкап и оригинальные данные никогда не хранятся в одном месте
Бэкапы должны делаться регулярно.
Бэкапы должны валидироваться.
Должно быть настроено уведомление о бэкапе и о его валидации.
Кроме того, время от времени нужно производить ручную проверку бэкапов.
RAID - это не бэкап. Даже RAID6. Но лучше RAID чем не RAID.
Нужно разделение на холодный и горячий бэкап. Холодный бэкап хранится на физически отключенном носителе, в безопасном месте, вдали от горячего бэкапа и места хранения бэкапируемых данных.
Старый бэкап удаляется только после валидации нового.
У вас должно быть как минимум три точки восстановления(т.е. три полных бэкапа за разную дату)
Бэкап-сервер должен сам забирать файлы для резервного копирования с удалённого сервера, а не наоборот
Шифрование бэкапов так же имеет смысл.
Ну и стандартное параноидальное брюзжание об опенсорсе, о недопустимости использования проприетарного софта и облачных решений.
Popadanec
01.12.2022 15:27+2Пункт с холодным бэкапом должен быть на первом месте. А то словили вирус шифровальщик и привет.
zuek
02.12.2022 12:27У меня "холодные бэкапы" хранятся на обычных серверах, на двух разных площадках, без сейфов и отключения от сети, но удалённо на них можно подключиться только по сертификату, и да - они сами забирают бэкапы. Так как с шифровальщиком я уже как-то сталкивался, и да, бэкапы тогда сливались "в сетевую папку"...
Samhuawei
01.12.2022 11:56-3А в чём баг состоит? В том что иконка не поменялась? Так это видимо кеш на конкретном устройстве, на другом поменяется.
Насколько я понимаю в любой ФС если скопировать файл в директорию где есть такой же файл он тупо перезапишется.
В FAT было ещё смешнее - если скопировать папку саму в себя получится рекурсия и место на диске быстро закончится.
ne555
01.12.2022 12:47+1Бага никакого нет, автор не знает, как работают ФС. Причем здесь ЯД вообще, если он перезаписал данные самостоятельно и жалуется..
Да, где-то внутри нашей системы была ошибка и каким-то образом 3 файла получили имена как у папок и переместились в корень. Но вот Яндекс диск взял и заменил папки файлами.
Вот не знаю, баг это или фича Яндекса
Это не баг и не фича, а работа ФС и Яндекс тут вообще н е п р и ч е м.
Hidden text
На ПК заменил папку с 5 файлами под именем "фоточки" на изображение "фоточки" папка удалилась и в корзине ее тоже нет. 
M_AJ
01.12.2022 13:43+4Это не баг и не фича, а работа ФС
Убунта в такой ситуации просто сообщает о невозможности записи "поверх", Windows пишет что папка с таким именем уже существует, и предлагает переименовать, то что Яндекс позволяет в этой ситуации замену, это все же особенность Яндекса. С учетом того, что это сервис для обычного пользователя, особенность так себе.
12rbah
02.12.2022 09:54+2Не знаю правильно ли я понял, но WebDAV это вроде возможность работать через api, а при работе через есть свойство overwrite которое позволит избежать таких ситуаций, и либо разраб который делал либу для работы либо поставил это свойство в true либо это сделал пользователь. Т.к. яндекс диск возвращает ошибку при попытке записи файла с таким же именем, в целом наверное это не лучшее решение из возможных, но если используешь api, то наверное стоит знать об этом и почитать документацию, т.к. об этом в ней написано, хотя в целом непонятно кто конкретно виноват.
andetlt Автор
01.12.2022 13:46+3Фича - это особенность работы файловой системы. Да, автор не знал как работают файловые системы. Да, я прямо признаю, что была ошибка в скрипте перемещения и он неправильно обозвал файлы и эти названия совпали с названиями папок. Предупреждаю тех, кто может ещё не знает. Прошу у вас прощения, что не знал. В браузере можно случайно лишиться всех файлов, если ты вдруг стал так переписывать и не гений в ФС.
А ведь там вовсе не файл "123"
И вообще в браузере я просто пробовал воспроизвести ошибку. По факту проблема произошла при работе через API. Так что не было никаких окошечек и никто ничего не подтверждал. Жалуюсь на Яндекс, что не идут навстречу, ведь файлы скорее всего живы.
khajiit
01.12.2022 14:44+5и не гений в ФС
Во времена DOS и книг Фигурнова объяснялось, что папка (directory тогда еще) — это файл особого вида, и каждое имя в ФС должно быть уникально в пределах того же уровня иерархии, потому что конфликт имен приведет к замещению. Не знали этого только двоечники.
А гении разрабатывали ФС.Теперь же, оказывается, для этого надо быть гением.
andetlt Автор
01.12.2022 15:05+6Я ж написал, что я пользователь. Ладно, сдаюсь. Пошёл читать Фигурнова. И жене дам почитать на всякий. Считаю, что без короткого теста по Фигурнову нельзя давать пользователям залогиниться в систему))) Яндекс.диск не для двоечников)
Firz
01.12.2022 15:30+2Справедливости ради, если какой-то сторонний скрипт или приложение через API перезаписало нужные папки и не выдало предупреждение — это проблема этого стороннего скрипта или приложения. Так что да, сторонние скрипты не для двоечников и их разработчики должны понимать что делают, как работают файловые системы и тот же API для которого они что-то пишут.
andetlt Автор
01.12.2022 15:50+2В скрипте нет обработки исключительных ситуаций, а она должна была возникнуть и по хорошему не должно было произойти ничего.
skozharinov
02.12.2022 04:30+3Исключительная ситуация возникнуть может только при выставлении заголовка
Overwrite: Fв запросе MOVE, по умолчанию файл/папка перезаписывается, и это поведение задокументировано у Яндекс.Диска и прописано в стандарте WebDAV.
K0styan
01.12.2022 15:29+1В те времена, если я правильно помню, у них ещё и расширение .DIR было, только на уровне интерфейса оно скрывалось. Поэтому файл "123" и папка "123" (на деле 123.DIR) тоже бы существовали без проблем - так что столкнуться с ситуацией было сложновато.
С другой стороны, в более новых ФС папки дополнительно обозначены признаком в файловой таблице, так что перепутать их системе должно быть сложно, и ничто не мешает разрешить одинаковые названия.
khajiit
01.12.2022 15:59+2Хм. Помнится, FAT12 в первой редакции не имела иерархии вообще, а .dir — это Macromedia Director…
Одинаковые названия разрешить нельзя: имя и атрибуты — разные сущности. И в работе с файлами они учитываются отдельно от имени.
OldPronStar
03.12.2022 09:55маленько не так помните - там у каждой записи каталога есть байт атрибутов, в котором выставляются необходимые биты ("только для чтения", "архивный", "скрытый" и "каталог")))
MaximRV
02.12.2022 08:06+1Так а если попробовать теперь поверх этого файла скопировать папку созданную в другой папке, ну чтобы в таблице файловой системы этот "особый файл" с видом "файл" перезаписался "особым файлом" с видом "папка". вдруг всё что хранилось внутри папки осталось
khajiit
02.12.2022 09:55… если переименовать *.txt в *.mp3, то можно будет послушать, а если в *.avi — то даже и посмотреть!
Содержимое папки же заменится.
Вариантов тут не так уж и много: или в саппорт и (если у них есть снепшоты) надеяться на удачу, или восстанавливать из бэкапа.MaximRV
02.12.2022 21:09содержимое папки не равно содержимое файла. содержимое папки - это записи в таблице файлов с привязкой, к какой папке файлы привязаны. Есть ненулевая вероятность что файлы на диске сохранились, как и записи о них в таблице. Если точнее, то папка - файл нулевой длины. И внутри этого файла соответственно ничего не лежит. Но зато имя этого файла упоминается в таблице файловой системы как указатель - где лежат вложенные файлы и папки. Получается, можно надеяться, что создатели той файловой системы не предусмотрели удаление вложенных файлов физически с диска и удаление записей о них. При перезаписи папки - файлом с тем же именем. Ведь не было же Команды именно Удалить. Намекает на таковую вероятность особенности отображения этого файла, указывающие что это как бы папка. Иконка папки же у него неспроста.
khajiit
02.12.2022 21:15+1Вы укапываетесь в подробности реализации знакомой вам ФС, не зная, что у яндекса не-NTFS.
При этом не понимаете, что если, как вы предложили выше, перезаписать файл перезаписавший папку,другой папкой, то по этому же имени станет доступна эта другая папка, а не та, которую удалили.
skozharinov
02.12.2022 21:44+2можно надеяться, что создатели той файловой системы не предусмотрели удаление вложенных файлов физически с диска и удаление записей о них
если в системе SSD, почти наверняка ФС просто отправит trim и всё, после этого там может быть что угодно
MaximRV
02.12.2022 21:23+2Итак. Не даёт Папкой перезаписать файл при попытке переместить интерактивно. Т.е. Файл Папкой заменить удалось. А вот Папкой файл не удаётся. Изначально во всплывающем окне он предлагает сразу папку переименовать с постфиксом - текущей датой. Но после удаления постфикса. Записать таки не даёт. Не реагирует на нажатие кнопки записи. т.к. защита, по крайней мере в интерактивном режиме есть. По API я не пробовал. Пусть автор заметки пробует.\
И пожалуйста, khajiit не считайте всех собеседников идиотами. Некоторые упомянутые вами книжки не только читали. Но и писали.
Это я к вашему:
"… если переименовать *.txt в *.mp3, то можно будет послушать, а если в *.avi — то даже и посмотреть! "
Слишком толсто.
А ведь исходя из Интерактивного! поведения Яндекс-диска - это даже не косяк. Это Залёт. Ибо Даже если подтвердив перезапись папки файлом можно потерять доступ к содержимому папки (я специально опустил формулировку "похерить файлы", ибо ещё неизвестно что с ними), то обратная операция, потенциально более безобидная, т.к. в результате её мы можем потерять данные лишь одного файла, который превращается в папку.
Впрочем, замечу, что при перезаписи Папки файлом. Изображение всё же меняется после обновления страницы (я просто закрыл, и через некоторое время открыл заново яндекс-диск, Обновить страницу я не жал, но уверен что и простое обновление страницы тоже подгрузит уже изменённое изображение для этого файла/папки.khajiit
02.12.2022 22:40Слишком толсто
Это ирония и отсылка к одному вошедшему в баш случаю.
Простите, если обидел.Некоторые упомянутые вами книжки не только читали. Но и писали.
Тогда становится еще более загадочно, чем вы руководствовались, предлагая примерно такое же по
толстотеосмысленности действие…
Потому как если бы это могло сработать, то, во-первых, это был бы большой такой баг с восстановлением "удаленных" файлов, а во-вторых, правильная реализация потребовала бы огромного количества ресурсов, целенапраленно потраченых для именно такого поведения, в том числе проверки а не совпадет ли перемещенная папка с одной из ранее удаленных*, что само по себе иррационально.Но давайте таки не будем ссориться на ровном месте.
Поведение, конечно, хоть ожидаемое, но потерпевшему легче от этого не становится.
foya
01.12.2022 11:57У меня уже два года тикет висит по поводу ошибки на яндекс услугах))) до сих пор исправить не могут, периодически пишут
BeLord
01.12.2022 11:57На мой взгляд, это такая прекрасная дыра в безопасности. В принципе, я бы апеллировал тех. поддержке, что проблема не только в том, что пользователь потерял свои файлы, а в том, что не исправление этого прекрасного механизма может привести к лавине не приятных последствий для сервиса, не буду описывать алгоритм он и так очевиден.
kAIST
01.12.2022 13:07+1На мой взгляд, это такая прекрасная дыра в безопасности.
Дыра состоит в стандартном и очевидном поведении файловых систем? Если бы их скрипт бэкапил не под WebDav а на другой физический диск, то было бы абсолютно так же.
не буду описывать алгоритм он и так очевиден.
Мне не очевиден. Расскажите?
slavius
01.12.2022 12:13+1Т.е. я.диск предупреждает при перемещении файла о дубликате? И при подтверждении удаляет одноимённую папку?
Или удаляет и при переименовании тоже?
andetlt Автор
01.12.2022 12:16При перемещении точно да. При переименовании (я тоже пробовал) я не понял. Один раз получилось, второй раз ругался, что такой файл уже существует и не дал переименовать.
KStrebkov
01.12.2022 12:19Не понимаю что хочет автор, описывая данный кейс как проблему. У вас есть путь /123. По одному и тому же пути в операционных системах не может быть одновременно и папки /123 и файла /123. Вам выдается предупреждение что будет замена по этому пути папки на файл. После замены (еще раз повторюсь замены) автор почему то ожидает что останутся и папка и файл.
andetlt Автор
01.12.2022 12:23+6Автор за свои 40 годиков первый раз столкнулся с этим и хочет предупредить таких же неумёх. Оказывается даже Windows так не умеет делать. В предупреждении было написано, что такой файл существует без намёков на папку. Опять же это был эксперимент. По API, думаю, просто выполняется перемещение. А ожидаю я, что останутся файлы, потому что наверное физически они не перезаписались и не перетёрлись, и писал в поддержку именно с этой надеждой.
toivo61
01.12.2022 14:21+1Ну да, в RSX-11, такой проблемы не было, там уже было версионирование файлов.
Да и в Вандрайве две корзины.
Popadanec
01.12.2022 15:32В окнах может быть сколько угодно файлов с одинаковым названием в одной папке/корне диска(естественно с учётом адресного пространства), главное чтобы расширение было разное.
А яндекс похоже наличие расширения вообще никак не учитывает.khajiit
01.12.2022 19:55+3Расширение — это часть имени. Оно семантически в юзерспейсе выделяется, для удобства работы.
crawlingroof
01.12.2022 12:29+5Возможные грабли, это то что тебя забанят без объяснения причин и диск удалят. Благо что там ерунда хранилась, стучался в ТП - без результата
h1pp0
01.12.2022 14:30+2Не рекомендую использовать Яндекс.Диск для работы и/или через WebDAV. Несколько лет назад они практически отключили его для существующих клиентов искусственным ограничением скорости.
Lebets_VI
01.12.2022 22:12Я вот не знал об этом и сегодня, из-за этого, удалил подписку на 3Тб на яндексе, а думал приспособить их для бекапов :(
dimirsen
01.12.2022 15:11-3Уникальности много не бывает. Надо делать префикс в имени: file_ для файлов и folder_ для папок
Iv38
01.12.2022 16:17+4Ну, кстати… Тут многие ругают автора, что очевидное поведение ему неочевидно. Оказывается, мне тоже было неочевидно. Да, я знаю как работают файловые системы, и что папка тоже файл. Но я никогда даже не задумывался что произойдёт при совпадении имён файла и папки. А ведь получается, так можно похоронить всю иерархию директорий со всеми файлами. И это гораздо катастрофичнее может быть, чем случайная замена одного файла.
Понятно, что ответ тут один — бэкапы. Мало ли что вообще может случиться с файловой системой.
GennPen
01.12.2022 17:12+6Но я никогда даже не задумывался что произойдёт при совпадении имён файла и папки.
Могу сказать больше, раньше (да и сейчас тоже) иногда проворачивали фокус чтобы автоматически не ставились левые программы: создаешь файл с именем каталога в место куда программа автоматически устанавливается.
serge-sb
02.12.2022 11:31Было такое давно на одной из первых работ. Собственно: на компьютерах пользователей был установлен клиент radmin'а, чтобы админы могли удалённо подключаться. Причём делать это они могли без уведомлений. Мне это не понравилось, поэтому удаляю radmin.exe... и нет, не даёт удалить. Далее стандартный виндовый способ: переименовываю этот файл и создаю папку с названием radmin.exe. Далее перезагрузка и никаких radmin'ов.
vconst
02.12.2022 09:37+1Понятно, что ответ тут один — бэкапы
Ответ тут один — учить матчастьIv38
02.12.2022 17:28+4Мой опыт разработки показывает, что всю матчасть нельзя изучить, а кода без багов не бывает. Так что бэкапы.
vconst
03.12.2022 09:22Вроде как выяснили, что для такого копирования, начало принудительно включить флаг «перезаписать в любом случае, без вопросов». То есть человек должен был прочитать мануал на эту конкретную команду, чтобы скртпт не ругался, когда ему надо перезаписать директорию
То есть, программист намеренно использовал что-то типа: «rm -rf», а потом удивляется «Как это так? Зачем директорию то удалять?». Потому что я не представляю, зачем специально ставить эту опцию и не понимаю — как ее можно поставить случайно.
Хотя вариант есть. «Программист» копипастил код непойми откуда, не понимая что там и зачем
rombell
03.12.2022 16:17Выше же вроде пояснили, что такое поведение — по умолчанию, наоборот, что бы отключить, надо найти и поставить флаг.
Quackerjack
01.12.2022 17:17Лет 5 назад, кажется, можно было заварить отличную "кашу" из данных, если включить дедупликацию на машине с установленным Яндекс Диском. Данные были консистентными только на машине где была включена дедупликацию, а на других уже синхронизированная Яндексом каша =))
Ilyayarovykh
02.12.2022 14:03удивительно, что Яндекс. еще не ответил тут) Репостни на vc)) А лучше на Дзен)
хотя по сути, вам все ответили - вы. правда считаете, что из вредности или пренебрежения к ламерам не хотят восстановить?)
"Ваши папки удалены и если они удалены через WebDAV, то они не появляются в корзине. Их не вернуть. "
GennPen
02.12.2022 17:22удивительно, что Яндекс. еще не ответил тут) Репостни на vc)) А лучше на Дзен)
А что он должен ответить? Что автор темы ССЗБ?
kvazimoda24
02.12.2022 23:21+1Тоже не понимаю, чего хочет автор. У него там какой-то скрипт с непонятным поведением. Этот скрипт мог и просто rm -rf / сделать.
Дальше автор пошёл в ТП Яндекса просить, по сути, услугу бекапа данных, которую ему никто не обещал. Сам же никаких бекапов, судя по всему, не делал. Хотя, откуда такая вера в сохранность данных в Яндекс.Диске? Ну вот забанят они аккаунт, и всё, кранты. Данных нет.
GennPen
Очередное доказательство, что хранить все важные данные в одном месте - не лучшая идея.