Работаем с NTFS. Проблемы

Привет всем!

Итак, настраиваю один сильно юзаный ноут после фатальной поломки харда. То есть хард новый и девственно чистый. Настраиваю не себе и завтра-послезавтра надо возвращать продукт. Естественно, он должен блестеть как котовы яйца в теплый мартовский день. Это диспозиция.
Теперь позиция - ставим первой систему офтопичную, семерку. Ну - дело привычки юзера, дело святое. Делим хард на три половинки, на систему-7, большую файлопомоку и под linux (как же мне без него). Естественно система-7 и файлопомойковый раздел форматируется как ntfs и юзерский профиль при установке офтопика переносится на этот файлопомойковый раздел. Это данность.
Далее в третий раздел (небльшой) ставлю RFR-20-x86_64 + GNOME-3. Все из кАропки. Далее, для заведенного юзера выбрасываем отдельные каталоги из хомовника на большую файлопомоку и связываем их с соответствующими каталогами профиля юзера в офтопике. Делаю это биндом в /etc/fstab (что куда ntfs defaults,noexec,bind,uid=,gid=,fmask=0111 0 0). то есть монтирование идет на конкретного юзера и файлы на ntfs-разделе получаются с правами с числом зверя 0666. Что и надо.
А теперь - что получаем в итоге.

1. Если на ntfs-раздел переносим юзерский каталог "Рабочий стол", то *.desktop файлы, размещенные на рабочем столе, не полностью подхватываются гномом. То есть не показываются их уникальные иконки (только дефолтное изображение, а не то, что в desktop-файле прописано) и при запуске Linux в лице GNOME сомневается в их валидности, не доверяет им и просит подтвержения. Причем, подтвержаем, более того, даже говорим, что оно доверенное, но GNOME эту информацию пропускает мимо себя и на следующем запуске снова недоверчиво утоняет, запустим или нет. Если же рабочий стол - родной, не прибинденный из ntfs-раздела, то проблем с desktop-файлами нет никаких, всё работает как в аптеке.
Собственно вопрос первый - это бага или фича? И можно ли это починить? Есть вполне обоснованное желание поместь рабочий стол именно на большой диск, так как юзер глуп, туп и нелюбопытен. Начнет растить свою файлопомойку на маленьком хомовнике от "Рабочего стола" и большой диск тривиально проигнорирует... А потом - ай-ай-ай, место кончилось...

2. И второе наблюдение. Если прибиндиванием ntfs-ные каталоги к себе в хомовник, то перестает работать корзина на этх прибинденных каталогах. То есть, если удаляем файл в традиционном каталоге, то он перемещается в корзину, откуда потом может быть легко извлечен. Но, если удаляем файло на прибинденном каталоге, то создается в корне этого прибинденного каталога скрытая папка .Trash-UID, удаляемый файл перемещается в неё (что правильно), но вот "Корзина", что размещена на "Рабочем столе" этого .Trash-UID не видит, не догадывается об его наличии ничего оттуда стандартным методом восстановить не дает. Естественно нет и легальной возможности (без написания самописного скрипта) и почистить эти "локальные" корзинки .Trash-UID... С этим никто не сталкивался? Может есть какой параметр, которым можно подключить эти "корзинки" к основной Корзине?

Просто надо не -o bind, а /home на корневом разделе. А все прочее (downloads, documents и т.п.) через создание каталогов на целевом разделе и симлинков на них в ~username. Плюс прописать в ~/.config/xdg-user-dirs{,.dirs} имена симлинков, после чего сделать xdg-user-dirs-update. Из параметров mount можно и нужно nodev, noexec, nosuid, uid=1000, gid=100, dmask=007, fmask=117 (для моей Слаквари), как оно будет в федоре - проверьте, должно быть нормально. И да, поправьте меня, если что-то упустил.

yars написал:

Просто надо не -o bind, а /home на корневом разделе. А все прочее (downloads, documents и т.п.) через создание каталогов на целевом разделе и симлинков на них в ~username.

Про симлинки я знаю. Дело не в них. Весь цимес идеи был именно в прибиндивании нужных каталогов. А оно не получилось в должном объеме...

Cruiser78,
кстати, а не связано ли недоверие с правом первого встречного менять файлы, с тем самым 666, проверьте на всякий случай такое предположение.

bormant написал:

Cruiser78,
кстати, а не связано ли недоверие с правом первого встречного менять файлы, с тем самым 666, проверьте на всякий случай такое предположение.

Не согласен. По моим настройкам fmask=0111, что дает права на ntfs именно 666. Обычно, если я копирую откуда-то desktop-файл на рабочий стол (или создаю его скриптом) то при первом запуске такой недоверчивый вопрос задается. А потом - оно где-то запоминается и больше вопросов не задается. А здесь... Непонятно.

С другой стороны - рабочие столы в Linux и в оффтопике разные... так что их можно и не совмещать. Научить юзера, куда именно складывать своё файло... Но... корзину научить работать надо.

А вот с корзиной - более-менее разобрался. Точнее, менее, чем более. Собака зарылась в том, что дефолтная корзина расположена в папке ~/.local/Trash. То есть в весьма ограниченном по размеру хомовнике. А вот прибинденные каталоги находятся на ином томе (да еще в иной файловой системе). Удаление же с корзиной присходит командой mv что 2Trash. Естественно, что между различными дисками mv не отрабатывает. Надо там юзать cp && rm -f.

Вот интересно, как все-таки научить корзину работать с несколькими различными дисками...

"Cruiser78" написал:

Естественно, что между различными дисками mv не отрабатывает. Надо там юзать cp && rm -f.

"Cruiser78" написал:

Вот интересно, как все-таки научить корзину работать с несколькими различными дисками...

drBatty написал:

WTF?

Ну, машинку уже забрали. Так что доделать не успел. Но...
поробовал mv между дисками - проблем не возникло. А вот при удалении файла - почему-то возникает состояние ошибки, пишет что не может переместить файло в корзину и предлагает его удалить безвозвратно. К тому же и в самбе ситуация похожая. Если настраиваем самбовую корзину на ином томе, то надо немного шаманить с командами самбы, говорить рециклу что он crossrename.

drBatty написал:

симлинк сделайте.
вот из этого: ~/.local/Trash

вот чуть поподробнее разжевать можно?
Я сейчас ~/local/share/Trash тоже отогнал (биндом) на большой том. Чтобы удаление большого файла не переполнило небольшой хомовник. Если открыть саму корзину, то её содержимое нам видно. Но вот при попытке удаления с рабочего стола (он в хомовнике родной) - в неё ничего не помешается, идет предложение удалить файл перманентно.
При удалении файлов из прибинденных каталогов (типа Изображения или Музыка) - в эту корзину тоже ничего не падает. Там локальные корзинки возникают, .Trash-UID. И вот как именно ссылку на эти .Trash-UID'ы в главном ~/.local/share/Trash обозвать? Там же какая-то структура должна поддерживаться. Я не смог найти документации на это дело...

"Cruiser78" написал:

поробовал mv между дисками - проблем не возникло.

"Cruiser78" написал:

А вот при удалении файла - почему-то возникает состояние ошибки

"Cruiser78" написал:

вот чуть поподробнее разжевать можно?

drBatty написал:

Вы хоть свой ФМ озвучте, если это дельфин, то я посмотрю, а если нет, то не ко мне вопросы.

Так вроде озвучил изачально - RFR-20+GNOME3.10. А в нём, в этом гноме по дефолту ФМ - наутилус. Структура папки Trash у него проста:
[console]$ ls -1
expunged
files
info
[/console]
Trash-UID'ы в прибинденных каталогах имеют стуктуру аналогичную, нет только каталога expunged.

Хотя, мне интерсны решения и для дольфина. Вообще надо разобраться, как перенести корзину на иной диск, большой диск.

PS. кстати, проверил сейчас на "стенде": если корзина в стандартном месте и на большой том заходим по сим-ссылке, то удаление в стандартную проходит нормально. Если же целевой каталог прибиндиваем - удаление идет в локальный для того ресурса каталог .Trash-UID. Ну а остальное - уже завтра...

Cruiser78 написал:

Я не смог найти документации на это дело...

Это GNOME, документация по его компонентам где-то на gnome.org и (частично) на freedesktop.org. Конкретно корзина работает на возможностях gvfs.

"Cruiser78" написал:

Так вроде озвучил изачально - RFR-20+GNOME3.10

"Cruiser78" написал:

Хотя, мне интерсны решения и для дольфина.

drBatty написал:

там вроде и проблемы такой нет.

Ну, не знаю, а на RFR-20+GNOME3 это что-то с нечтом.
Итак имеем большой ntfs-раздел на HDD. Монтируем его через запись в fstab вполне тривиальной строки:

UUID=D8244AC9244AA9F8                     /mnt/sdb                 ntfs    defaults,noexec,nosuid,nodev,uid=1000,gid=1000,fmask=0137,dmask=0007  1 2

То есть - для конкретного юзера (на ноуте как-то с юзерами не густо) и с вполне определенными пермиссиями. У меня параноидальное желание не давать возможности юзеру стартовать по дефолту какие-либо задачи откуда угодно. А так - на файло с файлопомойки атрибут "x" не ставится, небольшое затруднение создано.
Для экспериментов берем еще один раздел. Он у меня под xfs сделан и смонтирован в /mnt/sdc (с опцией default).
Теперь эксперименты с корзиной.
1. Корзина расположена на стандартном месте.
1.1. Удаляем ntfs-файло заходя наутилусом в нужный каталог на /mnt/sdb. Удаляется, при удалении помещается в стандартную корзину. Соответственно через симлинки файлы тоже удаляются в корзину.
1.2. Удаляем xfs-файло заходя наутилусом в нужный каталог на /mnt/sdc. В контекстном меню вместо выбора "Удалить" видим "Удалить безвозвратно", то есть мимо корзины. Корзина отдыхает полностью. Удалить в неё невозможно. Почему - непонятно. С NTFS-тома удаление идет.
1.2.1 Создаем в корне (ext4), хомовник на отдельном разделе живет, общий каталог с правами 0777. Делаем в нём файлик. Пытаемся удалить - снова мимо кассы. Видим только "Удалить безвозвратно"... Опять же думаем, почему с NTFS-тома удаление идет в корзину, а здесь нет.
1.3. Прибиндиваем себе в желаемое место хомовника каталог из ntfs-тома. Удаляем наутилусом файл. Удаление идет. Но не в главную корзину, а в локальную, которая создается в этом прибинденнном каталоге под именем .Trash-1000 (c UID юзера). Главная корзина этого траша не видит и не знает о его существовании. Как этот локальный Trash подключить непонятно.

2. Начинаем решать основную задачу. Хомовник у нас маленький, а юзер легко поместит в корзину фильм на несколько гигабайт и будет потом ныть, что linux отстой... Значит надо перенести корзину на тот же большой ntfs-раздел. Есть два путя, симлинком и биндом.
2.1. Делаем на ntfs "Корзину", то есть копируем туда ~/.local/share/Trash. Далее можно сделать один симлинк на эту цель, а можно внутри хомовного траша сделать симлинки на каталоги ntfs-траша. Это неважно, результат всё равно один - при попытке удаления файла появляется диалог с сообщением, что система не смогла перенести файл в корзину и с предложением удалить его безвозвратно. Оопс...
2.2. Теперь проверяем прибиндивание ntfs-корзины. Тот же самый. Корзину можно открыть, посмотреть её содержимое (если оно есть), даже можно очистить. Но вот удалить файл никак не удается в корзину. Там создается соответствующий info-файл НУЛЕВОЙ длины, имеющий владельцем юзера, и опаньки. Далее - сообщение о проблемах перемещения файла в корзину. В journalctl, при этом, ничего не пишется. Понять, в чем причина ошибки никак.

Как вынести Trash из ~/.local/share непонятно совершенно.

В лог systemd ничего и не будет падать, а вот в ~/.xsession-errors - весьма вероятно.

yars написал:

В лог systemd ничего и не будет падать, а вот в ~/.xsession-errors - весьма вероятно.

Нет, проверил версию. Не годится. Во первых, у меня этот файл датирован аж январем 2014 года. Ну, может быть идет дописывание с сохранением даты... А во вторых - грохнул я этот файл, повторил ошибку записи в корзину. Новый файл с логом ошибки не создался.
Так что версия хорошая, но неверная.
=========================
более того, сделал еще одну проверку. Вынес ~/.local/Trash не на ntfs-том, а на xfs. На юниксовую файловую систему. Увы, результат тот же самый. В каталоге Trash/info создается соответсвующий файлик нулевой длины и опаньки. Я думал, что там проблема в принудительном задании пермишенов на ntfs-файл; обламывается, например, chmod после создания touch'ем файла описания и вываливается вся процедура в эксепшен. Ан нет, на юниксовой файловой системе, где все права управляемы (проверил руками, ошибок нет, chmod созвращает честный 0), тоже самое. И, возникает ошибка, после которой файл в корзину не помещается.