Конфликт mingw с дропбоксом

Я столкнулся с проблемой MinGW64 (gcc 4.6.3, from RTools build on CRAN), которая возникает при работе с папкой Dropbox. У меня есть большой проект, который я создаю с помощью файла make. Он отлично компилирует все исходные файлы, но когда я начинаю добавлять все файлы *.o в библиотеку, я получаю странное сообщение:

C:\Rtools\gcc-4.6.3\binar.exe: невозможно переименовать «project.lib»; Причина: Файл существует.

Выполняемые команды:

ar rcs project.lib  func1.o
ar rcs project.lib  func2.o
ar rcs project.lib  func3.o
...
ar rcs project.lib  func120.o

Существует более 100 файлов *.o. Первоначальные работают, но после случайного количества из них появляется вышеуказанное сообщение об ошибке. Иногда на второй команде ar, иногда на сотой.

Этот make-файл годами работал под Win32, Win64, linux 32, linux 64 и OSX. И это работает на этом компьютере с Win64, когда я копирую папку в место, отличное от Dropbox. Я предполагаю, что существует некоторый конфликт, когда ar пытается повторно обновить файл библиотеки, а Dropbox пытается повторно скопировать файл в облако.

Кто-нибудь еще видел это? Или знаете, как работает Dropbox, и можете объяснить, что происходит?


person John Nolan    schedule 24.04.2015    source источник


Ответы (1)


Не уверен, что это проблема, связанная с Windows, но, вероятно, так и есть. Windows по умолчанию блокирует открытые файлы, и эти блокировки предотвращают правильное удаление/замену файлов. Dropbox любит открывать файлы в своей папке (чтобы проверить/загрузить их).

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

person David Macek    schedule 25.04.2015
comment
Спасибо - это то, что я подозревал. Я просто удивлен, что никто больше, кажется, не упомянул об этом. - person John Nolan; 29.04.2015