Цитата:
Мультимедию вообще трудно по-папкам раскладывать, нужен набор классификаций и чтобы каждый файл должен быть доступен с разных подходов. Например популярные фильмы могут быть одновременно шедеврами кино-искусства. Редко, конечно, но ведь могут  Хотелось бы такое кино находить в обоих папках. В линуксе можно устроить. Да и в винде можно отдельно держать свалку отдельно каталоги к ней с ярлычками. |
В Windows без ярлыков. NTFS Links (plugin для Total Comander)
[SPOILER="Описание"]Первоначально жёсткие и символические ссылки были изобретены для Unix-подобных систем. Позже они появились и в файловой системе NTFS, созданной фирмой Microsoft® для линейки операционных систем Windows NT. Ниже находится небольшое описание того, что же такое жёсткие и символические ссылки, чем они отличаются друг от друга и как их можно использовать на системе NTFS.
Жёсткие ссылки
Жёсткие ссылки (hard links) - это просто файловые записи, ссылающиеся на одно и то же место в области данных. Предположим, у нас есть файл C:\file.dat с некоторыми данными. И мы создаём на него жёсткую ссылку под именем C:\Folder\other.txt. Тогда для нас это будет выглядеть, как наличие двух файлов с указанными именами, находящимися по указанным путям, причём содержимое этих файлов будет абсолютно идентичным, а как только мы изменяем один из них, тут же меняется и другой. После создания жёсткой ссылки абсолютно невозможно различить, какой из файлов был "главным", а какой был создан как ссылка; теперь это два абсолютно равноправных файла. В файловой системе присутствует счётчик ссылок для каждой области данных, что даёт возможность узнать, сколько на данный момент создано жёстких ссылок на определённый файл. При удалении файла, счётчик которого больше единицы, удаляются не его данные, а только ссылка на них. Сами данные будут уничтожены только тогда, когда счётчик достигает значения 0, т.е. когда в системе больше нет ни одной записи, ссылающейся на эти данные. Таким образом, если в вышеприведённом примере попытаться удалить файл C:\file.dat, то реально место на диске не освободится, поскольку на те же данные указывает ещё одна ссылка: файл C:\Folder\other.txt. И только при удалении этого второго файла счётчик ссылок становится равным нулю и место на диске освобождается.
Создание жёстких ссылок разрешено только в пределах одного NTFS-раздела. Т.е. создать на одном разделе ссылку на файл, находящийся на другом разделе, невозможно.
Поскольку каталог - это, по сути, обычный файл (только с определённым атрибутом и специфическими данными), то, теоретически, ничто не мешает сделать жёсткую ссылку на каталог. В этом случае в системе будут присутствовать два каталога, всё содержимое которых полностью идентично, причём как только меняется содержимое одного из них (например, создаётся подкаталог), эти же изменения отражаются и во втором. В общем, всё точно так же, как с файлами. На некоторых Unix-подобных системах можно создавать жёсткие ссылки на каталоги, хотя и от лица суперпользователя. На NTFS же подобная операция невозможна. Для каталогов на NTFS используются символические ссылки, о которых пойдёт речь ниже.
Символические ссылки
Символическая ссылка на Unix (soft link) - это обычный файл, у которого установлен определённый атрибут, а в качестве содержимого прописано то, на что он указывает. По сути это очень сильно напоминает ярлыки в Windows. В случае символических ссылок есть чётко выраженный "главный" файл или каталог, и одна или несколько ссылок, которые на него указывают. Если этот файл/каталог переименовать, переместить или удалить, то все символические ссылки, указывавшие на него, станут нерабочими. При удалении "главного" файла данные уничтожаются сразу (если, конечно, у него нет ещё и жёстких ссылок!), никакого учёта символических ссылок в файловой системе нет.
На NTFS принципы создания и хранения символических ссылок принципиально другие. Строго говоря, никаких символических ссылок на NTFS нет. Вместо этого на этой системе существуют так называемые точки монтирования (junctions), которые позволяют подключать не только каталоги, но и диски, и сетевые пути... С точки же зрения пользователя работа с ними будет выглядеть практически так же, как и с описанными выше символическими ссылками Unix, с единственной лишь разницей: на NTFS невозможно создать символическую ссылку на файл. Поэтому я здесь и далее буду продолжать называть их символическими ссылками.
Для файлов можно пользоваться либо уже описанными выше жёсткими ссылками, либо же стандартными ярлыками Windows, которые, кстати, не ограничены системой NTFS и прекрасно работают в FAT, а также могут указывать на файлы с других дисков.
Замечание:
В окне Total Commander жёсткие ссылки отображаются как обычные файлы, поскольку, как было сказано выше, они неотличимы от "главных" файлов.
Для символических же ссылок используется специальный значок: Разумеется, он может быть другим, если используется альтернативная библиотека значков, где данный значок (номер 13) переопределён. Однако имейте в виду, что если символическая ссылка имеет атрибут "только для чтения", "скрытый" или "системный", то для её отображения используется обычный значок каталога. Будьте осторожны в использовании данной возможности, так как в этом случае, вы сами не сможете отличить каталог от символической ссылки!
Применение ссылок
"Это всё, конечно, хорошо," - скажет кто-нибудь. - "Но зачем мне вообще нужны какие-то там ссылки NTFS? Обходился без них, и теперь обойдусь." Спорить, конечно, сложно. Но точно так же я могу сказать: "А зачем нам вообще эта Windows? Обходились без неё, сидели на MS-DOS, и всё было прекрасно." Здесь то же самое. Да, можно обойтись без ссылок. Но существуют ситуации, в которых применение ссылок NTFS гораздо удобнее и эффективнее остальных способов решения проблемы. Здесь я приведу несколько примеров того, как можно использовать жёсткие и символические NTFS-ссылки, причём именно в случаях, когда достижение той же цели другими средствами либо влечёт за собой значительные неудобства, либо невозможно в принципе.
1. Программы с общими данными.
Пусть у нас есть две или больше программ, которые совместно работают с одними и теми же данными (неважно, параллельно или по отдельности). Логично было бы держать все их общие файлы в одном каталоге (а в случае с параллельным выполнением иначе может и не получиться вообще). Хорошо, если программы позволяют явно указать, в каком каталоге находятся нужные им файлы. А если не позволяют, а требуют, чтобы они обязательно были рядом с ними, в определённом подкаталоге? Или программ с добрый десяток, и все они ссылались на один каталог, а теперь каталог надо переместить в другое место (например, чтобы освободить место на диске)? Вот тут на помощь и приходят возможности NTFS. Просто создаём символическую ссылку, указывающую на нужный нам каталог, который может быть где угодно, а сами ссылки размещаем, где нужно, и даём им требуемые имена... И ничего не надо перенастраивать, т.к. обращение к символической ссылке происходит в точности так же, как и обычное обращение к каталогу. Программы попросту ничего не заметят (ну разве что изменение скорости работы, если диски имеют разную производительность).
2. Перенос папок в другое место.
Теперь рассмотрим ещё раз предыдущий пример, только вместо программ возьмём простого пользователя, которому понадобилось переместить какую-то свою папку на другой диск. Неважно, с какой целью. Может быть, необходимо освободить место на диске; может быть, другой диск более надёжен. Важно то, что по привычке он будет ещё долго пытаться попасть в свою папку по её старому пути, каждый раз негромко матерясь на свою забывчивость, и так пока не привыкнет к новому местоположению. А оно надо - привыкать? Делаем символическую ссылку на новое местоположение, размещая её там же, где раньше находилась эта папка. И теперь обращаемся к ней, как и раньше, совершенно не замечая разницы, только уже достигнув тех целей, ради которых и был совершён перенос папки на новое место. Просто? Да. Удобно? Да. Почему не используем? Пожатие плечами... :-)
3. Защита DLL от удаления.
Пусть мы установили какую-то программу, которая использует свою супер-навороченную DLL-библиотеку... ну, назовём её, скажем, Super.dll. Что такое DLL? Это библиотека, используемая несколькими программами сразу. И размещается она обычно в общедоступном месте, например, в каталоге Windows. И вот та же фирма выпускает ещё одну программу, использующую ту же самую DLL. Какое-то время мы пользовались ими обеими, а потом решили первую программу удалить. И случилась такая незадача, что деинсталлятор программы "не заметил", что есть ещё одна программа, использующая тот же файл Super.dll, и удалил его. Вторая программа теперь просто перестанет работать. Как же этого избежать? Да очень просто. Делаем жёсткую ссылку на файл Super.dll. Название этой ссылке даём точно такое же - Super.dll, а размещаем её в каталоге второй программы. Теперь удаление первой программы ни к чему страшному не приведёт: удалится всего лишь одна из жёстких ссылок на DLL-библиотеку, а сама она останется жива, и оставшаяся программа сможет загружать эту же самую библиотеку, обращаясь к ней по созданной жёсткой ссылке. Мало того, это не потребует ни одной дополнительной строки кода в программе, поскольку DLL-файлы автоматически подхватываются из каталога самой программы.
Разумеется, та же проблема прекрасно решается обычным копированием DLL в нужное место, но при этом будет тратиться дисковое пространство. Если же использовать жёсткие ссылки, то на диске физически присутствует только одна копия файла.
4. Защита других важных данных.
Этот пример дополняет предыдущий пункт, образуя с ним такую же логическую пару, какую образовали пункты 1 и 2. Т.е. снова вместо программы тут выступает пользователь.
Не знаю, кто как, а я иногда удалял файлы, которые считал ненужными, а через месяцок после этого спохватывался: "Ах я дурак, сам же себе говорил, что этот файл нельзя удалять!.." К сожалению, я не знал тогда о таком инструменте, как жёсткие ссылки, и данные оказывались безнадёжно утерянными. Разумеется, жёсткие ссылки - не панацея. Но защитить файл с заурядным именем, но важными данными они помогут. Просто создаём на нужный нам файл жёсткую ссылку в каком-нибудь каталоге, из которого мы точно ничего удалять не будем (завести, скажем, специальный каталог с коллекцией таких жёстких ссылок - почему бы и нет?) Теперь, даже если мы и удалим первоначальный файл, посчитав его ненужным, он останется на диске, и мы сможем обратиться к нему по созданной ранее жёсткой ссылке.
И снова заметим, как и в пункте 3: да, можно того же самого добиться простым копированием. Но при этом будет расти и занимаемое место на диске.
5. Объединение разбросанных каталогов.
Предположим, нужно иногда открывать доступ по сети к куче разных каталогов, которые разбросаны по разным дискам, лежат в каталогах разного уровня вложенности и т.п. Можно написать два CMD-скрипта, которые будут, соответственно, открывать и закрывать доступ. Можно даже исхитриться и объединить их в один скрипт, которому нужное действие задаётся в виде параметра командной строки. А можно просто собрать в один каталог символические ссылки на все эти подкаталоги и одним махом, стандартным и прывычным способом открывать и закрывать сетевой доступ сразу к ним всем.
В общем, как вы видите, применений может быть масса, этими пятью вариантами дело не ограничивается. В конце концов, у каждого свои задачи. Кому-то нужно одно, кому-то - другое. Включите фантазию, используйте данные вам возможности на полную катушку! Пусть компьютер делает то, что нужно вам, а не наоборот!
[/SPOILER]
Re: Поиск фильмов и прочих киноматериалов
Линейный вид
