Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 177
Пауза при копировании понравилась.
Copy-Paste Manager
(пародия на знаменитую качалку файлов)
(пародия на знаменитую качалку файлов)
Ещё бы приоритеты копирования (для больших файлов). Было бы удобно.
Все проблемы при работе с файлами в винде, давно решаются установкой Total Commander. Ну или Far — кому что больше нравится.
это понятно, но много ли пользователей ставят себе TC или FAR?
Total Commander + F5->F2 (в очередь)
у CopyMik есть задание приоритета при копировании (ключ /PRIORITY ...)
Она была в операционной системе BeOS. Десять лет назад. Безумно удобная фишка
btw, по ссылке (в начале этой статьи) есть видео с демонстрацией этих нововведений
Ну наконец-то сделали то, что уже очень давно напрашивалось. Объединение нескольких процессов копирования в одно окно. Еще бы сделали общую очередь копирования, в которую можно было бы файлы добавлять. А то несколько независимых процессов копирования в параллель все таки не всегда удобно.
Это было настолько очевидное улучшение (по крайней мере пауза — это точно), что нужно было еще реализовать в Windows XP SP3. Можно было это сделать и в Висте и в 7-ке.
Но, сдается, выдумывать новые фишки становится всё сложнее. Поэтому приберегли эту фишку на потом. Не удивлюсь, если это всерьез будет преподносится как конкурентное преимущество новой ОС.
Но, сдается, выдумывать новые фишки становится всё сложнее. Поэтому приберегли эту фишку на потом. Не удивлюсь, если это всерьез будет преподносится как конкурентное преимущество новой ОС.
Надо в проводник добавить две панели и поддержку плагинов от TC. Это будет пушка!
Поддержка двух панелей по сути реализована при помощи Aero Snap.
По-моему выглядит плохо, из-за кучи разных рамок.
Я бы лучше хотел в проводнике вид колонками как в файндере
Я бы лучше хотел в проводнике вид колонками как в файндере
Если у вас два монитора, то не очень удобно использовать Aero Snap.
В той же убунте (точнее, Наутилусе) двух-панельный режим при отображении списком выглядит и работает гораздо ближе к стилю фара/тотала.
Win -> / <-
> интерфейс копирования файлов
Интерфейс чего? o_O Файлы должны просто копироваться, нет?
В тексте ошибка:
Интерфейс чего? o_O Файлы должны просто копироваться, нет?
В тексте ошибка:
Продвинутые менеджеры для массового копирования файлов установлены менее чем на 0,45% всех компьютеров с Windows 7, так что доработка интерфейса встроенного файл-менеджера является весьма НЕвостребованной для большинства юзеров.Большинство не устанавливает эти менеджеры, значит это невостребованная функция.
Большинство просто не знают о такой возможности.
О возможности устанавливать программы? Если бы им понадобилась такая функциональность, нужные программы они бы нашли.
хм, большинство скорее не копирует туда-сюда терабайты файлов каждый день, поэтому сторонняя утилита, немного оптимизирующая процесс, им не нужна.
Большинству пользователей психологически комфортнее использовать «родную», предустановленную программу для таких низкоуровневых целей.
Сколько раз ни ставил тотал или far — так и не смог привыкнуть. Так и тянуло на эксплорер кликнуть.
Сколько раз ни ставил тотал или far — так и не смог привыкнуть. Так и тянуло на эксплорер кликнуть.
Большинство не знают о такой возможности и не устанавливают эти менеджеры, поэтому это востребованная фича? Или что вы имели ввиду?
Это значит ребята их майкрасофта признают наличие проблемы у этой довольно нужной штуки, и, так как большая часть пользователей просто не знают о сторонних решениях позволяющих исправить недочеты стандартной утилиты, решили исправить ее. Таким образом хорошо будет всем… (за исключением консерваторов)
> продвинутые менеджеры для массового копирования файлов (TeraCopy, FastCopy и Copy Handler) установлены менее чем на 0,45% всех компьютеров с Windows 7, так что доработка интерфейса встроенного файл-менеджера является весьма востребованной
както не логично звучит.
както не логично звучит.
Похожий принцип уже давненько используется в Наутилусе.
Вот бы еще табы добавили.
Вот бы еще табы добавили.
Похожий принцип уже давненько используется в Наутилусе.
И с незапамятных времен — в макоси:
И почему я не удивлена?
Давно уже Гномик равняется на Макось.
Давно уже Гномик равняется на Макось.
А паузы-то нету :)
[holywar mode]А в кедах есть %)[/holywar mode]
Есть, конечно. И уже давно, и графики есть, и уже даже неблокирующий диалог для обработки кофликтов есть.
И две панели нормальные.
> Похожий принцип уже давненько используется в Наутилусе.
Вот только нет очереди и кнопки «Пауза».
> Вот бы еще табы добавили.
В какое место в окне «File operations» вы хотите табов?
Вот только нет очереди и кнопки «Пауза».
> Вот бы еще табы добавили.
В какое место в окне «File operations» вы хотите табов?
А кнопка паузы есть?)
А диалог обработки коллизий похож на KDE-шный.
не хватает паузы
простите, что-то не заметил ветки с кучей таких же комментов. Торопыжка.
Gentoo, KDE 4.6.5, предпочитаю англоязычный интерфейс
Кому интересно, еще одна инновация Windows 8:
Совсем недавно в кде ещё появился неблокирующий диалог для обработки разных ошибок копирования: en.munknex.net/2011/08/gsoc-results-interaction-dialog.html
Теперь можно не волноваться, что огромная загрузка прервётся из-за того, что у одного файла были неподходящие права доступа или что-то в этом духе. :)
Теперь можно не волноваться, что огромная загрузка прервётся из-за того, что у одного файла были неподходящие права доступа или что-то в этом духе. :)
Да, это классная фича. Видимо можно ожидать в 4.8, вместе со вторым, существенно ускоренным анимированным дельфином.
Паузы в Наутилусе вроде как нет. Да и про оптимизацию под разные размеры файлов в нем я ничего не слышал.
«оптимизацию под разные размеры файлов в нем»
Она не в нем, она должна быть в подсистемах ядра, в драйвере файловой системы. Как бы файлами управлять это ее задача, а наутилус всего лишь интерфейс.
Она не в нем, она должна быть в подсистемах ядра, в драйвере файловой системы. Как бы файлами управлять это ее задача, а наутилус всего лишь интерфейс.
Насколько я знаю, в windows система копирует неоптимально и файловый менеджер Total Commander реализует оптимальную схему вместо этих самых систем. Почему это не могут сделать в линупсе? И, кстати, отсутствие нормального мощного двухпанельника в линукс до сих пор не позволяет мне комфортно работать с файлами в линукс. Или может быть они есть, но где-то прячутся?
Я не вкурсе, что там делает Total Commander, и как это делает windows, однако файловый менеджер по определению не обладает той информацией, которой обладает ядро, он даже не может знать, где физически находятся данные, в каком месте диска, или вообще в кэше
В линуксе все отлично работает. Про двухпанельних не скажу, ибо imho это более менее удобно только в консоли, а в консоли есть замечательный mc.
В линуксе все отлично работает. Про двухпанельних не скажу, ибо imho это более менее удобно только в консоли, а в консоли есть замечательный mc.
А табы в наутилусе давно есть, тыкните колесиком по папке.
WindowTabs поможет, если заплатить :)
О, не ужели в гноме это сделали раньше чем в винде?! Не знал не знал…
> при копировании фотографий, если уже есть файл с тем же названием, окно предварительного просмотра показывает уменьшенные копии файлов и спрашивает, действительно ли нужно заменить имеющиеся файлы
При этом копирование остальных файлов продолжается или опять все встает колом и отойдя от компа во время процесса копирования возвращаешься к тому же проценту, что и перед уходом, только-лишь из-за коллизии какого-то файла?
При этом копирование остальных файлов продолжается или опять все встает колом и отойдя от компа во время процесса копирования возвращаешься к тому же проценту, что и перед уходом, только-лишь из-за коллизии какого-то файла?
Научится ли диалог замены файлов не задавать вопросов, если файлы абсолютно идентичны? Или хотя бы самостоятельно сравнивать и помечать их?
Это будет бомба.
А если файлы по 600 мб или больше, вы готовы ждать лишние пару минут на выполнение diff?
А если файлы по 600 мб, то в подавляющем большинстве случаев различия будут найдены уже на первом килобайте.
Вот как-то не могу представить, чтобы часто попадались файлы, содержщие абсолютно одинаковое количество байт и различающиеся только где-нибудь в хвосте.
Вот как-то не могу представить, чтобы часто попадались файлы, содержщие абсолютно одинаковое количество байт и различающиеся только где-нибудь в хвосте.
Достаточно посчитать хэш. Хотя это, несомненно, тоже занимает время.
Ролик на ту же тему youtu.be/RilLowVIBG0
Радует, что MS стала обращать внимание на интерфейс, упрощая некоторые операции.
«Умное копирование», если правильно понял, будет реализовано по типу KDE 4.x?
Если так, то будем посмотреть, штука удобная.
«Умное копирование», если правильно понял, будет реализовано по типу KDE 4.x?
Если так, то будем посмотреть, штука удобная.
В Windows 8 этот диалог стал более понятным.
Мне он показался более сложным.
Это точно. А что если файлов тыща?
Если копировать много файлов, выделив их один раз и нажав копировать/вставить, то для них всех отобразится одна полоска (один поток).
Чтобы их стало тысяча, нужно тысячу раз нажать копировать/вставить. По-моему, такое мало вероятно :)
Чтобы их стало тысяча, нужно тысячу раз нажать копировать/вставить. По-моему, такое мало вероятно :)
Да, полоска одна (прогрессбар), а вот в окошке, где надо галочками отмечать файлы, будет безумие)
Сложным показался диалог замены файлов с одинаковыми названиями.
Более того:
— говорит о том, что стало хуже.
Более того:
- Маленькие галочки, вместо больших кнопок для выбора.
- Убрали возможность «Переместить, но сохранить оба файла» и «Сделать это для всех конфликтов».
— говорит о том, что стало хуже.
Можно тыкнуть просто по изображению, галочки просто для того, чтобы показать что тыкать можно. попадать в них не надо
2. Если вы поставите галочки на оба файла, то оба и сохранятся — аналог «Переместить, но сохранить оба файла». У заголовков в таблице есть галочки, которые позволяют выделить сразу все файлы из исходного или конечного расположения — аналог «Сделать это для всех конфликтов».
«Check boxes are necessary. As much as we preferred the cleaner no-checkbox look, it simply didn’t test well. Users didn’t know what to do when presented with the UI. Check boxes were much more effective in providing appropriate cues for selection. We made sure to retain a large click-target area, so users can click on the check box, thumbnail, or the text to select a file»
Уж пускай будут банальные чекбоксы. Всё же лучше, чем огромные кнопки, потому что нестандартно. Особенно убивают кнопки при открытии панели принтера в «Принтерах и факсах», которые и на наведение реагируют, но при этом одним щелчком вдавливаются, а щёлкаются только двойным. Это вообще что? Кнопка — вроде нет… И вообще, с какой целью оно там, я до сих пор не проникся.
Интересно, как будет выглядеть последнее окошко при копировании (с заменой) пары сотен файлов.
Главное чтобы при копировании все остальные программы не начинали тормозить как сейчас
О, ну неужели, наконец-то додумались пауза сделать, не прошло и 20 лет)
«Данные телеметрии Microsoft показывают, что продвинутые менеджеры для массового копирования файлов (TeraCopy, FastCopy и Copy Handler) установлены менее чем на 0,45% всех компьютеров с Windows 7, у остальных пользователей такой функции нет, они просто не знают о подобных программах, поэтому доработка встроенного интерфейса Windows будет весьма кстати.»
Интересно, что это за данные такие, и учитывали ли они Total Commander, FAR Manager и прочие продвинутые аналоги. Что-то мне подсказывает, что большинство недовольных проводником поставили именно их, а не какие-то костыли к проводнику.
«Касательно прогноза времени копирования в Windows Explorer — разработчики знают о существующих шутках на этот счёт и обещают исправить этот недостаток, насколько это возможно. Но они говорят, что идеально точно прогнозировать время невозможно, потому что на него влияет слишком много непредсказуемых факторов.»
И опять же, почему-то в вышеперечисленных мной продуктах такие проблемы изначально меньше.
Интересно, что это за данные такие, и учитывали ли они Total Commander, FAR Manager и прочие продвинутые аналоги. Что-то мне подсказывает, что большинство недовольных проводником поставили именно их, а не какие-то костыли к проводнику.
«Касательно прогноза времени копирования в Windows Explorer — разработчики знают о существующих шутках на этот счёт и обещают исправить этот недостаток, насколько это возможно. Но они говорят, что идеально точно прогнозировать время невозможно, потому что на него влияет слишком много непредсказуемых факторов.»
И опять же, почему-то в вышеперечисленных мной продуктах такие проблемы изначально меньше.
И опять же, почему-то в вышеперечисленных мной продуктах такие проблемы изначально меньше.
перевод в этом топике очень условный, читайте лучше оригинал.
Там сказано
Estimating the time remaining to complete a copy is nearly impossible to do with any precision because there are many unpredictable and uncontrollable variables involved – for instance, how much network bandwidth will be available for the length of the copy job? Will your anti-virus software spin up and start scanning files? Will another application need to access the hard drive? Will the user start another copy job?
Как, например, вышеперечисленные вами продукты будут решать эти проблемы?
Я вообще сижу уже два года с погашенным explorer.exe, ггг.
В 21-м веке Microsoft наконец-то реализует паузу для процесса копирования. Это прорыв, я считаю.
А вот у убунте нет до сих пор :(
Я не понимаю вашей иронии. Что же, не реализовывать её вообще, раз так. «Ну всё, опоздали»?
Ирония в том, что это можно было сделать и раньше.
Ирония в том, Microsoft считает это своей эксклюзивной инновационной мегафичей, не имеющий аналогов.
Покажите где вы в тексте это увидели?
В тексте это нет. Это ИМХО. А так вещь полезная. Жалко, что этот функционал дошел до Windows только сейчас — пользователи XP и Windows 7 (а их большинство будет еще ого-го как долго) не оценят этого.
То есть вы сейчас за Микрософт решили, что Микрософт считает эту штуку эксклюзивной инновационной мегафичей, не имеющий аналогов и немедленно высмеяли это?
лучше бы последующие файлы для копирования на тот же диск ставились в очередь, а не копировались параллельно, фрагментируя диск и замедляя скорость записи
ну хоть кнопку паузы сделали, уже хорошо
ну хоть кнопку паузы сделали, уже хорошо
Вот сколько живу и до сих пор фигею от тупости разработчиков, отвечающие за копирование файлов — такое ощущение, что они сами по жизни, когда что-то собираются копировать — им дают по рукам или за них это делают другие. ну всё же просто как два пальца и можно було сделать это еще во времена Win95:
1) сделать как показано (как в кедах) одно окно для всех копирований (слава Алл… Яй… не знаю кому) — до этого додумались наконец в Мелкомяшких
2) сделать позможность поставить на паузу (до этого гномодевелоперы до сих пор не доперли!)
3) добавить например изменение последовательснти (перетаскивать в этом единственном окне вверх/вниз) операций копирования
4) система (в отличии от большинства пользователей) _знает_ как разбиты (и разбиты ли вообще) диска на резделы, то есть:
а) копирование с одного физического диска на другой — гоним на полных скоростях в параллель (одновременно читаем и на другой пишем) — причем как только самой системе вдруг понадобилось срочно что-то там прочесть/записать (например участвует диск С:), то приостановить на пару секунд копирование, чтобы млин не убивать диск 20 позиционированиями в секунду! — так же намного быстрее разрулится ситуёвина
б) разделы на одном диске — значит создаем буфер (например равный скорости чтения диска или в разы больше) и сначала копируем, потом пишем — а не дергаме бедный диск ради каждого файла!!! (такое решение применено в плагине в Far)
в) выводить НАМНОГО больше информации о копировании (текущая + средняя скорость, сколько скопировано, сколько осталось, учитывать при копировани не только объем, но и количество файлов!)
г) я может что-то не понимаю, но почему нельзя научиться писать 1000 файлов па 1 Кб с такой же скоростью, как и 1 файл размером 1 Мб ?? (почему нельзя сначала записать содержание этой 1000 файлов за один «полуоборот» диска, и только потом одним махом занести в FAT их заголовки и т.п.?)
5) ну и как уже говорилось — не _останавливать_ процесс копирование, если возникли вопросы!!!
1) сделать как показано (как в кедах) одно окно для всех копирований (слава Алл… Яй… не знаю кому) — до этого додумались наконец в Мелкомяшких
2) сделать позможность поставить на паузу (до этого гномодевелоперы до сих пор не доперли!)
3) добавить например изменение последовательснти (перетаскивать в этом единственном окне вверх/вниз) операций копирования
4) система (в отличии от большинства пользователей) _знает_ как разбиты (и разбиты ли вообще) диска на резделы, то есть:
а) копирование с одного физического диска на другой — гоним на полных скоростях в параллель (одновременно читаем и на другой пишем) — причем как только самой системе вдруг понадобилось срочно что-то там прочесть/записать (например участвует диск С:), то приостановить на пару секунд копирование, чтобы млин не убивать диск 20 позиционированиями в секунду! — так же намного быстрее разрулится ситуёвина
б) разделы на одном диске — значит создаем буфер (например равный скорости чтения диска или в разы больше) и сначала копируем, потом пишем — а не дергаме бедный диск ради каждого файла!!! (такое решение применено в плагине в Far)
в) выводить НАМНОГО больше информации о копировании (текущая + средняя скорость, сколько скопировано, сколько осталось, учитывать при копировани не только объем, но и количество файлов!)
г) я может что-то не понимаю, но почему нельзя научиться писать 1000 файлов па 1 Кб с такой же скоростью, как и 1 файл размером 1 Мб ?? (почему нельзя сначала записать содержание этой 1000 файлов за один «полуоборот» диска, и только потом одним махом занести в FAT их заголовки и т.п.?)
5) ну и как уже говорилось — не _останавливать_ процесс копирование, если возникли вопросы!!!
Пункт (г) как правило упирается в производительность файловой подсистемы и I/O. Можете поэкспериментировать в никсах с утилитой dd. К примеру:
dd if=video1.iso of=tmp bs=1 count=1048576
1048576+0 записей считано
1048576+0 записей написано
скопировано 1048576 байт (1,0 MB), 2,27584 c, 461 kB/c
$dd if=video1.iso of=tmp bs=1048576 count=1
1+0 записей считано
1+0 записей написано
скопировано 1048576 байт (1,0 MB), 0,0118877 c, 88,2 MB/c
Поясню: в первом случае делается миллион чтений блоков размером в 1 байт (и столько же записей). Во втором случае — чтение одного блока размером в мегабайт. Если кто-то подумает, что скорость быстрее из за буфера — файл был предварительно прочитан и уже лежал в дисковом кеше (хотя и без этого первый прогон не сильно отличался — 457 Кб/с).
В случае именно вашего вопроса — тысяча ваша файлов совсем не обязательно лежит последовательно в одном месте диска, чтобы моментом считать их в буфер. Их надо найти в ФС, назначить операции чтения, определить место назначения (особенно это актуально если диск почти заполнен и приходится раскладывать файлы частями).
dd if=video1.iso of=tmp bs=1 count=1048576
1048576+0 записей считано
1048576+0 записей написано
скопировано 1048576 байт (1,0 MB), 2,27584 c, 461 kB/c
$dd if=video1.iso of=tmp bs=1048576 count=1
1+0 записей считано
1+0 записей написано
скопировано 1048576 байт (1,0 MB), 0,0118877 c, 88,2 MB/c
Поясню: в первом случае делается миллион чтений блоков размером в 1 байт (и столько же записей). Во втором случае — чтение одного блока размером в мегабайт. Если кто-то подумает, что скорость быстрее из за буфера — файл был предварительно прочитан и уже лежал в дисковом кеше (хотя и без этого первый прогон не сильно отличался — 457 Кб/с).
В случае именно вашего вопроса — тысяча ваша файлов совсем не обязательно лежит последовательно в одном месте диска, чтобы моментом считать их в буфер. Их надо найти в ФС, назначить операции чтения, определить место назначения (особенно это актуально если диск почти заполнен и приходится раскладывать файлы частями).
А занести заголовки потом — там возникает много проблем с блокировкой и конкуррентным доступом. Процесс копирования — не единственный в системе. Частично в ext4 эта проблема решается введением экстентов.
2) У гнома идеология другая, их концепция чем меньше элементов управления — тем лучше. Простому, не искушенному пользователю, незачем ставить копирование на паузу. А именно на таких гномовцы и рассчитывают.
3) А тут даже я не понимаю, зачем их последовательность изменять, если они параллельно все выполняются.
a) Для этого и существует шедуллер и приоритеты процессов, вполне работает механизм, по крайней мере в *nix;
б) Потом, в случае сбоя, будете рассказывать пользователю куда его гигабайты понухи пропали;
г) Устройство современных файловых систем заметно сложнее, чем вы его себе представляете;
5) В KDE уже сделали. =)
3) А тут даже я не понимаю, зачем их последовательность изменять, если они параллельно все выполняются.
a) Для этого и существует шедуллер и приоритеты процессов, вполне работает механизм, по крайней мере в *nix;
б) Потом, в случае сбоя, будете рассказывать пользователю куда его гигабайты понухи пропали;
г) Устройство современных файловых систем заметно сложнее, чем вы его себе представляете;
5) В KDE уже сделали. =)
б) какая связь между размером буфера и пропажей данных?
Действительно, никакой. Переглючило меня.
Но и смысла никакого в реальности нет, а скорее даже вред. Поскольку, если планироващик ввода-вывода достаточно умен, то он будет минимизировать перемещение головки, если рядом с данными, которые надо считать, есть область куда можно записать. Таким образом чередуя чтение и запись.
Большой буфер же, который предполагается обрабатывать в режиме заполнил до конца, затем опсутошил до конца — только помешает его работе. В этом случае, ему сначала придется попрыгать по областям, чтобы считать данные, заполнив буффер, а затем поелозить головкой в поисках свободных областей для записи этого буфера.
Частые перемещения головки диска же происходят не от того, что мы читаем и пишем, а в основном от того, что данные раскиданы по диску, свободные области также раскиданы по диску.
В конце концов, управлять обращениями к диску и сортировать их наиболее оптимальным образом должен планировщик потока ввода-вывода, а не файловый менеджер (последний чаще всего и не подозревает о физическом расположении данных на диске). Кроме того разные алгоритмы работы планироващика лучше справляются с разными задачами, и при этом копировать данные из одной области диска в другую — вряд ли самая частая задача, под которую стоит его оптимизировать.
Но и смысла никакого в реальности нет, а скорее даже вред. Поскольку, если планироващик ввода-вывода достаточно умен, то он будет минимизировать перемещение головки, если рядом с данными, которые надо считать, есть область куда можно записать. Таким образом чередуя чтение и запись.
Большой буфер же, который предполагается обрабатывать в режиме заполнил до конца, затем опсутошил до конца — только помешает его работе. В этом случае, ему сначала придется попрыгать по областям, чтобы считать данные, заполнив буффер, а затем поелозить головкой в поисках свободных областей для записи этого буфера.
Частые перемещения головки диска же происходят не от того, что мы читаем и пишем, а в основном от того, что данные раскиданы по диску, свободные области также раскиданы по диску.
В конце концов, управлять обращениями к диску и сортировать их наиболее оптимальным образом должен планировщик потока ввода-вывода, а не файловый менеджер (последний чаще всего и не подозревает о физическом расположении данных на диске). Кроме того разные алгоритмы работы планироващика лучше справляются с разными задачами, и при этом копировать данные из одной области диска в другую — вряд ли самая частая задача, под которую стоит его оптимизировать.
Вот плохо читаете — пункт б) — это случай, когда в копировании участвуют два _разных_ раздела одного диска. В случае копирования внутри одного раздела — да, пусть там всё само разруливается и оптимизируется, как Вы написали.
>В этом случае, ему сначала придется попрыгать по областям, чтобы считать данные, заполнив >буффер, а затем поелозить головкой в поисках свободных областей для записи этого буфера.
Но ведь головка та, вместо того, чтобы носиться по _всему диску_ на всём протяжении копирования, будет сначала носиться по одному разделу, потом по второму — чувствуете разницу?
>а не файловый менеджер (последний чаще всего и не подозревает о физическом расположении >данных на диске)
Вот как раз это узнать элементарно: сравните sda1 > sda2 и sda1 > sdb1 — сразу же видно!
ЗЫ кстати в винде тоже испольуются такие же пути монтирования — что-то типа multi(0)disk(0)rdisk(0)partition(1)
>В этом случае, ему сначала придется попрыгать по областям, чтобы считать данные, заполнив >буффер, а затем поелозить головкой в поисках свободных областей для записи этого буфера.
Но ведь головка та, вместо того, чтобы носиться по _всему диску_ на всём протяжении копирования, будет сначала носиться по одному разделу, потом по второму — чувствуете разницу?
>а не файловый менеджер (последний чаще всего и не подозревает о физическом расположении >данных на диске)
Вот как раз это узнать элементарно: сравните sda1 > sda2 и sda1 > sdb1 — сразу же видно!
ЗЫ кстати в винде тоже испольуются такие же пути монтирования — что-то типа multi(0)disk(0)rdisk(0)partition(1)
«сначала носиться по одному разделу, потом по второму — чувствуете разницу?»
Верно только если у вас разделы не LVM. Но тут еще возникает вопрос, а зачем вы разбивали жесткий диск на множество разделов, да еще примерно одинакового назначения?
Я если и делю диск, то на разделы принципально разного назначения, и таких ситуаций, как приведенная вами, просто не возникает. Вы сами ее искусственно создали. Я учитываю специфику взаимодействия с каждым разделом, при принятии решения, как разбить диск, собственно ради этого только и имеет смысл его разбивать.
Перемещать данные с одного раздела на другой в пределах одного жесткого диска, или писать большой объем данных в два раздела сразу на одном диске — это очень редкие уникальные ситуации, которые вот я даже припомнить не могу, когда у меня такое случалось.
При этом вы хотите, чтобы файловый менеджер еще проверял содержаться ли эти два пункта назначения на одном диске и на разных разделах. А файловый менеджер такой информации просто не имеет, ОС абстрагирует его от всяких sda/sdb и т. д. Проверял, является ли блочное устройство флешкой, SSD или разделом жесткого диска в не LVM (или подобной) схеме разбивки.
Я думаю ради обработки такого редкого случая, размер кода, который необходимо добавить и поддерживать — если и не соизмерим со всем, уже написанным кодом, то составляет весьма существенный объем.
Верно только если у вас разделы не LVM. Но тут еще возникает вопрос, а зачем вы разбивали жесткий диск на множество разделов, да еще примерно одинакового назначения?
Я если и делю диск, то на разделы принципально разного назначения, и таких ситуаций, как приведенная вами, просто не возникает. Вы сами ее искусственно создали. Я учитываю специфику взаимодействия с каждым разделом, при принятии решения, как разбить диск, собственно ради этого только и имеет смысл его разбивать.
Перемещать данные с одного раздела на другой в пределах одного жесткого диска, или писать большой объем данных в два раздела сразу на одном диске — это очень редкие уникальные ситуации, которые вот я даже припомнить не могу, когда у меня такое случалось.
При этом вы хотите, чтобы файловый менеджер еще проверял содержаться ли эти два пункта назначения на одном диске и на разных разделах. А файловый менеджер такой информации просто не имеет, ОС абстрагирует его от всяких sda/sdb и т. д. Проверял, является ли блочное устройство флешкой, SSD или разделом жесткого диска в не LVM (или подобной) схеме разбивки.
Я думаю ради обработки такого редкого случая, размер кода, который необходимо добавить и поддерживать — если и не соизмерим со всем, уже написанным кодом, то составляет весьма существенный объем.
3) это вот для такого случая:
Вам нужно записать на один диск (например купили свежий полуторатеррабайтник) и сливаете на него с двух старых (музыка и фильмы например) — заранее задали операции для копирования и ушли ужинать. Чтобы не издеваться над диском и не фрагментировать его (сразу же после покупки!) Вы эти операции проделаете _последовательно_. Так и система, видя, что вы задали ей такие задания, будет их выполнять _последовательно_ а не одновоременно — вот для этого Вам и нужно изменение последовательности действия — например Вам срочно вдруг присписело сначало слить фотки на новый винт.
Вам нужно записать на один диск (например купили свежий полуторатеррабайтник) и сливаете на него с двух старых (музыка и фильмы например) — заранее задали операции для копирования и ушли ужинать. Чтобы не издеваться над диском и не фрагментировать его (сразу же после покупки!) Вы эти операции проделаете _последовательно_. Так и система, видя, что вы задали ей такие задания, будет их выполнять _последовательно_ а не одновоременно — вот для этого Вам и нужно изменение последовательности действия — например Вам срочно вдруг присписело сначало слить фотки на новый винт.
Я не вижу причин для фрагментирования и никакого издевательства. Аллокатор современной файловой системы вполне разумен, чтобы зарезервировать для одного файла свободную область, при ее наличии, и уложить его туда целиком.
Да в случае если у вас не SSD диск и если вы копируете одновременно два очень больших файла, скорее всего записывая их параллельно получите больше перемещений головки диска. Но зачем вы так делаете? Зачем в этом случае вы запустили две параллельные операции? Выделите все вместе и тогда будет запущен один процесс, и в нем все будет копироваться последовательно.
Тот функционал, который вы назвали, нужен в 1% всех случаев для каких-то особо требовательных безнадежных перфекционистов, которые при этом пользуются HDD и что-то знают про такие недоступные для обычного пользователя вещи, как устройство жесткого диска.
Эти люди вполне могут поставить некую альтернативную программу, аля Супер_Перемещатель_Файлов_ProEdition. У всех остальных же, подобный функционал вызовет только лишние вопросы и головную боль.
«например Вам срочно вдруг присписело сначало слить фотки на новый винт.»
Вы ставите на паузу уже запущенный процесс копирования большого длинного файла на этот новый винт, если таковой запущен (в случае копирования небольших файлов ситуация с частым дерганьем головки диска не актуальна). Выделяете все новые фотки, которые решили скопировать, и переносите на новый винт. Да, будет одно маленькое неудобство, когда фотки будут скопированны, вам придется самостоятельно снять с паузы остановленный процесс.
Да в случае если у вас не SSD диск и если вы копируете одновременно два очень больших файла, скорее всего записывая их параллельно получите больше перемещений головки диска. Но зачем вы так делаете? Зачем в этом случае вы запустили две параллельные операции? Выделите все вместе и тогда будет запущен один процесс, и в нем все будет копироваться последовательно.
Тот функционал, который вы назвали, нужен в 1% всех случаев для каких-то особо требовательных безнадежных перфекционистов, которые при этом пользуются HDD и что-то знают про такие недоступные для обычного пользователя вещи, как устройство жесткого диска.
Эти люди вполне могут поставить некую альтернативную программу, аля Супер_Перемещатель_Файлов_ProEdition. У всех остальных же, подобный функционал вызовет только лишние вопросы и головную боль.
«например Вам срочно вдруг присписело сначало слить фотки на новый винт.»
Вы ставите на паузу уже запущенный процесс копирования большого длинного файла на этот новый винт, если таковой запущен (в случае копирования небольших файлов ситуация с частым дерганьем головки диска не актуальна). Выделяете все новые фотки, которые решили скопировать, и переносите на новый винт. Да, будет одно маленькое неудобство, когда фотки будут скопированны, вам придется самостоятельно снять с паузы остановленный процесс.
>Аллокатор современной файловой системы вполне разумен
примеры ОСей в студию
>Да в случае если у вас не SSD диск и если вы копируете одновременно два очень больших файла, >скорее всего записывая их параллельно получите больше перемещений головки диска
Так я и хочу поставить копироваться несколько потоков и спокойно пойти кушать не парясь фрагментацией (мне как раз и не нужно знать фрагментируется оно при этом или нет — сама ось должна как раз взять на себя последовательность копирования, а не я этим париться)
>Выделите все вместе и тогда будет запущен один процесс, и в нем все будет копироваться >последовательно.
КАК??? я же копирую с _разных_ дисков на новый!
примеры ОСей в студию
>Да в случае если у вас не SSD диск и если вы копируете одновременно два очень больших файла, >скорее всего записывая их параллельно получите больше перемещений головки диска
Так я и хочу поставить копироваться несколько потоков и спокойно пойти кушать не парясь фрагментацией (мне как раз и не нужно знать фрагментируется оно при этом или нет — сама ось должна как раз взять на себя последовательность копирования, а не я этим париться)
>Выделите все вместе и тогда будет запущен один процесс, и в нем все будет копироваться >последовательно.
КАК??? я же копирую с _разных_ дисков на новый!
>Аллокатор современной файловой системы вполне разумен
примеры ОСей в студию
www.tldp.org/LDP/sag/html/filesystems.html#FRAGMENTATION
В устройстве файловых систем microsoft я не разбираюсь, поэтому не вкурсе что там творится.
КАК??? я же копирую с _разных_ дисков на новый!
Мой Dolphin кажется не умеет выделять несколько объектов за пределами одного уровня иерархии и это да, проблема. Я бы тогда просто воспользовался командой
примеры ОСей в студию
www.tldp.org/LDP/sag/html/filesystems.html#FRAGMENTATION
В устройстве файловых систем microsoft я не разбираюсь, поэтому не вкурсе что там творится.
КАК??? я же копирую с _разных_ дисков на новый!
Мой Dolphin кажется не умеет выделять несколько объектов за пределами одного уровня иерархии и это да, проблема. Я бы тогда просто воспользовался командой
cp. Но скорее всего, я бы просто не парился.
5) Это вам к ТС надо :) Там можно заранее задать ответы на вопросы :)
Видимо хотят не усложнять, боятся, что пользователи будут тупить.
Видимо хотят не усложнять, боятся, что пользователи будут тупить.
Кстати!!!
А вы знаете, KillCopy _единственная_ программа для винды, которая при копировани/переносе/переименовании СОХРАНЯЕТ дату и время создания и изменения файлов? (да, есть еще какой-то плагин для Total Commander, но я так и не понял как его настроить, ибо дата изменения таки меняется)
PS сам пользуюсь ей уже кучу лет и все ставлю
А вы знаете, KillCopy _единственная_ программа для винды, которая при копировани/переносе/переименовании СОХРАНЯЕТ дату и время создания и изменения файлов? (да, есть еще какой-то плагин для Total Commander, но я так и не понял как его настроить, ибо дата изменения таки меняется)
PS сам пользуюсь ей уже кучу лет и все ставлю
Robocopy
входит в дистрибутив начиная с 6.0
входит в дистрибутив начиная с 6.0
TeraCopy — вторая единственная программа для винды, которая также сохраняет обе даты неизменными. Да и интерфейс у неё нативный, без идиотических «шкурок».
Открыл проводник, выбрал файл (созданный 22 апреля с.г. с одинаковыми датами в «создан» «изменён» и «открыт»), нажал ctrl+c, ctrl+v. Рядом появился файл у которого дата изменения также 22 апреля, а дата создания — сегодняшняя. Что весьма логично, т.к. эта КОПИЯ файла была СОЗДАНА сегодня.
А если мне надо слить 100500 файлов на флэшку/скопироват на сервак/слить коллеге в его документы/сделать копию и прочее — у _всех_ файлов будет дата создание — на момент копирования, и хрен потом через год-другой найдешь документы, например созданные в преддверии какого-нить срочного совещания и валяющиеся абы где в папках/рабочих столах пользователей.
Скопировал 3 файла, даты ИЗМЕНЕНИЯ остались те же:
>>, например созданные в преддверии какого-нить срочного совещания
По дате изменения и найдёшь. Один хрен, файл может быть создан 01 января, но нужна будет та копия в которую последние ИЗМЕНЕНИЯ внесли 26 августа.
>>валяющиеся абы где в папках/рабочих столах пользователей.
Помоему вы с больной головы на здоровую перекладываете. Не храните ВАЖНЫЕ документы абы как.
>>, например созданные в преддверии какого-нить срочного совещания
По дате изменения и найдёшь. Один хрен, файл может быть создан 01 января, но нужна будет та копия в которую последние ИЗМЕНЕНИЯ внесли 26 августа.
>>валяющиеся абы где в папках/рабочих столах пользователей.
Помоему вы с больной головы на здоровую перекладываете. Не храните ВАЖНЫЕ документы абы как.
Жаль не добавили поддержку 7-ки
Ну а докачку, особенно для сетевых шар, они видимо сделают только к 2024 году, во времена Windows15.
Центрирование заголовка окна :(((((((((((((((((((((((((
Вам, ПРАВДА, кажется, что это важно?! вот мне, как рядовому пользователю виндовс, кажется, что им просто уже и делать нечего, осталось только такой фигней заниматься: заголовки посередине сделать и копирование на паузу поставить, можно было бы еще и дать возможность людям курсор заменить на собачку или сердечко какое-нибудь.
Ещё бы табы в проводнике и отсутствие промежуточного копирования файлов на системный диск при перетаскивании (например, если разархивировать файл перетаскиванием из 7-zip в проводник)
Совсем забыл, ещё мечтаю о встроенной системе проверки обновлений для программ и драйверов. А то сейчас у каждой программы своя поделка в автозагрузке.
я думаю поведение при перетаскивании из 7-zip заложено разработчиками этого приложения
Нет, это проблема windows, некоторые разработчики даже свои расширения пишут для обхода проблемы, цитата: «Windows drag&drop mechanics does not allow source application of drag&drop operation to find out easily, where the files are dropped. It is up to target application (Windows Explorer usually) to transfer files to destination.»
Использовал и TeraCopy, и FastCopy, и еще несколько аналогов. Удобный вид представления информации, особенно списком файлов и проверкой CRC (кстати, такого нововведения не предвидится?).
«Разработчики признают, что раньше Windows Explorer был оптимизирован только для быстрого копирования маленьких файлов, но не для копирования большого количества файлов и файлов большого объёма. Теперь это исправили: при наличии нескольких процессов или копировании нескольких больших файлов диалог отображает прогресс-бар для каждого процесса в отдельности.»
И что тут исправили? Сначала говорится про оптимизированность для маленьких файлов (техническая сторона вопроса), потом говорится о диалоге при копировании больших файлов (интерфейс). И где инновации? Вышеназванные программы для копирования имеют функцию изменения размера буфера при копировании (в ручном режиме, а у некоторых даже в автоматическом), что как раз и повышает скорость копирования, подстраиваясь под размер копируемых в данный момент файлов.
«Разработчики признают, что раньше Windows Explorer был оптимизирован только для быстрого копирования маленьких файлов, но не для копирования большого количества файлов и файлов большого объёма. Теперь это исправили: при наличии нескольких процессов или копировании нескольких больших файлов диалог отображает прогресс-бар для каждого процесса в отдельности.»
И что тут исправили? Сначала говорится про оптимизированность для маленьких файлов (техническая сторона вопроса), потом говорится о диалоге при копировании больших файлов (интерфейс). И где инновации? Вышеназванные программы для копирования имеют функцию изменения размера буфера при копировании (в ручном режиме, а у некоторых даже в автоматическом), что как раз и повышает скорость копирования, подстраиваясь под размер копируемых в данный момент файлов.
Пользовался всю жизнь Total Cоmmander'ом и даже не догадывался о существовании таких «ужасных» проблем…
Потому что когда копировали с левой панельки в правую — шли пить чай? Ну да, тогда никаких проблем с несколькими одновременными операциями не возникает.
Единственно что точно всегда бесило в Проводнике — отсутствие нормального Yes to all, и если в XP это ещё худо бедно можно было через Shift + действие сделать, то в Висте это точно не работало.
Единственно что точно всегда бесило в Проводнике — отсутствие нормального Yes to all, и если в XP это ещё худо бедно можно было через Shift + действие сделать, то в Висте это точно не работало.
1) кнопка «В фоне» просто волшебная :) Там же и Пауза. Хм, интересно, в каком году был реализован данный функционал?
2) даже среди пользующихся тоталом мало кто использует (да и я не сразу заметил), ещё более волшебная кнпопка F2 – добавление в очередь. И не надо потом ругать себя, что успел поесть, а снять с паузы второй поток забыл.
2) даже среди пользующихся тоталом мало кто использует (да и я не сразу заметил), ещё более волшебная кнпопка F2 – добавление в очередь. И не надо потом ругать себя, что успел поесть, а снять с паузы второй поток забыл.
раз уж упомянули TeraCopy, FastCopy и Copy Handler то гляньте ещё на эту утилитку. Во многих ситуациях она избавит Вас от написания скриптов копирования. Реализована своими силами, в разумных границах функционал можно ещё расширить.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Windows 8: поддержка USB 3.0 и «умное» копирование файлов