» Total Commander (Часть 8)

suomifinland

Цитата:

Как сделать так чтобы при любых обстоятельствах, при открытии Total в левой и правой половине программы постоянно открывались одни и те же КАТАЛОГИ (предварительно выбранные мною), закрываться Total может с любыми каталогами, но открываться именно с теми которые мне необходимы для работы.

KT315E

Цитата:

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

suomifinland

Цитата:

Браво, браво! Именно то что я и хотела!

Почитал, улыбнуло,в итоге выбрала не совсем тот вариант, что хотела, а нужный и прелестный вариант предложил Skif_off, всего лишь надо, в wincmd.ini - [Configuration] прописать ключ Savepath=0 (добавить строчку), после этого открыть нужные каталоги, заблокировать их и сохранить настройки , после каждого запуска будут открываться вкладки, которые были на момент сохранения настроек, отличный ключ, к своему стыду и не знал о его существовании( век живи - век учись!). А блокировка вкладки, с возможностью смены каталогов, это нечто другое, вкладка ваша будет отображать нужный каталог, но запоминать она будет последний посещенный каталог в этой вкладке. И еше, а как же быть с другими, побочно открытыми вкладками, каталоги - не входящие в вами заблокированные вкладки, они же после перезапуска тоже откроются. А вот с вышеуказанным ключом, задача выполняется на все 100%.

Abel11 (17:11 08-04-2014)
Цитата:

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

Ничего подобного.

Rodny
Да, насчет того, что запоминает последний посещенный каталог, это я как-то на автомате, все же я имел в виду, не после перезапуска, а в процессе работы, при переключении между вкладками, просто привычка, для меня работать так неудобно.

Цитата:

Это концепция Micro$oft, которая более чем имеет право на жизнь

Что за концепция такая, это не тали что все юзеры лохи и не лезте куда не просят. Nicrosoft пусть отдыхает, полно ребят которые лезут и делают нам на радость.

Цитата:

Сейчас мы ему кирпичом в интерфейс

+200

Total Commander 8.51 RC 2
http://ghisler.ch/board/viewtopic.php?t=40139
http://ghisler.com/851_rc2.php

так и не исправили баг с зависшей квадратной иконкой

smersh2012
Что за баг?

Antonij72
Такой. В правом окне черный "окрас" значка папки $Recycle.Bin. В зависимости от настроек (тип цветовой схемы и т.д.) программы баг может проявляться по-разному. Я писал уже об этом здесь.

кто-то уже пользуется скриптом, чтобы операции F5/F6 копирование/перенос происходили сразу, без подтверждения в выскакивающем диалоговом окне?
если "Да" - прошу подсказать как установить.

vapa
вот готовый откомпилированный exe. даже не вспомню сколько лет назад скомпилирован со скрипта.

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

А не выяснили почему, когда делаешь "Перемещение" (F6) с диска, допустим c: на диск, созданный командой subtr f: c:\f производится не перемещение, а копирование, а затем удаление исходного файла. Если файл занимает сотни мегов, то по времени это совершенно разные операции. (far и Teracopy все делают как положено). Там что-то принципиально не под силу Гислеру? Или он не знает об этом. Сообщите, пожалуйста, кто может ему. (ТС 8.51RC2).

Samotek
Может имелась ввиду subst c:\f ? Если да, то никаких проблем с перемещением не заметил. Часто приходится subst использовать.

Цитата:

Может имелась ввиду subst c:\f ?

Таких параметров у subst нет.:


Цитата:

Сопоставление имени диска указанному пути.

SUBST [диск1: [диск2:]путь]
SUBST диск1: /D

диск1: Виртуальный диск, который сопоставляется указанному пути.
[диск:]путь Физические диск и путь,
которым сопоставляется виртуальный диск.
/D Удаление ранее созданного виртуального диска.

Введите SUBST без параметров для вывода текущего списка виртуальных дисков.

Неправильно перемещает с диска С: на виртуальный диск, созданный командой subst F: C:\Папка. И на Win7 64 и на Win XP

Samotek

Цитата:

Таких параметров у subst нет

Сорри конечно нет, использую "subst V: c:\BOOT.ISO\ISO\XP3_14.01.20_DVD"
Перемещение с пом. TC работает с любого локального диска на V:
Win7 x64, TC 8.xx x64 (с правами администратора)

mig73

Цитата:

Перемещение с пом. TC работает

Наверно все таки ты не понял: Я не говорил, что в принципе не работает. Я говорил, что выбирается неправильный алгоритм: изменить ссылку в каталоге или физически переписать файл по новой ссылке. По первому алгоритму разницы во времени перемещения файла в 1байт и 1 гигабйт нет. А во втором - замучаешься ждать. Может, конечно надо поставить какие-то настройки для этого - но какие?

Samotek

Цитата:

не выяснили почему, когда делаешь "Перемещение" (F6) с диска, допустим c: на диск, созданный командой subtr  f: c:\f производится не перемещение, а копирование, а затем удаление исходного файла.

Цитата:

не говорил, что в принципе не работает. Я говорил, что выбирается неправильный алгоритм: изменить ссылку в каталоге или физически переписать файл по новой ссылке.

Честное слово не понял чего вы хотите. Ну да ладно, видимо не дано
Настойки: default для TC - все OK

mig73 11:30 12-04-2014
Цитата:

Честное слово не понял чего вы хотите.

А по-моему, проблема описана вполне внятно. Просто попробуйте сами проделать то, что описывает Samotek: переместить объект C:\Папка с диска С: на виртуальный диск, созданный командой subst F: При этом взять файл или папку размером 10-15 GB, чтобы действительно ощутить разницу (по сравнению с "обычным" перемещением объекта в пределах одного логического раздела). Как говорится, лучше один раз увидеть...

Samotek 14:26 11-04-2014
Цитата:

Почему, когда делаешь "Перемещение" (F6) с диска, допустим c: на диск, созданный командой subtr  f: c:\f производится не перемещение, а копирование, а затем удаление исходного файла.

Потому что именно таков стандартный алгоритм Windows и большинства файловых менеджеров для перемещения файла между разными логическими разделами. Вы же сами велели системе считать разделы C: и F: двумя разными логическими разделами. Но при этом хотите, чтобы TC откуда-то знал, что "на самом деле" это всё-таки один и тот же диск.
Как это удаётся делать FAR и TeraCopy - загадка природы

Не пробовали играть с настройками TC на вкладке Copy/Delete?

oshizelly

Цитата:

Но при этом хотите, чтобы TC откуда-то знал, что "на самом деле" это всё-таки один и тот же диск.

Ну, например проанализировав результаты выполнения команды subst без параметров.

Цитата:

Как это удаётся делать FAR и TeraCopy - загадка природы

Значит, что удается стандартным средствам Windows и нескольким(двум, по крайней мере менеджерам) под силу, а одному Гислеру не под силу? Вот это - действительно загадка!
Кстати Windows именно перемещает. Правда, говорят, иногда сам ошибается... И "Логические" и "Виртуальные" диски - не одно и то-же. Мне так кажется.

Цитата:

Как говорится, лучше один раз увидеть...

Сделал все как вы предложили. Результаты видно сразу: с винта D: на виртуалку, созданную командой "subst v: c:\temp"(на системном логическом разделе того же диска) все переносится (25,1 Gb) со скоростью соответствующей скорости скорости винта D: Перенос с винта D: в созданную папку D:\Папка происходит практически мгновенно (в пределах 1го логического раздела). С виртуалки V: обратно на D: опять же со скоростью соответствующей скорости скорости винта D: В чем фишка то ? Все работает так, как и должно работать. Вот настройки операций с файлами TC:

mig73 03:37 13-04-2014
Цитата:

Результаты видно сразу: с винта D: на виртуалку, созданную командой "subst v: c:\temp"(на системном логическом разделе того же диска) все переносится

Немного не так эксперимент поставлен. Надо попробовать перемещать файл между дисками в пределах одного и того же физического/логического диска.
Например, с диска C: на виртуальный диск, созданный командой "subst v: c:\temp" и обратно.
Либо же, например, с диска D: на виртуальный диск, созданный командой "subst v: d:\temp" и обратно.

oshizelly
Уточню немного: на физическом диске может быть несколько логических дисков, причем с разными файловыми системами. И тогда тс работает как все. А виртуальный диск - всего ли ссылка на директорию. И если в пределах логического диска делать перемещение методом копирования, то это может оказаться еще медленней, чем копирование с одного логического диска на другой.
mig73

Цитата:

со скоростью соответствующей скорости скорости винта

А перемещение в пределах логического диска практически не зависит от размера перемещаемых данных и скорости винта (несколько байт надо переписать).

Samotek 11:32 13-04-2014
Цитата:

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

Не замечал такого, да и никаких разумных причин для этого вроде бы нет.

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

oshizelly

Цитата:

Не замечал такого, да и никаких разумных причин для этого вроде бы нет.

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

Samotek 12:31 13-04-2014
Цитата:

А мне кажется это очевидно - операция чтения на одном физическом диске(физическое перемещение головок дисковода )

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

oshizelly

Цитата:

Исправьте, пожалуйста, опечатку в своём предыдущем посте.

Хорошо, попробую переформулировать, хотя по примеру из моего первого поста http://forum.ru-board.com/topic.cgi?forum=5&topic=45288&start=2920#12 все можно понять правильно:
При перемещении файлов в пределах одного логического диска, если цель или источник заданы виртуальным диском, созданным командой Windows subst, тс не изменяет указатели на файл в иерархии файловой системы, а использует копирование-удаление, несоизмеримо увеличивая время операции.
Так хорошо?

Samotek 13:10 13-04-2014
Цитата:

Так хорошо?

Так, вне всяких сомнений, хорошо, поскольку обобщённо формулирует суть проблемы.

Но вообще-то я имел в виду описку в этом вашем посте, где IMHO отсутствует весьма существенное уточнение:

Цитата:

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

Почему мне кажется, что без этого уточнения существенно меняется смысл - об этом я уже написал двумя постами выше

oshizelly

Цитата:

Надо попробовать перемещать файл между дисками в пределах одного и того же физического/логического диска

Ну так как видно из приведенного скрина, перемещение производилось в пределах одного физического диска, разбитого на разделы С и D.
Вообще поднятая проблема мне кажется очень важной, т.к. ежедневно имеем дело с виртуальными папками и TC. Проблем пока не испытали, но кто знает что дальше будет.

mig73 21:00 13-04-2014
Цитата:

перемещение производилось в пределах одного физического диска, разбитого на разделы С и D.

Вот именно! В пределах одного физического диска, но разных его логических разделов.

А проблема станет наглядной только при перемещении файла между реальным логическим разделом и виртуальным разделом, созданным на базе того же самого логического раздела.
Например, между реальным C: и виртуальным V ("subst v: C:\temp")
Или же между реальным D: и виртуальным V ("subst v: D:\temp").

Но никак не между реальным C: и и виртуальным V ("subst v: D:\temp").

Вот здесь Samotek это обобщённо сформулировал.

насчет всех этих "перемещений-копирований".
я фиг знает сколько времени тому назад (и даже по моему не раз) озвучивал ситуацию, что тотал через одно известное место работает с операциями копирования начиная с Windows 7 и выше в плане адекватности прогресс-бара выполнения операций.
особенно заметно это при работе со съемными накопителями и когда в системе много оперативной памяти или есть SSD.
обычно в таких ситуациях все выглядит так. допустим, вам надо скопировать с раздела на раздел (другой носитель) гигабайтный файл или того хуже, запаковать файл с одного раздела прямо на съемный носитель. прогресс бар мгновенно пробегает примерно до 90% процентов явно из-за неадекватной работы тотала с файловым кешем Windows, а потом резко замедляется, "стоит" на месте и примерно через реально необходимое для осуществления данной операции количество секунд резко делает "прыжок" до 100%.
меня еще давно это настолько задолбало, что я вынужден был "отобрать" у тотала операции чтения-записи и "переназначить" их на известную утилиту TeraCopy, которая адекватно отображает прогресс-бар и, к тому же, прекрасно интегрируется в Тотал.
уже столько версий тотала с тех пор сменилось, а проблема "рваного" прогресс-бара как была, так её Гислер и не собирается решать.