Сразу оговорюсь, я не разработчик - я заказчик и эксплуататор с базовыми навыками.

Есть у нас сервис для автоматизации внутренних процессов организации. И для хранения относительно большого количества фотографий мы используем Яндекс диск через WebDAV. Фотографии мы храним в папках по месяцам. И вот недавно у нас пропали результаты всех наших трудов за 3 месяца. Т.е. пропали 3 папки из корня Яндекс диска.

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

В панике начал писать в техподдержку. Описал все обстоятельства и слёзно попросил по возможности восстановить папки и их содержимое. На свой запрос получил формализованный ответ, что мы понимаем, что ситуация вас огорчила и да, сказать по правде, я немного огорчился от этой ситуации, потеряв результаты трудов за 3 месяца. Ну и дальше, что мы не принимаем участия в разработке ваших приложений, не гарантируем работоспособность сторонних решений и не несём ответственности. Ваши папки удалены и если они удалены через WebDAV, то они не появляются в корзине. Их не вернуть.

Я проверил данный кейс Яндекс диска в браузере. Вы тоже можете повторить этот финт.

Рецепт:

  1. Создаете папку "123" в корне. Можно насыпать туда файлов.

  2. Создаете файл "123" (без расширения) в любой папке.

  3. Перемещаете файл в корень. Яндекс ругается, что такой ФАЙЛ уже есть и предлагает заменить.

  4. После замены мы получаем файл в корне и лишаемся папки и возможности её восстановить.

Интересно, что у этого файла иконка папки, но при этом в списке он после всех папок и у него есть размер, как у файла. При клике открывается как файл - в моём случае картинка.

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

Вот не знаю, баг это или фича Яндекса, но вероятность потерять данные существует. В одной точке сошлись 3 обстоятельства: особенность Яндекса, желание нашего менеджера изменить месяц и ошибка в нашем коде. Самое интересное, что наша систем работает уже несколько лет, но, как оказалось, раз в году и палка стреляет.

Комментарии (63)


  1. GennPen
    01.12.2022 11:50
    +14

    Очередное доказательство, что хранить все важные данные в одном месте - не лучшая идея.


  1. Firz
    01.12.2022 11:51
    +20

    Все люди делятся на тех, кто еще не делает бэкапы, кто делает бэкапы и кто делает бэкапы и периодически проверяет что из них можно восстановиться.


    1. shasoftX
      01.12.2022 14:14
      +8

      Следующий шаг - проверка что восстанавливается всё правильно. А то я тут месяц-два назад обнаружил что не всё верно восстанавливается.


      1. Didimus
        02.12.2022 10:42

        А дальше - бумажный архив в сейфе


  1. ramiil
    01.12.2022 11:55
    +23

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

    1. Бэкап должен быть

    2. Бэкап и оригинальные данные никогда не хранятся в одном месте

    3. Бэкапы должны делаться регулярно.

    4. Бэкапы должны валидироваться.

    5. Должно быть настроено уведомление о бэкапе и о его валидации.

    6. Кроме того, время от времени нужно производить ручную проверку бэкапов.

    7. RAID - это не бэкап. Даже RAID6. Но лучше RAID чем не RAID.

    8. Нужно разделение на холодный и горячий бэкап. Холодный бэкап хранится на физически отключенном носителе, в безопасном месте, вдали от горячего бэкапа и места хранения бэкапируемых данных.

    9. Старый бэкап удаляется только после валидации нового.

    10. У вас должно быть как минимум три точки восстановления(т.е. три полных бэкапа за разную дату)

    11. Бэкап-сервер должен сам забирать файлы для резервного копирования с удалённого сервера, а не наоборот

    12. Шифрование бэкапов так же имеет смысл.

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


    1. Popadanec
      01.12.2022 15:27
      +2

      Пункт с холодным бэкапом должен быть на первом месте. А то словили вирус шифровальщик и привет.


      1. YMA
        01.12.2022 16:00

        Если это не планомерное вторжение в сеть, а просто случайное попадание шифровальщика - то и 11-ый пункт будет кстати. Вообще, чеклист у @ramiilочень полезный.


      1. zuek
        02.12.2022 12:27

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


    1. screwer
      02.12.2022 03:52

      3-2-1


  1. Samhuawei
    01.12.2022 11:56
    -3

    А в чём баг состоит? В том что иконка не поменялась? Так это видимо кеш на конкретном устройстве, на другом поменяется.

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

    В FAT было ещё смешнее - если скопировать папку саму в себя получится рекурсия и место на диске быстро закончится.


    1. ne555
      01.12.2022 12:47
      +1

      Бага никакого нет, автор не знает, как работают ФС. Причем здесь ЯД вообще, если он перезаписал данные самостоятельно и жалуется..

      Да, где-то внутри нашей системы была ошибка и каким-то образом 3 файла получили имена как у папок и переместились в корень. Но вот Яндекс диск взял и заменил папки файлами.

      Вот не знаю, баг это или фича Яндекса

      Это не баг и не фича, а работа ФС и Яндекс тут вообще н е п р и ч е м.

      Hidden text
      На ПК заменил папку с 5 файлами под именем "фоточки" на изображение "фоточки" папка удалилась и в корзине ее тоже нет.
      На ПК заменил папку с 5 файлами под именем "фоточки" на изображение "фоточки" папка удалилась и в корзине ее тоже нет.


      1. M_AJ
        01.12.2022 13:43
        +4

        Это не баг и не фича, а работа ФС

        Убунта в такой ситуации просто сообщает о невозможности записи "поверх", Windows пишет что папка с таким именем уже существует, и предлагает переименовать, то что Яндекс позволяет в этой ситуации замену, это все же особенность Яндекса. С учетом того, что это сервис для обычного пользователя, особенность так себе.


        1. 12rbah
          02.12.2022 09:54
          +2

          Не знаю правильно ли я понял, но WebDAV это вроде возможность работать через api, а при работе через есть свойство overwrite которое позволит избежать таких ситуаций, и либо разраб который делал либу для работы либо поставил это свойство в true либо это сделал пользователь. Т.к. яндекс диск возвращает ошибку при попытке записи файла с таким же именем, в целом наверное это не лучшее решение из возможных, но если используешь api, то наверное стоит знать об этом и почитать документацию, т.к. об этом в ней написано, хотя в целом непонятно кто конкретно виноват.


          1. andetlt Автор
            02.12.2022 13:05

            Ваша правда.


      1. andetlt Автор
        01.12.2022 13:46
        +3

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

        А ведь там вовсе не файл "123"
        И вообще в браузере я просто пробовал воспроизвести ошибку. По факту проблема произошла при работе через API. Так что не было никаких окошечек и никто ничего не подтверждал. Жалуюсь на Яндекс, что не идут навстречу, ведь файлы скорее всего живы.


        1. khajiit
          01.12.2022 14:44
          +5

          и не гений в ФС

          Во времена DOS и книг Фигурнова объяснялось, что папка (directory тогда еще) — это файл особого вида, и каждое имя в ФС должно быть уникально в пределах того же уровня иерархии, потому что конфликт имен приведет к замещению. Не знали этого только двоечники.
          А гении разрабатывали ФС.


          Теперь же, оказывается, для этого надо быть гением.


          1. andetlt Автор
            01.12.2022 15:05
            +6

            Я ж написал, что я пользователь. Ладно, сдаюсь. Пошёл читать Фигурнова. И жене дам почитать на всякий. Считаю, что без короткого теста по Фигурнову нельзя давать пользователям залогиниться в систему))) Яндекс.диск не для двоечников)


            1. Firz
              01.12.2022 15:30
              +2

              Справедливости ради, если какой-то сторонний скрипт или приложение через API перезаписало нужные папки и не выдало предупреждение — это проблема этого стороннего скрипта или приложения. Так что да, сторонние скрипты не для двоечников и их разработчики должны понимать что делают, как работают файловые системы и тот же API для которого они что-то пишут.


              1. andetlt Автор
                01.12.2022 15:50
                +2

                В скрипте нет обработки исключительных ситуаций, а она должна была возникнуть и по хорошему не должно было произойти ничего.


                1. skozharinov
                  02.12.2022 04:30
                  +3

                  Исключительная ситуация возникнуть может только при выставлении заголовка Overwrite: F в запросе MOVE, по умолчанию файл/папка перезаписывается, и это поведение задокументировано у Яндекс.Диска и прописано в стандарте WebDAV.


                  1. vconst
                    02.12.2022 09:33

                    Первое предложение в инструкции: «Ну что, сломал?..»


          1. K0styan
            01.12.2022 15:29
            +1

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

            С другой стороны, в более новых ФС папки дополнительно обозначены признаком в файловой таблице, так что перепутать их системе должно быть сложно, и ничто не мешает разрешить одинаковые названия.


            1. khajiit
              01.12.2022 15:59
              +2

              Хм. Помнится, FAT12 в первой редакции не имела иерархии вообще, а .dir — это Macromedia Director…


              Одинаковые названия разрешить нельзя: имя и атрибуты — разные сущности. И в работе с файлами они учитываются отдельно от имени.


            1. OldPronStar
              03.12.2022 09:55

              маленько не так помните - там у каждой записи каталога есть байт атрибутов, в котором выставляются необходимые биты ("только для чтения", "архивный", "скрытый" и "каталог")))


        1. MaximRV
          02.12.2022 08:06
          +1

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


          1. khajiit
            02.12.2022 09:55

            … если переименовать *.txt в *.mp3, то можно будет послушать, а если в *.avi — то даже и посмотреть!


            Содержимое папки же заменится.
            Вариантов тут не так уж и много: или в саппорт и (если у них есть снепшоты) надеяться на удачу, или восстанавливать из бэкапа.


            1. MaximRV
              02.12.2022 21:09

              содержимое папки не равно содержимое файла. содержимое папки - это записи в таблице файлов с привязкой, к какой папке файлы привязаны. Есть ненулевая вероятность что файлы на диске сохранились, как и записи о них в таблице. Если точнее, то папка - файл нулевой длины. И внутри этого файла соответственно ничего не лежит. Но зато имя этого файла упоминается в таблице файловой системы как указатель - где лежат вложенные файлы и папки. Получается, можно надеяться, что создатели той файловой системы не предусмотрели удаление вложенных файлов физически с диска и удаление записей о них. При перезаписи папки - файлом с тем же именем. Ведь не было же Команды именно Удалить. Намекает на таковую вероятность особенности отображения этого файла, указывающие что это как бы папка. Иконка папки же у него неспроста.


              1. khajiit
                02.12.2022 21:15
                +1

                Вы укапываетесь в подробности реализации знакомой вам ФС, не зная, что у яндекса не-NTFS.
                При этом не понимаете, что если, как вы предложили выше, перезаписать файл перезаписавший папку,другой папкой, то по этому же имени станет доступна эта другая папка, а не та, которую удалили.


              1. skozharinov
                02.12.2022 21:44
                +2

                можно надеяться, что создатели той файловой системы не предусмотрели удаление вложенных файлов физически с диска и удаление записей о них

                если в системе SSD, почти наверняка ФС просто отправит trim и всё, после этого там может быть что угодно


            1. MaximRV
              02.12.2022 21:23
              +2

              Итак. Не даёт Папкой перезаписать файл при попытке переместить интерактивно. Т.е. Файл Папкой заменить удалось. А вот Папкой файл не удаётся. Изначально во всплывающем окне он предлагает сразу папку переименовать с постфиксом - текущей датой. Но после удаления постфикса. Записать таки не даёт. Не реагирует на нажатие кнопки записи. т.к. защита, по крайней мере в интерактивном режиме есть. По API я не пробовал. Пусть автор заметки пробует.\

              И пожалуйста, khajiit не считайте всех собеседников идиотами. Некоторые упомянутые вами книжки не только читали. Но и писали.
              Это я к вашему:
              "… если переименовать *.txt в *.mp3, то можно будет послушать, а если в *.avi — то даже и посмотреть! "
              Слишком толсто.

              А ведь исходя из Интерактивного! поведения Яндекс-диска - это даже не косяк. Это Залёт. Ибо Даже если подтвердив перезапись папки файлом можно потерять доступ к содержимому папки (я специально опустил формулировку "похерить файлы", ибо ещё неизвестно что с ними), то обратная операция, потенциально более безобидная, т.к. в результате её мы можем потерять данные лишь одного файла, который превращается в папку.

              Впрочем, замечу, что при перезаписи Папки файлом. Изображение всё же меняется после обновления страницы (я просто закрыл, и через некоторое время открыл заново яндекс-диск, Обновить страницу я не жал, но уверен что и простое обновление страницы тоже подгрузит уже изменённое изображение для этого файла/папки.


              1. khajiit
                02.12.2022 22:40

                Слишком толсто

                Это ирония и отсылка к одному вошедшему в баш случаю.
                Простите, если обидел.


                Некоторые упомянутые вами книжки не только читали. Но и писали.

                Тогда становится еще более загадочно, чем вы руководствовались, предлагая примерно такое же по толстоте осмысленности действие…
                Потому как если бы это могло сработать, то, во-первых, это был бы большой такой баг с восстановлением "удаленных" файлов, а во-вторых, правильная реализация потребовала бы огромного количества ресурсов, целенапраленно потраченых для именно такого поведения, в том числе проверки а не совпадет ли перемещенная папка с одной из ранее удаленных*, что само по себе иррационально.


                Но давайте таки не будем ссориться на ровном месте.
                Поведение, конечно, хоть ожидаемое, но потерпевшему легче от этого не становится.


  1. foya
    01.12.2022 11:57

    У меня уже два года тикет висит по поводу ошибки на яндекс услугах))) до сих пор исправить не могут, периодически пишут


  1. BeLord
    01.12.2022 11:57

    На мой взгляд, это такая прекрасная дыра в безопасности. В принципе, я бы апеллировал тех. поддержке, что проблема не только в том, что пользователь потерял свои файлы, а в том, что не исправление этого прекрасного механизма может привести к лавине не приятных последствий для сервиса, не буду описывать алгоритм он и так очевиден.


    1. kAIST
      01.12.2022 13:07
      +1

      На мой взгляд, это такая прекрасная дыра в безопасности.

      Дыра состоит в стандартном и очевидном поведении файловых систем? Если бы их скрипт бэкапил не под WebDav а на другой физический диск, то было бы абсолютно так же.

      не буду описывать алгоритм он и так очевиден.

      Мне не очевиден. Расскажите?


  1. slavius
    01.12.2022 12:13
    +1

    Т.е. я.диск предупреждает при перемещении файла о дубликате? И при подтверждении удаляет одноимённую папку?

    Или удаляет и при переименовании тоже?


    1. andetlt Автор
      01.12.2022 12:16

      При перемещении точно да. При переименовании (я тоже пробовал) я не понял. Один раз получилось, второй раз ругался, что такой файл уже существует и не дал переименовать.


      1. slavius
        01.12.2022 12:43

        Предупредили о совпадении имени, и при подтверждении проведения операции файл заместил папку?

        Или предупредили о совпадении имени, и при переименовании файла в процессе переноса в корень всё равно папка пропала?


        1. andetlt Автор
          01.12.2022 13:29


  1. KStrebkov
    01.12.2022 12:19

    Не понимаю что хочет автор, описывая данный кейс как проблему. У вас есть путь /123. По одному и тому же пути в операционных системах не может быть одновременно и папки /123 и файла /123. Вам выдается предупреждение что будет замена по этому пути папки на файл. После замены (еще раз повторюсь замены) автор почему то ожидает что останутся и папка и файл.


    1. andetlt Автор
      01.12.2022 12:23
      +6

      Автор за свои 40 годиков первый раз столкнулся с этим и хочет предупредить таких же неумёх. Оказывается даже Windows так не умеет делать. В предупреждении было написано, что такой файл существует без намёков на папку. Опять же это был эксперимент. По API, думаю, просто выполняется перемещение. А ожидаю я, что останутся файлы, потому что наверное физически они не перезаписались и не перетёрлись, и писал в поддержку именно с этой надеждой.


      1. toivo61
        01.12.2022 14:21
        +1

        Ну да, в RSX-11, такой проблемы не было, там уже было версионирование файлов.

        Да и в Вандрайве две корзины.


      1. Popadanec
        01.12.2022 15:32

        В окнах может быть сколько угодно файлов с одинаковым названием в одной папке/корне диска(естественно с учётом адресного пространства), главное чтобы расширение было разное.
        А яндекс похоже наличие расширения вообще никак не учитывает.


        1. YMA
          01.12.2022 16:05
          +1

          В плане файловой системы вполне учитывает:


        1. khajiit
          01.12.2022 19:55
          +3

          Расширение — это часть имени. Оно семантически в юзерспейсе выделяется, для удобства работы.


        1. vconst
          02.12.2022 09:35

          Тут кто-то еще, кроме автора текста, считает — что «папка, это название такого особого маленького жесткого диска», а не просто еще один файл, с особым атрибутом?


          1. nikolas78
            03.12.2022 00:27
            +1

            «Тут» может и нет, а «там» — 99.99% пользователей ЯД.


  1. crawlingroof
    01.12.2022 12:29
    +5

    Возможные грабли, это то что тебя забанят без объяснения причин и диск удалят. Благо что там ерунда хранилась, стучался в ТП - без результата


  1. h1pp0
    01.12.2022 14:30
    +2

    Не рекомендую использовать Яндекс.Диск для работы и/или через WebDAV. Несколько лет назад они практически отключили его для существующих клиентов искусственным ограничением скорости.


    1. Lebets_VI
      01.12.2022 22:12

      Я вот не знал об этом и сегодня, из-за этого, удалил подписку на 3Тб на яндексе, а думал приспособить их для бекапов :(


  1. remzalp
    01.12.2022 14:46

    А бэкапы принципиально решили не делать?


  1. dimirsen
    01.12.2022 15:11
    -3

    Уникальности много не бывает. Надо делать префикс в имени: file_ для файлов и folder_ для папок


  1. Iv38
    01.12.2022 16:17
    +4

    Ну, кстати… Тут многие ругают автора, что очевидное поведение ему неочевидно. Оказывается, мне тоже было неочевидно. Да, я знаю как работают файловые системы, и что папка тоже файл. Но я никогда даже не задумывался что произойдёт при совпадении имён файла и папки. А ведь получается, так можно похоронить всю иерархию директорий со всеми файлами. И это гораздо катастрофичнее может быть, чем случайная замена одного файла.
    Понятно, что ответ тут один — бэкапы. Мало ли что вообще может случиться с файловой системой.


    1. GennPen
      01.12.2022 17:12
      +6

      Но я никогда даже не задумывался что произойдёт при совпадении имён файла и папки. 

      Могу сказать больше, раньше (да и сейчас тоже) иногда проворачивали фокус чтобы автоматически не ставились левые программы: создаешь файл с именем каталога в место куда программа автоматически устанавливается.


      1. serge-sb
        02.12.2022 11:31

        Было такое давно на одной из первых работ. Собственно: на компьютерах пользователей был установлен клиент radmin'а, чтобы админы могли удалённо подключаться. Причём делать это они могли без уведомлений. Мне это не понравилось, поэтому удаляю radmin.exe... и нет, не даёт удалить. Далее стандартный виндовый способ: переименовываю этот файл и создаю папку с названием radmin.exe. Далее перезагрузка и никаких radmin'ов.


    1. vconst
      02.12.2022 09:37
      +1

      Понятно, что ответ тут один — бэкапы
      Ответ тут один — учить матчасть


      1. Iv38
        02.12.2022 17:28
        +4

        Мой опыт разработки показывает, что всю матчасть нельзя изучить, а кода без багов не бывает. Так что бэкапы.


        1. vconst
          03.12.2022 09:22

          Вроде как выяснили, что для такого копирования, начало принудительно включить флаг «перезаписать в любом случае, без вопросов». То есть человек должен был прочитать мануал на эту конкретную команду, чтобы скртпт не ругался, когда ему надо перезаписать директорию

          То есть, программист намеренно использовал что-то типа: «rm -rf», а потом удивляется «Как это так? Зачем директорию то удалять?». Потому что я не представляю, зачем специально ставить эту опцию и не понимаю — как ее можно поставить случайно.

          Хотя вариант есть. «Программист» копипастил код непойми откуда, не понимая что там и зачем


          1. rombell
            03.12.2022 16:17

            Выше же вроде пояснили, что такое поведение — по умолчанию, наоборот, что бы отключить, надо найти и поставить флаг.


    1. Didimus
      02.12.2022 11:31

      Главное, чтобы это в бэкапе тоже не случилось


  1. Quackerjack
    01.12.2022 17:17

    Лет 5 назад, кажется, можно было заварить отличную "кашу" из данных, если включить дедупликацию на машине с установленным Яндекс Диском. Данные были консистентными только на машине где была включена дедупликацию, а на других уже синхронизированная Яндексом каша =))


  1. Ilyayarovykh
    02.12.2022 14:03

    удивительно, что Яндекс. еще не ответил тут) Репостни на vc)) А лучше на Дзен)

    хотя по сути, вам все ответили - вы. правда считаете, что из вредности или пренебрежения к ламерам не хотят восстановить?)

    "Ваши папки удалены и если они удалены через WebDAV, то они не появляются в корзине. Их не вернуть. "


    1. GennPen
      02.12.2022 17:22

      удивительно, что Яндекс. еще не ответил тут) Репостни на vc)) А лучше на Дзен)

      А что он должен ответить? Что автор темы ССЗБ?


  1. kvazimoda24
    02.12.2022 23:21
    +1

    Тоже не понимаю, чего хочет автор. У него там какой-то скрипт с непонятным поведением. Этот скрипт мог и просто rm -rf / сделать.
    Дальше автор пошёл в ТП Яндекса просить, по сути, услугу бекапа данных, которую ему никто не обещал. Сам же никаких бекапов, судя по всему, не делал. Хотя, откуда такая вера в сохранность данных в Яндекс.Диске? Ну вот забанят они аккаунт, и всё, кранты. Данных нет.