Невозможно создать файл с ошибкой 183, так как он уже существует

Обновлено: 03.07.2024

Я копирую музыку с одного компьютера на другой. Для каждого альбома я получаю сообщение об ошибке 183 (невозможно создать файл, если этот файл уже существует) в файле folder.jpg. Нет ничего конкретного, что я делаю, чтобы создать эту ошибку (есть ли?); Кажется, что-то в способе копирования создает эту ошибку каждый раз. Как этого избежать?

Есть возможность игнорировать, но написано "игнорировать будущие ошибки" - я не знаю, означает ли это, что будут игнорироваться ВСЕ ошибки или только будущие версии 183 (расплывчатая формулировка). Но даже в этом случае в файле folder.jpg есть обложка альбома, поэтому я бы предпочел, чтобы он отражал ее так, как должен.

Я видел еще 183 треда, на которые не было ответа; не уверен, почему это так, но это не очевидная вещь, поэтому я надеюсь, что у кого-то есть совет.

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

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

Правильно ли сообщение об ошибке, другими словами: файл в каталоге RecycleBin.ffs_tmp уже существует на момент отображения сообщения?

Кстати, какую версию FreeFileSync вы используете?

Хорошо, это странно. Прошлой ночью при зеркалировании у меня было три альбома и три жалобы на «folder.jpg». Этим утром я повторил зеркалирование, чтобы получить сообщение об ошибке, и, что удивительно, у него было больше материала для копирования. Ничего не изменилось со вчерашнего вечера — если было что копировать, почему не сделали этого прошлой ночью? Кроме того, вместо трех жалоб было две. Так что я сделал зеркалирование еще раз, сразу же, и он смог обработать последние два файла без каких-либо жалоб. (Первый запуск FFS, который я когда-либо делал, закончился без ошибок. Всегда что-то было.)

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

Я понятия не имею, существует ли этот каталог. Я, конечно, не создавал его, и нет причин для его существования до запуска FFS. «.ffs_tmp» в названии заставляет меня предположить, что это временный каталог, который FFS создает сама. Когда я смотрю вокруг, я не вижу такого каталога.

Кстати, я видел в некоторых других темах, когда гуглил об этом (темы, которые не были о FFS), что «перемещение» автоматически создает каталог назначения, и если вы сначала «создаете» каталог, а затем «перемещаете», Windows выдает эту ошибку. Я не знаю, выполняет ли FFS в этом случае создание, а затем перемещение. (Я не специалист по Windows. Также не объясняет, почему только эти файлы.)

Кроме того, последнее уточнение: в моем втором посте, где я думал, что скопировал файлы вручную, я определенно этого не делал. Я не знаю, что там происходит, но не обращайте на это внимания.

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

Хорошо, это расстраивает. Наконец-то у меня появилось время заняться тщательной документацией. и ошибка исчезла. Как шум в машине, которого не бывает в мастерской. Только ты не выдумываешь.

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

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

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

<р>1. Как на исходном, так и на целевом компьютере параметры папки были настроены на отображение типов файлов и скрытых файлов. Я сделал это для того, чтобы иметь возможность делать подробные и недвусмысленные снимки экрана содержимого папок на разных этапах операции. Я предполагаю, что это влияет только на то, как папка просматривается, и не повлияет на FFS.

<р>2. Мне пришлось изменить разрешение на целевом компьютере, чтобы я мог сохранить снимок экрана с исходного компьютера на целевом компьютере через домашнюю группу. Но это разрешение затрагивало папку в библиотеке документов; музыка находится в музыкальной библиотеке, и никакие разрешения там не менялись. Итак, опять же, кажется, что это не должно иметь значения.

<р>3. Обычно я нажимаю «Синхронизировать», и сначала выполняется сравнение, а затем я нажимаю «ОК», чтобы начать процесс зеркалирования. В этом случае я не нажимал OK, потому что сначала хотел сделать снимок экрана с состоянием папок, когда FFS просматривал их перед зеркалированием. Затем я вернулся и завершил синхронизацию. Похоже, это тоже не имеет значения, но я сделал это не так, как раньше.

После этого я могу повторить попытку копирования (F5), и все работает.

Проводник Windows работает нормально.

Текст был успешно обновлен, но возникли следующие ошибки:

комментарий hardhub от 22 марта 2021 г.

Pxx64 прокомментировал 22 марта 2021 г.

комментарий hardhub от 24 марта 2021 г.

Найтли также затронут.

Все делать с помощью дальнего менеджера.

Pxx64 прокомментировал 25 марта 2021 г.

К сожалению, у меня не воспроизводится. Какую версию Samba вы используете? У меня сейчас 4.13.1
Как настроен общий ресурс, есть ли нестандартные ACL?

Pxx64 прокомментировал 25 марта 2021 г.

Кстати, вы пробовали с чистым профилем? Просто каждую ночь распаковать в отдельную папку, переименовать Far.exe.example.ini в Far.exe.ini, открыть, раскомментировать и установить
UseSystemProfiles=0
сохранить, а затем запустить Far из этой папки< /p>

Pxx64 прокомментировал 25 марта 2021 г.

@alabuzhev Я предполагаю, что дамп памяти в момент появления ошибки будет бесполезен для отладки, перед этим нужно захватить стеки с помощью ttd или wpr/xperf?

прокомментировал алабужев 25 марта 2021 г.

@Pxx64, мы пытаемся сначала вызвать CreateDirectoryEx (чтобы унаследовать как можно больше данных из исходного каталога), а если это не удается, мы возвращаемся к CreateDirectory.

Предположительно, CreateDirectoryEx не является транзакционной операцией внутри samba: сначала создает, потом пытается установить какие-то атрибуты и терпит неудачу, не очищая после себя и оставляя каталог там как есть, в полусозданное государство. Последующий вызов CreateDirectory завершится ошибкой, поскольку он уже существует. Мы могли бы, вероятно, обойти это, но сначала кто-то должен подтвердить - все это чистая спекуляция.

прокомментировал алабужев 25 марта 2021 г.

Дамп действительно бесполезен.

прокомментировал алабужев 25 марта 2021 г.

Пожалуйста, запустите это - gh-368.zip, например. test.exe C:\some_folder \\server\share\some_folder и покажите результат.

комментарий hardhub от 25 марта 2021 г.

Samba 4.12.12 (fc32, последняя версия стабильной версии)

комментарий hardhub от 25 марта 2021 г.

Пожалуйста, запустите это - gh-368.zip, например. test.exe C:\some_folder \\server\share\some_folder и покажите результат.

183: ERROR_ALREADY_EXISTS (невозможно создать файл, если этот файл уже существует).

И каталог создается Win32 API. Это ошибка в API? Самба?
Это не похоже на ошибку в Far Manager, учитывая все вышеперечисленное.

Я думаю, обходной путь прост, вы можете сделать проверку, подобную этой, GetFileAttributes(dst) перед второй попыткой создать каталог.

прокомментировал алабужев 25 марта 2021 г.

Это подтверждает предположение выше. 🤦‍♂️

И каталог создается Win32 API. Это ошибка в API? Самба?

Самба, конечно. Win32 просто перенаправляет команду базовым драйверам, сетевым протоколам и т. д.
Похоже на классическое "давайте реализуем 53 % каждой спецификации, а затем надеемся, что ни одно приложение не попытается сделать определенные вещи определенным образом" .

комментарий hardhub от 26 марта 2021 г.

На первый взгляд все работает нормально!

комментарий hardhub от 26 марта 2021 г.

Некоторые мысли. Я использовал robocopy и установил несколько других менеджеров, таких как Double Commander.

Эта проблема не затрагивает Проводник Windows, Robocopy, Drag&Drop в FileZilla, Double Commander.

Хотя в Win7 только Far и Robocopy используют SMB2 FSCTL_SRV_COPYCHUNK.

прокомментировал битрейд 26 марта 2021 г.

Некоторые мысли. Я использовал robocopy и установил несколько других менеджеров, таких как Double Commander.

Эта проблема не затрагивает Проводник Windows, Robocopy, Drag&Drop в FileZilla, Double Commander.

Хотя в Win7 только Far и Robocopy используют SMB2 FSCTL_SRV_COPYCHUNK.

С другой стороны, я много лет ежедневно писал в общие ресурсы samba с помощью Far на серверах ArchLinux и Alpine и не помню, чтобы когда-либо сталкивался с этой проблемой.

комментарий hardhub от 26 марта 2021 г.

Некоторые мысли. Я использовал robocopy и установил некоторые другие менеджеры, такие как Double Commander.
Проводник Windows, Robocopy, Drag&Drop в FileZilla, Double Commander не затронуты этой проблемой.
Хотя в Win7 только Far и Robocopy используют SMB2 FSCTL_SRV_COPYCHUNK.

С другой стороны, я много лет ежедневно писал в общие ресурсы samba с помощью Far на серверах ArchLinux и Alpine и не помню, чтобы когда-либо сталкивался с этой проблемой.

Чтобы воспроизвести проблему, необходимо выполнить точные действия. Каталог, который вы хотите скопировать в самбу, должен исходить из той же самой самбы. Например, копирование из samba в samba также завершается ошибкой, если оно выполняется с помощью Far в Windows.

Может быть, я могу попробовать разные живые дистрибутивы и смонтировать разделы вручную, чтобы наконец найти причину.
Но я боюсь, что мы потратим много времени на попытки его найти.
Я попробую, но обходной путь для Far работает нормально ))

Почему я получаю сообщение об ошибке, если мой скрипт создает папку? Я использую Python в Windows 7. Ошибка:

FileExistsError: [WinError 183] Невозможно создать файл, если этот файл уже существует: [путь к рассматриваемому файлу или папке]

Проблема в том, что файла и папки там не было.


По-видимому, файл или каталог с таким именем уже существует. Что еще можно сказать об этом?

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

@ErykSun проблема в том, что папки и файла там не было. но не интересно, уже) я решил. Спасибо)

3 ответа 3

Я только что столкнулся с такой же проблемой. Эта ветка помогла мне решить проблему, но кому-то может помочь следующее уточнение:

Для меня недоразумение возникло из-за Shutil.copytree(источник, пункт назначения, символические ссылки, игнорировать) .

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

Надеюсь, это кому-нибудь поможет.


Как указано в комментариях, папка уже существует. Вы, кажется, думаете, что попытки создать уже существующую папку просто ничего не дадут. Но Windows видит это не так.

Чтобы избежать сообщения об ошибке, сначала проверьте, существует ли папка. Перед кодом, создающим папку, выполните


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

Два способа создать папку с разным содержимым, но с тем же именем: (1) Удалите всю папку вместе с ее содержимым с помощью Shutil.rmtree(), а затем создайте новую папку, которую вы хотите. (2) Удалите исходное содержимое папки и поместите файлы в (теперь пустую) исходную папку.

Я только что столкнулся с немного более тонкой версией этого, это может помочь кому-то еще.

Я создавал папку с:
os.makedirs(os.path.dirname(my_filename), exists_ok=True)

Что должно создать папку, но не ошибку, если она уже существует. Я бы запускал это много раз без проблем.

Запустил еще раз и получил ошибку:

В конце концов выяснилось, что я сохранил выходную папку из предыдущего запуска для сравнения, переименовав ее во что-то другое.
Что не должно было вызвать проблемы, но один из файлов из этой папки все еще был открыт в Блокноте. Итак, поскольку ссылка на папку все еще была активной, ОС выдавала ошибку.

После этого я могу повторить попытку копирования (F5), и все работает.

Проводник Windows работает нормально.

Текст был успешно обновлен, но возникли следующие ошибки:

комментарий hardhub от 22 марта 2021 г.

Pxx64 прокомментировал 22 марта 2021 г.

комментарий hardhub от 24 марта 2021 г.

Найтли также затронут.

Все делать с помощью дальнего менеджера.

Pxx64 прокомментировал 25 марта 2021 г.

К сожалению, у меня не воспроизводится. Какую версию Samba вы используете? У меня сейчас 4.13.1
Как настроен общий ресурс, есть ли нестандартные ACL?

Pxx64 прокомментировал 25 марта 2021 г.

Кстати, вы пробовали с чистым профилем? Просто каждую ночь распаковать в отдельную папку, переименовать Far.exe.example.ini в Far.exe.ini, открыть, раскомментировать и установить
UseSystemProfiles=0
сохранить, а затем запустить Far из этой папки< /p>

Pxx64 прокомментировал 25 марта 2021 г.

@alabuzhev Я предполагаю, что дамп памяти в момент появления ошибки будет бесполезен для отладки, перед этим нужно захватить стеки с помощью ttd или wpr/xperf?

прокомментировал алабужев 25 марта 2021 г.

@Pxx64, мы пытаемся сначала вызвать CreateDirectoryEx (чтобы унаследовать как можно больше данных из исходного каталога), а если это не удается, мы возвращаемся к CreateDirectory.

Предположительно, CreateDirectoryEx не является транзакционной операцией внутри samba: сначала создает, потом пытается установить какие-то атрибуты и терпит неудачу, не очищая после себя и оставляя каталог там как есть, в полусозданное государство. Последующий вызов CreateDirectory завершится ошибкой, поскольку он уже существует. Мы могли бы, вероятно, обойти это, но сначала кто-то должен подтвердить - все это чистая спекуляция.

прокомментировал алабужев 25 марта 2021 г.

Дамп действительно бесполезен.

прокомментировал алабужев 25 марта 2021 г.

Пожалуйста, запустите это - gh-368.zip, например. test.exe C:\some_folder \\server\share\some_folder и покажите результат.

комментарий hardhub от 25 марта 2021 г.

Samba 4.12.12 (fc32, последняя версия стабильной версии)

комментарий hardhub от 25 марта 2021 г.

Пожалуйста, запустите это - gh-368.zip, например. test.exe C:\some_folder \\server\share\some_folder и покажите результат.

183: ERROR_ALREADY_EXISTS (невозможно создать файл, если этот файл уже существует).

И каталог создается Win32 API. Это ошибка в API? Самба?
Это не похоже на ошибку в Far Manager, учитывая все вышеперечисленное.

Я думаю, обходной путь прост, вы можете сделать проверку, подобную этой, GetFileAttributes(dst) перед второй попыткой создать каталог.

прокомментировал алабужев 25 марта 2021 г.

Это подтверждает предположение выше. 🤦‍♂️

И каталог создается Win32 API. Это ошибка в API? Самба?

Самба, конечно. Win32 просто перенаправляет команду базовым драйверам, сетевым протоколам и т. д.
Похоже на классическое "давайте реализуем 53 % каждой спецификации, а затем надеемся, что ни одно приложение не попытается сделать определенные вещи определенным образом" .

комментарий hardhub от 26 марта 2021 г.

На первый взгляд все работает нормально!

комментарий hardhub от 26 марта 2021 г.

Некоторые мысли. Я использовал robocopy и установил несколько других менеджеров, таких как Double Commander.

Эта проблема не затрагивает Проводник Windows, Robocopy, Drag&Drop в FileZilla, Double Commander.

Хотя в Win7 только Far и Robocopy используют SMB2 FSCTL_SRV_COPYCHUNK.

прокомментировал битрейд 26 марта 2021 г.

Некоторые мысли. Я использовал robocopy и установил несколько других менеджеров, таких как Double Commander.

Эта проблема не затрагивает Проводник Windows, Robocopy, Drag&Drop в FileZilla, Double Commander.

Хотя в Win7 только Far и Robocopy используют SMB2 FSCTL_SRV_COPYCHUNK.

С другой стороны, я много лет ежедневно писал в общие ресурсы samba с помощью Far на серверах ArchLinux и Alpine и не помню, чтобы когда-либо сталкивался с этой проблемой.

комментарий hardhub от 26 марта 2021 г.

Некоторые мысли. Я использовал robocopy и установил некоторые другие менеджеры, такие как Double Commander.
Проводник Windows, Robocopy, Drag&Drop в FileZilla, Double Commander не затронуты этой проблемой.
Хотя в Win7 только Far и Robocopy используют SMB2 FSCTL_SRV_COPYCHUNK.

С другой стороны, я много лет ежедневно писал в общие ресурсы samba с помощью Far на серверах ArchLinux и Alpine и не помню, чтобы когда-либо сталкивался с этой проблемой.

Чтобы воспроизвести проблему, необходимо выполнить точные действия. Каталог, который вы хотите скопировать в самбу, должен исходить из той же самой самбы. Например, копирование из samba в samba также завершается ошибкой, если оно выполняется с помощью Far в Windows.

Может быть, я могу попробовать разные живые дистрибутивы и смонтировать разделы вручную, чтобы наконец найти причину.
Но я боюсь, что мы потратим много времени на попытки его найти.
Я попробую, но обходной путь для Far работает нормально ))

Читайте также: