Організація файлів на комп’ютері

Думаю, що у всіх, хто працює з комп'ютером, є якась стратегія організації файлів, а у програмістів точно.

Я опишу, як сам організую файли, у формі майже розрізнених ідей-нотаток. Може, щось буде корисно комусь, і може хтось поділиться своїми прийомами.

На Мак я пересів нещодавно, і робочий ноутбук у мене все одно на Windows 7, більшість прийомів орієнтовані на Windows.

Основна мета моєї структури - мінімізувати і максимально спростити бекап та потенційну міграцію на інший комп'ютер. За правильного підходу ці завдання можна вирішувати як одну.

Усі рекомендації нижче рухомі саме цією метою.

Один із підходів для вирішення обох завдань – зробити так, щоб усі мої файли були доступні в ієрархії одного єдиного каталогу. “Мої” означає, що у разі переїзду на інший комп'ютер, ці файли мають бути перенесені (не забуті). Я маю каталог c:\moe (етимологія англійського “слова” moe втрачена). Рухаючись цим каталогом вниз, можна знайти всі "мої" файли, все-все. Також важливо, що в каталозі c:\moe немає сміття, яким зазвичай загажено My Documents (будь-які проекти-приклади, що створюються Студією без попиту, міріади інших папок My. від різних програм і т.д.). Тобто, це чиста корисна інформація без неконтрольованого сміття.

Навіщо такі складності? Не секрет, що в Windows розташування деяких файлів "за замовчуванням" дуже незвичайне, і далеко не всі програми дозволяють змінювати їхнє розташування. Спробуйте знайти базу даних Outlook Express або Microsoft Outlook, профайли Thunderbird'у, Chrome'у або iTunes, налаштування сесій SecureCRT і т.д. Всі вони зазвичай ховаються десь у надрах c:\Users\your_user_name. Можна тупо бекапити цей каталог, але, знову, там дуже багато неконтрольованого г * вна.

Отже, за допомогою символьних посилань я навів усі необхідні каталоги до простих шляхів. Наприклад:

Ідемо далі. Останнім часом я став люто ненавидіти програми, які зберігають конфігурацію та налаштування в реєстрі. Я ще можу зрозуміти, що Microsoft Office користується реєстром через “глибоку інтеграцію” до системи. Але чому Far або putty досі не можуть просто користуватися текстовим файлом для налаштувань і зберігати його в c:\Users\. - не зрозуміло. Для таких програм у мене написаний скрипт, який командою reg копіює параметри потрібних гілок реєстру в текстові файли. Що такого корисного є в налаштуваннях Far? Наприклад, ftp/sftp сесії. У мене їх близько сотні, і втратити їх не хочу.

Окремим рядком хочу відзначити програми, якими можна використовувати у портативному режимі. У мене є окремий каталог для них, наприклад:

Зазвичай, у цьому каталозі я тримаю невеликі програми, які можна просто копіювати без установки, і без яких некомфортно. А так просто переніс цей каталог на іншу машину, і мінімальний набір утиліт вже є.

Далі, каталог c:\moe\cmd. Тут лежать різні саморобні скрипти та однофайлові мікро утиліти типу junction.exe. Цей каталог знаходиться під контролем git, тому що скрипти часто змінюються, і хочеться бачити історію змін.

Тут лежить усе, що з програмуванням. Ієрархія цього каталогу зазвичай однорівнева: проект -> каталог. Одна умова (підтверджена роками) – не використовувати прогалини в іменах каталогів. Сильно спрощує скриптування.

Також корисно зробити лінк каталогу c: Program Files в c: prg . Простіше працювати у скриптах із програмами, встановленими в цьому каталозі.

Ще один каталог - c:\moe\documents.

Тут лежать те, що називається документами, без прив'язки доякийсь проект: doc(x), xls(x), pdf, jpg тощо. Тут уже допустимі імена з пробілами та українськими літерами. Внутрішня ієрархія – за змістом. З документами на роботі я часто створюю підкаталоги в номері року. Вони зручно прибирати старі. Наприклад:

Якийсь час тому я почав активно користуватися атрибутом read-only. Якщо я бачу, що не змінюю файл деякий час, наприклад, пару місяців, то я роблю його read-only. Це стосується і проектів і документів. Атрибут read-only дозволяє виключити випадковий перезапис старого файлу, відкритого для отримання прикладу з минулого. Ну а якщо захочеться його таки змінити, то треба буде знімати прапор read-only або робити копію через “Save as…”. Основна ідея - старий файл не треба перезаписувати, тому що історія його створення може бути призабута, і можна випадково похерити важливий файл. Усі його похідні мають бути зроблені через клонування.

До речі, у Mac OS Lion компанія Apple зробила функцію "залочки" файлів, які не змінювалися деякий час.

Documents буде також автоматично бути locked, якщо вони не змінюються для малого while. Auto-lock time configurable в “Options…” кнопки Time Machine preference pane (of all places), з значеннями з одного дня до одного року. Default is 2 weeks.

Є ще кілька каталогів:

c:\moe\books - книги
c:\moe\itunes - база даних iTunes
c:\moe\soft - архів програм (зазвичай дистрибутиви)
c:\moe\vm - віртуальні машини

Для фізичного здійснення бекапу я використовую nnbackup. Це дуже просунута програма, але я використовую в ній лише одну функцію односторонньої синхронізації - при черговому збереженні кожен файл у каталозі c:\moe, який змінився, буде оновлено. Але виході, щеразів, точна копія цього каталогу на страховому носії.

Під завісу для редагування змінних оточення в Windows я використовую RapidEE. Складно уявити зручнішу програму.

P.S. Додаткова доважка (щоб двічі не вставати), яка начебто як за темою, але не зовсім. У тій же статті про Lion описується, що Apple запровадила поняття версійності документів на рівні API. Я бачив схоже в одній із систем розробки у Блумберзі – в IDE не треба було примусово зберігати файли проекту. У будь-який момент часу середовище забезпечує збереження файлів, і у разі зависання чи інших проблем під час перезапуску відкриті файли автоматично відновлювалися з autosave'а. А ось якщо розробник примусово зберігає файл (наприклад, натискає Ctrl-S), то файл не просто зберігається, а робиться commit у SVN з новою ревізією, і доводиться також вводити опис цієї зміни.

Спочатку мене такий підхід бісів, так як багаторічна звичка в досовських "масувати" F2 або Ctrl-S кожні три секунди призводила до вікна введення опису змін. Але згодом я реально підсів на це. Тепер Збереження набуло сенсу, а не лише засобом порятунку від зависання в процесі запуску.

Я був приємно здивований, то в Lion такий підхід введений на рівні операційної системи. Тут, звичайно, у Apple основна мета трохи інша - вони хочуть тим самим повністю позбавитися питань про збереження незбережених документів при виході з програми, щоб їх (додатки), можна було непомітно для користувача вбивати і перезапускати заново, як в iOS. Забавно, що в Lion за замовчуванням у Dock'і забрали індикатор запущеності програми. Основне посилання таке - користувача це питання більше не повинен хвилювати. Операційна система запустить програму, якщопотрібно, і сама вб'є його, якщо є потреба у його ресурсах. Документи ж завжди будуть у безпеці.

Хто ще поділиться ідеями та прийомами організації файлів?