Андрей Прошу прощения, что так долго добирался до этой задачи. Не очень понятно было как глубока эта кроличья нора, нужно было сначала добить другую очень сложную задачу, чтобы с чистым сознанием можно было взяться за эту.
Но вот теперь перечитывая анамнез заново, и вспоминая всю чертовщину, что творилась ранее с Диск.О, мне кажется самым разумным объяснением, что в Диск.О ошибка именно в функции переименования/переноса файлов. Это объясняет и те эффекты, которые вы ранее встречали, и как ни странно, и этот случай тоже.
На первый взгляд может показаться, причем тут Диск.О, теперь же файлы в Яндекс переносились, а с ним похожих проблем ранее не замечалось. И тогда можно прийти к ложному выводу, что единственный общий знаменатель между этими случаями - Tonfotos, а значит дело в нём.
Но это не совсем так. Я ранее уже не раз описывал механизм, которым работает программа в случае переноса файлов. Я его не сам придумал. Это стандартный механизм, который рекомендуется применять для переноса файлов. Если кратко, то смысл такой:
- Сначала пытаемся переименовать файл, указав в качестве нового имени новый путь к нему. Если оба пути внутри одной файловой системы, то файл просто перенесется из папки в папку, никакого фактического копирования не потребуется. Эта операция гораздо более защищенная от сбоев, чем копирование и удаление.
- Если эта операция не удалась, то создается новый файл по новому пути, туда копируется содержимое старого.
- После этого старый файл пытаемся перенести в корзину
- Если не получилось (не поддерживается корзина на этом диске, например), то просто удаляем.
В вашем случае логика чуть длиннее, так как при попытке перенести была ошибка что такой файл уже есть, и поэтому далее была попытка переименовать его уже в другое имя. В любом случае, логика тут железная, опробованная тысячами пользователей, и нигде еще, кроме Диск.О до этого сбоев не дававшая.
Так вот, как мне кажется, проблема в том, что Диск.О дает ответ на операцию переименования ДО ТОГО как её реально исполнит. Видимо, он сначала пытается отправить изменения в облако, а только потом фактически что-то сделать на диске.
Представьте, Tonfotos дает команду на переименование по новому пути, Диск.О перехватывает ее, видит, что место занято, дает ошибку. Tonfotos спрашивает у вас что делать. Пока всё ОК, из-за задержи на ожидание ввода пользователя. Далее Tonfotos делает еще несколько запросов на переименование но уже с новым именем, и на все тут же получает ОК. Программа после этого смотрит, что папка осталась пустой, и решает ее удалить тоже.
Гипотеза в том, что все эти изменения не применились сразу, а начали синхронизоваться с облаком. И где-то в логике Диск.О удаление папки ОПЕРЕДИЛО перенос файлов. Папка удалилась со всем файлами, при этом они уже каким-то чудом уже переименовались, но еще не улетели на новое место. Как-то так. Да, тут тоже есть масса вопросов, но это лучшее объяснение, что я могу пока придумать. Других идей у меня просто нет. В логике Tonfotos точно всё ОК.
