Окружение проблемы:
1. Под "нестандартной ситуацией" я понимаю использование в ПК не "обычного" (в большинстве ПК) набора дисков: типично это жесткий диск как носитель ОС и, возможно, подключаемые либо всегда присутствующие диски иной физической сущности, как то: SDD, CD/DVD etc. У меня же, скажем на нетбуке, диском, несущим (одну из рассматриваемых) ОС, является "флешка" (хотя на основном диске тоже есть ФС с Осью, но в данном разрезе этот диск можно рассматривать лишь как диск, несущий пользовательские данные). Итак, в обычном выводе mount:
/dev/sdb1 on / type ext4 (rw,errors=remount-ro)
/dev/sda1 on /media/1A80B46980B44D4F type fuseblk (rw,nosuid,nodev,allow_other,allow_other,default_permissions,blksize=4096)
Устройство /dev/sdb1 - это "флешка", несущая ОС (скажем хUbuntu или лUbuntu); устройство /dev/sda1 - это "основной" диск ПК. (У меня он является NTFS-диском, но в принципе, я думаю точно такая же ситуация будет при наличии дисков с любой иной ФС...)
2. Использование некоторых программ(*), которые в своих конфигурационных файлах имеют ссылки на, скажем, документы и прочие пользовательские ф-лы, расположенные именно на диске, упомянутом в п.1, т.е. ссылающиеся на диск, который формально определяется ОС как кандидат на (авто)монтирование и который *формально* должен быть доступным сразу после старта ОС.
* Например, использование юзером редактора Geany с "проектами", ссылающимися на многие ф-лы, лежащие на описываемом автомонтируемом диске.
3. Нет никаких проблем с использованием подобного диска сугубо "вручную", т.е. открыв папку в файловом менеджере ОС на таком диске, кликнув на ярлыке данного устройства. Папки открываются без проблем и даже без ощущаемых глазом задержек: поэтому поначалу я думал, что примонтирование подобного диска осуществляется ОС где-то на стадии старта... пока не наткнулся на описываемую проблему.
Описание самой проблемы:
Если сразу после старта ОС запустить подобную программу, скажем Geany с "проектами"), предварительно вручную не открывая папки на описываемом в п.1 диске, оказывается, что данная программа не может открыть те документы (ф-лы), которые имеет в "автостартуемой" конфигурации. Иными словами, скажем Geany откроет тут не проект, имеющий сохраненные ранее наборы документов, а совсем пустой окно (без вкладок сохраненных ф-лов).
Проблема усугубляется в случае задействования системы автосохранения (точнее Автозапуска) приложений, которые сохраняют юзеру прошлый сеанс работы, ибо при старте такой проект должен быть априорно открыт ДО(*) любых ручных манипуляций юзера с ФС.
* Вообще говоря скажем ф-ция Автозапуск в ЛUbuntu позволяет назначить задержки (от 1 и более сек) для любого назначенного приложения. Но это паллиатив и предполагает, что юзер обязан после старта ОС открыть папку на описываемом "проблемном" диске, чтобы "подмонтировать" его...
Вот те ОС, под которыми я столкнулся с проблемой... и разрешил её лишь указ. ниже образом (увы, вполне "стандартным" ручным прописыванием "жесткой" конфигурации своих дисков):
Lubuntu, Xbuntu, PuppyLinux (т.е. это все дистросы, приемлемые для нетбуков особенно)
Под хUbuntu попробовал было задействовать Gigalo (а под PuppyLinux давно юзаю, -- но это действенно лишь в иных конфигурациях дисков ПК, -- демона hotpup), однако никакого толку от него именно в данном разрезе проблемы не оказалось... Вывод: похоже, что ни одно (
) из распространенных средств "автомонтирования" дисков, которые по-видимому ОС (или этот автомонтёр) воспринимает почему-то как removable, не стартует настолько рано, чтобы к моменту готовности ОС к работе уже все *физически* доступные диски оказались бы подмонтированными и готовыми к работе...
Решение-"костыль":
Прописать в fstab свой "проблемный" диск вручную, ***взяв параметрами вывод mount*** (из уже примонтированного состояния ФС своего ПК).
У меня это такая запись (ВНИМАНИЕ: не копировать бездумно!):
/dev/sda1 /media/1A80B46980B44D4F auto rw,nosuid,nodev,allow_other,blksize=4096,default_permissions
Какие "продвинутые" идеи?
Кстати, припоминается, что с чем-то схожим сталкивались и иные пользователи в принципиально сходной ситуации, хотя по внешним проявлениям кажущейся многоликой, и "решение" было увы таким же: ручная пропись...