Здравствуйте, Аноним, Вы писали:
А>Здравствуйте, _FRED_, Вы писали:
_FR>>Здравствуйте, Аноним, Вы писали:
_FR>>А вы посмотрите на проблему по-другому: во-первых, медленнее работать не будет: в самом худшем случае (который, на современных-то винтах не наступит при нормально работающем оборудовании и драйверах) запросы на чтение\запись выстроятся в одну очередь и получится ровно то, что есть сейчас. А>как не посмотрю никак не откроется тот прекрасный вид, что написали
А>вот на выделенное хочу увидеть подтверждение, доказательство, что асинхронные запросы ны выполнение операций с диском (а запись — это достаточно сложная операция, которая не просто делегируется hdd. при записи обновляется куча доп инфы) не вытесняют друг-друг. да и вообще результаты тестов в студию
Выделенное, и то чему вы хотите получить доказательство — разные вещи. "Запросы выстроятся в очередь" — это одно утверждение, а "не вытесняют друг-друга" — совершенно другое. Да и никто не утверждал что не вытесняют. Наоборот, выстраивание в очередь — это как раз вытеснение.
Результаты тестов это подтверждают. Время асинхронного копирования не больше чем у синхронного.
Здравствуйте, Аноним, Вы писали:
_FR>>А вы посмотрите на проблему по-другому: во-первых, медленнее работать не будет: в самом худшем случае (который, на современных-то винтах не наступит при нормально работающем оборудовании и драйверах) запросы на чтение\запись выстроятся в одну очередь и получится ровно то, что есть сейчас. Но, во-вторых, когда пользователь прикупит себе SSD, вот там, как на хорошей трассе, разница между спортивной машиной и драндулетом даст знать
А>как не посмотрю никак не откроется тот прекрасный вид, что написали
А>вот на выделенное хочу увидеть подтверждение, доказательство, что асинхронные запросы ны выполнение операций с диском (а запись — это достаточно сложная операция, которая не просто делегируется hdd. при записи обновляется куча доп инфы) не вытесняют друг-друг. да и вообще результаты тестов в студию
И какого рода доказательств вы ждёте? Сами не знаете или каких-то конкретных? Или тесты и будут доказательством? А если у кого-то другого, на другом железе, будут другие результаты, то это будет опровержением моих доказательств или нет?
Что мешает вам самому (а доказательства нужны именно вам — мне-то они ни к чему) собрать два примера кода (оба в данном топике приведены) и потестить на имеющемся у вас оборудовании и привести тут? В назидание, так сказать, тем, кто не поверит мне?
Я считаю, что тот, кто хочет написать производительную операцию, сам не поленится потестировать. Пищи для размышлений было дано предостаточно.
Help will always be given at Hogwarts to those who ask for it.
S>Выделенное, и то чему вы хотите получить доказательство — разные вещи. "Запросы выстроятся в очередь" — это одно утверждение, а "не вытесняют друг-друга" — совершенно другое. Да и никто не утверждал что не вытесняют. Наоборот, выстраивание в очередь — это как раз вытеснение.
Запросы выстроятся в очередь в ядре. Ядро обрабатывает запросы асинхронно всегда, причем запросы, поступившие от разных процессов. Ядро вообще не знает, синхронный это или асинхронный запрос — будет оно такими пустяками заниматься!
А вот приложение 3 кольца может при этом либо тупо ждать, пока запрос не будет выполнен (синхронный в/в), либо заняться чем-то иным, пока запрос выполняется (асинхронный).
Иными словами
синхронный запрос :
ReadFile(асинхронно)
и немедленно WaitFor чтение выполнено
асинхронный запрос :
ReadFile(асинхронно)
делаем что-то иное, пока в ядре читаем. Буфер не трогаем!
WaitFor чтение выполнено
S>Результаты тестов это подтверждают. Время асинхронного копирования не больше чем у синхронного.
Совершенно верно. Вот время загрузки процессора потоком, который все это инициировал, может быть увеличено, так как он не будет ждать, а загрузит процессор, выполняя иную работу.
Здравствуйте, Dan123, Вы писали:
D>Здравствуйте! D>Нужно копировать файл с отображением хода копирования, например в прогрессбаре. D>CopyFileEx мне не подходит.
1. Насколько я понял из доки, есть ограничения ее использования в некоторых версиях Windows.
2. Пока с ней разбирался нарвался на такую вещь. Если конечного файла не существует, то все проходит нормально.
А если файл существует, то иногда копирование проходит нормально, а иногда нет. Можно конечно в этом случае предварительно
файл удалить. Но п.1 меня не устраивает.
Здравствуйте, Dan123, Вы писали:
D>1. Насколько я понял из доки, есть ограничения ее использования в некоторых версиях Windows.
В Windows95 и ее точно нет, но там и дотнета нет.
В windows98,ME,NT4 ее вроде как нет, но это так важно ? В NT4 вроде как дотнет тоже не работает, так ?
Requires Windows Vista, Windows XP, or Windows 2000 Professional.
D>2. Пока с ней разбирался нарвался на такую вещь. Если конечного файла не существует, то все проходит нормально. D>А если файл существует, то иногда копирование проходит нормально, а иногда нет.
Когда копирование не проходит нормально, надо GetLastError вызывать и выяснять, что там ненормально. Ненормально может быть при использовании любых средств, это штатная ситуация. У тебя скорее всего нет прав на удаление файла, или же он кем-то занят. Ошибку в этих случаях ты получишь при любом способе копирования.
_FR>Я считаю, что тот, кто хочет написать производительную операцию, сам не поленится потестировать. Пищи для размышлений было дано предостаточно.
Я протестировал оба варианта.
Сначала в своем примере перед копированием побайтно я добавил строку outputFile.SetLength(inputFile.Length);
После этого скорость копирования в моем случае увеличилась на 20 секунд и сравнялась со скоростью копирования в Total Commander.
Затем я воспроизвел этот пример асинхронного копирования.
Скорость копирования в обоих примерах оказалась абсолютно одинаковой. В обоих примерах использовал одинаковый размер буфера, исходный и конечный
файл располагаются на одном диске.
Во втором тесте конечный файл расположил на USB флэшке. И в этом случае асинхронный вариант скопировал файл на флэшку на 50 секунд быстрее.
PD>Когда копирование не проходит нормально, надо GetLastError вызывать и выяснять, что там ненормально. Ненормально может быть при использовании любых средств, это штатная ситуация. У тебя скорее всего нет прав на удаление файла, или же он кем-то занят. Ошибку в этих случаях ты получишь при любом способе копирования.
В моем примере я сделал по нажатию кнопки копирование друг за другом трех файлов. Запускаю приложение, нажимаю кнопку "Копировать" — все нормально. Получаю три копии файла. Жму кнопу еще раз 5-10 — все три файла копируются заново без проблем. Затем, например, на 11- попытке один из файлов копироваться перестает. Удаляю этот конечный файл из проводника (апликуху при этом не выгружаю). Нажимаю кнопку и все опять начинает работать до какой-то n-й попытки. Затем прочитал про ограничения и меня это совсем как-то охладило. GetLastError не стал анализировать после этого. Юникодовая версия у меня вообще как-то сходу не заработала. А насколько я понял, в ANSI версии возникнут проблемы с названиями файлов. Решил поискать другие варианты.
В описании функции есть вот это:
Windows 2000: Когда CopyFileEx используется для копирования зашифрованного файла, функция пытается зашифровать выходной файл с ключом по умолчанию. Не пытайтесь сделать так, чтобы зашифровать выходной файл с ключом, использованным при кодировании исходного файла. Если файл не может быть зашифрован, CopyFileEx заканчивает операцию копирования, не зашифровав выходной файл.
Просветите по поводу зашифрованных файлов. Если я попытаюсь побайтно скопировать зашифрованный файл, я тоже нарвусь на проблемы?
Re[7]: Копирование файла
От:
Аноним
Дата:
07.10.10 16:54
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:
S>>Результаты тестов это подтверждают. Время асинхронного копирования не больше чем у синхронного.
PD>Совершенно верно. Вот время загрузки процессора потоком, который все это инициировал, может быть увеличено, так как он не будет ждать, а загрузит процессор, выполняя иную работу.
один хрен самый быстрый способ копирования, это последовательное чтение в оооочень большой буфер (сотни мегов), а затем последовательная запись. Если на разных физических устройствах — то параллельная.
PD>>Когда копирование не проходит нормально, надо GetLastError вызывать и выяснять, что там ненормально. Ненормально может быть при использовании любых средств, это штатная ситуация. У тебя скорее всего нет прав на удаление файла, или же он кем-то занят. Ошибку в этих случаях ты получишь при любом способе копирования.
D>В моем примере я сделал по нажатию кнопки копирование друг за другом трех файлов. Запускаю приложение, нажимаю кнопку "Копировать" — все нормально. Получаю три копии файла. Жму кнопу еще раз 5-10 — все три файла копируются заново без проблем. Затем, например, на 11- попытке один из файлов копироваться перестает.
Вот здесь и надо GetLastError смотреть. Это же очень просто. Проблема может быть совсем не тут, надо поэтому знать, что происходит.
> Удаляю этот конечный файл из проводника (апликуху при этом не выгружаю). Нажимаю кнопку и все опять начинает работать до какой-то n-й попытки. Затем прочитал про ограничения и меня это совсем как-то охладило.
Что именно ?
>GetLastError не стал анализировать после этого. Юникодовая версия у меня вообще как-то сходу не заработала.
Так разбираться надо.
D>В описании функции есть вот это: D>Windows 2000: Когда CopyFileEx используется для копирования зашифрованного файла, функция пытается зашифровать выходной файл с ключом по умолчанию. Не пытайтесь сделать так, чтобы зашифровать выходной файл с ключом, использованным при кодировании исходного файла. Если файл не может быть зашифрован, CopyFileEx заканчивает операцию копирования, не зашифровав выходной файл.
D>Просветите по поводу зашифрованных файлов. Если я попытаюсь побайтно скопировать зашифрованный файл, я тоже нарвусь на проблемы?
Шифрование прозрачно, про ключ надо помнить, но явно он нигде не участвует. Проблем быть не должно. Но об особенности для W2000 не в курсе. А переводчика надо уволить.
Windows 2000: When encrypted files are copied using CopyFileEx, the function attempts to encrypt the destination file with the default keys. No attempt is made to encrypt the destination file with the keys used in the encryption of the source file. If it cannot be encrypted, CopyFileEx completes the copy operation without encrypting the destination file.
No attempt is made означает "не пытается" (функция), а вовсе не совет тебе что-то там не пытаться.
Вообще читай лучше оригинальную докуметацию на английском, меньше проблем будет.
Здравствуйте, Аноним, Вы писали:
А>Здравствуйте, Pavel Dvorkin, Вы писали:
S>>>Результаты тестов это подтверждают. Время асинхронного копирования не больше чем у синхронного.
PD>>Совершенно верно. Вот время загрузки процессора потоком, который все это инициировал, может быть увеличено, так как он не будет ждать, а загрузит процессор, выполняя иную работу.
А>один хрен самый быстрый способ копирования, это последовательное чтение в оооочень большой буфер (сотни мегов), а затем последовательная запись. Если на разных физических устройствах — то параллельная.
Я вроде как о другом совсем говорил... Выделил сейчас.
GetLastError возвращает 5. Я так понял, это означает "Доступ запрещен".
Обнаружил, что после n-го копирования конечный файл имеет атрибут "Только для чтения". Хотя у исходного такого атрибута нет.
Почему это происходит я пока не понял. Вообще я так понимаю, что перед началом копирования если файл существует, то лучше его сперва удалить?
Или лучше проанализировать и изменить его атрибуты?
Еще вопрос. Чтобы не возникло проблем с названиями файла лучше использовать юникодовую версию?
В юникодовой версии GetLastError возвращает 2. Пока не нашел значения этой ошибки. Завтра продолжу разбираться.
Здравствуйте, Dan123, Вы писали:
D>GetLastError возвращает 5. Я так понял, это означает "Доступ запрещен". D>Обнаружил, что после n-го копирования конечный файл имеет атрибут "Только для чтения". Хотя у исходного такого атрибута нет.
Аттрибуты файла к этой ошибке отношения не имеют. Это ошибка от системы безопасности, она означает, что у вызывающего функцию юзера нет необходимых прав на доступ к данному файлу. Это может означать как фактическое отсутствие таких прав в дескрипторе защиты файла (если ошибка возвращена при попытке открыть или создать файл), так и то, что при открытии файла необходимые для работы данной функции права не были запрошены (если ошибка — результат вызова функций типа ReadFile, WriteFile etc).
D>В юникодовой версии GetLastError возвращает 2. Пока не нашел значения этой ошибки. Завтра продолжу разбираться.
2 означает, что функция не может найти файл, имя которого Вы ей передали. Либо ошибка в имени, либо такого пути/файла действительно нет.
Здравствуйте, Dan123, Вы писали:
D>GetLastError возвращает 5. Я так понял, это означает "Доступ запрещен". D>Обнаружил, что после n-го копирования конечный файл имеет атрибут "Только для чтения". Хотя у исходного такого атрибута нет. D>Почему это происходит я пока не понял. Вообще я так понимаю, что перед началом копирования если файл существует, то лучше его сперва удалить? D>Или лучше проанализировать и изменить его атрибуты?
D>Еще вопрос. Чтобы не возникло проблем с названиями файла лучше использовать юникодовую версию?
D>В юникодовой версии GetLastError возвращает 2. Пока не нашел значения этой ошибки.
D>Вопрос в другом, могу ли я при таком подходе наступить на какие-нибудь непредвиденные грабли?
Ты забыл, что функции типа CopyFileEx() не просто копируют содержимое файлов, но также и альтернативные потоки данных, дескрипторы безопасности, атрибуты шифрования и прочее и прочее. Я тебе советую посмотреть исходник функции CopyFileEx(), ужаснуться нескольким страницам непонятного кода и запомнить раз и навсегда, что такие вещи нельзя делать вручную, сам замучаешься.
D>Нужно ли при таком подходе после процесса копирования еще раз открыть файлы и сравнить их побайтно, чтобы убедиться в том, что файлы идентичны?
Не нужно, но можно. Если пользователь согласен тратить своё время на твою параноидальность.
D>Единственное, хотелось бы, чтобы скорость копирования была побыстрее, но изменение размера буфера на скорость копирования особо не сказалось.
Как уже сказали, размер буфера очень маленький у тебя. Я бы посоветовал выставлять от 64 КБ вплоть до нескольких МБ. Кстати, Total Commander, например, если правильно помню, использует именно 64 КБ буфера.
D>...есть ограничения ее использования в некоторых версиях Windows.
Давай конкретно, о каких именно ограничениях речь?
Здравствуйте, x64, Вы писали:
x64>Я тебе советую посмотреть исходник функции CopyFileEx(), ужаснуться нескольким страницам непонятного кода и запомнить раз и навсегда, что такие вещи нельзя делать вручную, сам замучаешься.
Здравствуйте, Dan123, Вы писали:
D>Скорость копирования в обоих примерах оказалась абсолютно одинаковой. В обоих примерах использовал одинаковый размер буфера, исходный и конечный D>файл располагаются на одном диске.
Каковы размеры буфера и файла?
Help will always be given at Hogwarts to those who ask for it.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Здравствуйте, samius, Вы писали:
S>>Выделенное, и то чему вы хотите получить доказательство — разные вещи. "Запросы выстроятся в очередь" — это одно утверждение, а "не вытесняют друг-друга" — совершенно другое. Да и никто не утверждал что не вытесняют. Наоборот, выстраивание в очередь — это как раз вытеснение.
PD>Запросы выстроятся в очередь в ядре. Ядро обрабатывает запросы асинхронно всегда, причем запросы, поступившие от разных процессов. Ядро вообще не знает, синхронный это или асинхронный запрос — будет оно такими пустяками заниматься! PD>А вот приложение 3 кольца может при этом либо тупо ждать, пока запрос не будет выполнен (синхронный в/в), либо заняться чем-то иным, пока запрос выполняется (асинхронный).
Я лишь хотел сказать что тупо ждать завершения двух запросов ничуть не хуже чем ждать завершения одного чтобы отправить второй.
Сами не знаете или каких-то конкретных? Или тесты и будут доказательством? А если у кого-то другого, на другом железе, будут другие результаты, то это будет опровержением моих доказательств или нет? 
"Нормальные герои всегда идут в обход!"
