HNKTO
Silver Member | Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору Камрады, выношу вопрос на публику. И потестить и ваши ИМХО по поводу мяса. http://sendfile.su/1393363 Суть: я тут из своих наработок собрал и думаю предложить Джамперу возможно лучший аналог CopyFileEx() для Кекса Что мы об этом знаем: В Винде CopyFileEx() dwCopyFlags: COPY_FILE_ALLOW_DECRYPTED_DESTINATION - хз что и как, но предположим оно там работает COPY_FILE_FAIL_IF_EXISTS - работает согласно инструкции COPY_FILE_RESTARTABLE - судя по всем признакам игнорируется, по крайней мере на XP+ COPY_FILE_OPEN_SOURCE_FOR_WRITE - задекларирован, но не документирован. Не исследовал Остальное пашет согласно инструкции В 9x, добавляется у M$ через MSLU, Кекс позволяет игнорировать MSLU и добавляет напрямую На практике работает так-же как CopyFile, т. е. никаких обратных функций, стоповых флагов, .... В Linux, работает так-же как в 9x с Кексом, т. е. перенаправление в CopyFile ============ Что предлагаю: dwCopyFlags: COPY_FILE_ALLOW_DECRYPTED_DESTINATION - игнорируется (а а что я в ответ на это на 9x должен делать?) COPY_FILE_OPEN_SOURCE_FOR_WRITE - игнорируется COPY_FILE_RESTARTABLE - функция пытается возобновить копирование, но при этом НЕ ПРОВЕРЯЕТ, является уже существующая часть частью копируемого файла (с точки зрения данных). Функция в ряде случаев функция может вообще отказываться копировать, но всё-равно завершается успехом (прикидываясь под винду) также имеет набор прочих флагов, см. CopyFileEx.cpp, тут стоит только выделить 0x8000, по идее нет смысла, но я наблюдал ошибки когда тут на тестировании пытался вызвать функцию с меньшим числом аргументов, загоняя в неё большее число. В обратной функции StreamSize, StreamBytesTransferred, dwStreamNumber, dwCallbackReason - не могу гарантировать, что работают идентично, но по краней мере повторил на что оно похоже при копировании локальных файлов tElaps - Это собственно ещё один хвост от CopyFileM. Именно его передача включается флагом 0x8000, также при этом упомянутые выше 4 аргумента начинают заполняться по упрощённой схеме, итого начинают отличаться от винды. А теперь о проблемах: Данная функция ощутимо медленней оригинала! Главная проблема: она никак не разбирает ситуацию копирования между двумя физическими носителями, итого значительно теряет в скорости копирования. В вопросах копирования в пределах одного носителя в общем случае соответствует быстродействию оригинала. Вторично: В отличие от оригинала никак не анализирует состояние дискового кэша, в результате все ситуации быстрого повторного копирования того-же файла в том-же направлении всегда выполняются с общей производительностью (итого значительно медленней возможного). На этом всё вроде. К тестилке: См copyfiles.exe в папке release (или перекомпилируем сами, если интересно/надо) Программа понимает 2 аргумента командной строки: от_куда_копируем Программа понимает 2 аргумента командной строки: "от куда копируем" "куда копируем" собственно заполнятся в два верхних эдит-бокса окна Нижние два эдита: левый: пусто или 0 - вызвать мою функцию, 1 - вызвать оригинальную виндовую функцию правый: число, комбинация флагов для поля dwCopyFlags. пусто - подразумевает 0. Тут стоит заметить что в коде зашито добавление 0x8000 при вызове моей функции. Ок запускает копирование, Cancel пытается остановить (если обратная функция вызывается) или выход из программы После операции программа отображает возврат функции и код GetLastError() и завершает свою работу Усё. Кто хочет помочь - смотрим, тестим, высказываем замечания и предложения. Sheleh, альтернативный шелл для 9х, Linux? Хорошим желом занимаешься! Успехов. |