«Невозможно найти или создать каталог мусора» в Thunar, используя XFCE

Заявленное намерение ОП

предисловие и обоснование исходного ответа обновлено 18 мая 2015 г.

mikeserv (ОП) заявил в последнем обновлении своего вопроса: «Я считаю позором , хотя то, что я впервые задал этот вопрос, чтобы указать на источник дезинформации, , и, к сожалению, ответ, получивший наибольшее количество голосов, в значительной степени вводит в заблуждение »

. ]Ну ладно; Я чувствую, что было довольно обидно, что я потратил так много времени, пытаясь понять, как объяснить, что я имею в виду, только чтобы найти , что , когда перечитывал вопрос. Этот вопрос закончился "[порождением] обсуждения, а не ответов" и в итоге составил ~ 18 КБ текста (только для вопроса, для ясности), что было бы долго даже для сообщения в блоге.

Но StackExchange - это не ваша мыльница и не ваш блог. Однако, по сути, вы использовали его, по крайней мере, как частичку того и другого. Люди в конечном итоге тратили много времени, отвечая на ваши «важные замечания», вместо того, чтобы отвечать на реальные вопросы людей. На этом этапе я буду отмечать вопрос как не подходящий для нашего формата, учитывая, что OP прямо заявил, что это даже не предназначалось для того, чтобы быть вопросом.

На данный момент я не уверен, был ли мой ответ по существу или нет; возможно, нет, но он был направлен на некоторые из ваших вопросов, и, возможно, это может быть полезным ответом для кого-то еще; новички воодушевляются, некоторые из тех "не" превращаются в "иногда делаю", когда вы набираетесь опыта. :)

Как правило ...

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

[в значительной степени переработано из моего исходного ответа]
после рассмотрения, я считаю, что я ошибся -читайте акцент, сделанный OP на вопросах, на которые я отвечал; тем не менее, затронутые вопросы были , и я оставил ответы в основном нетронутыми, поскольку считаю, что они являются точными и касаются вопросов, которые, как я видел, возникали в других контекстах. по поводу советов новичкам.

В исходном сообщении по-разному задавался вопрос, почему в различных статьях даются такие советы, как «Не анализируйте вывод ls » или «Никогда не анализируйте вывод ls » и так далее.

Мое предлагаемое решение проблемы состоит в том, что примеры такого рода утверждения являются просто примерами идиомы, сформулированной несколько иначе, в которой абсолютный квантор сочетается с императивом [например, «не [никогда] X »,« [вы должны] всегда Y »,« [никогда не] Z »] для формирования утверждений, предназначенных для использования в качестве общих правил или рекомендаций, особенно когда они даются новичкам в предмете, а не как абсолютные истины, несмотря на кажущуюся форму этих утверждений.

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

И тогда эксперт, возможно, решит сделать что-то в нарушение «Правил». Но это не сделало бы их менее «Правилами».

Итак, к обсуждаемой теме: на мой взгляд, только потому, что эксперт может нарушить это правило, не будучи полностью разбитым, я не вижу никакого способа, которым вы могли бы оправдать, говоря новичку, что " иногда «нормально анализировать вывод ls , потому что: это не . Или, по крайней мере, новичку точно так не поступать.

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

Правила, которые должны быть нарушены?

Читая статью по теме, которая предназначена для новичков или может быть прочитана ими, вы часто будете видеть такие вещи, как это:

  • «Вы не должны когда-либо делай X ».
  • « Никогда не делай Q! »
  • « Не делай Z ».
  • « Всегда нужно делать Y! »
  • « C, неважно что. "

Хотя эти утверждения определенно кажутся констатирующими абсолютные и вневременные правила, это не так;вместо этого это способ сформулировать общие правила [a.k.a. «руководящие принципы», «практические правила», «основы» и т. д.], что, по крайней мере, возможно, является одним из подходящих способов изложить их для начинающих, которые могут читать эти статьи. Однако только потому, что они сформулированы как абсолютные, правила, безусловно, не связывают профессионалов и экспертов [которые, вероятно, были теми, кто суммировал такие правила в первую очередь, как способ фиксировать и передавать знания, полученные при решении повторяющихся вопросы в их конкретном ремесле.]

Эти правила определенно не собираются раскрыть, как эксперт будет решать сложную или нюансированную проблему, в которой, скажем, эти правила конфликтуют друг с другом; или в которых соображения, которые изначально привели к правилу, просто не применимы. Эксперты не боятся (или не должны бояться!) Просто нарушать правила, которые, как им известно, не имеют смысла в конкретной ситуации. Эксперты постоянно сталкиваются с уравновешиванием различных рисков и проблем в своем ремесле и часто должны использовать свое суждение, чтобы выбрать нарушение такого рода правил, балансируя различные факторы и не имея возможности просто полагаться на таблицу правил, которым нужно следовать. Возьмем, к примеру, Goto : ведутся долгие и повторяющиеся споры о том, вредны ли они. (Да, никогда не используйте gotos.; D)

Модальное предложение

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

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

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

если у вас нет возможности чтобы сказать, что это руководство неверно в конкретном случае, и доказать себе, что вы правы, тогда $ {RULE}

, где, конечно, вы могли бы заменить «никогда не анализировать ls output» из $ {RULE}. :)

Ах да! Что о Parsing ls Output?

Итак, учитывая все это ...Думаю, совершенно очевидно, что это правило хорошее. Прежде всего, настоящее правило должно пониматься как идиоматическое, как объяснено выше ...

Но, кроме того, дело не только в том, что вы должны хорошо разбираться в сценариях оболочки, чтобы знать, можно ли его нарушить в некоторых случаях. частный случай. Кроме того, требуется столько же навыков, чтобы сказать, что вы ошиблись , когда пытаетесь сломать его во время тестирования! И я уверенно заявляю, что очень большая часть вероятной аудитории таких статей (дающих советы вроде «Не анализируйте вывод ls !») не могут делать эти вещи , и те, кто обладает такими навыками, скорее всего, поймут, что они выяснят это самостоятельно, и все равно проигнорируют правило.

Но ... только посмотрите на этот вопрос, и как даже люди, которые, вероятно, действительно обладают навыками, думали, что это плохой призыв делать это; и сколько усилий потратил автор вопроса, чтобы добраться до точки текущего лучшего примера! Я гарантирую вам, что в решении такой сложной проблемы 99% людей ошибутся, и это даст потенциально очень плохие результаты! Даже если выбранный метод окажется удачным; пока эта (или другая) идея парсинга ls не будет принята ИТ-специалистами / разработчиками в целом, выдержит множество испытаний (особенно проверку временем) и, наконец, не сможет перейти к «общей методике» 'статус, вполне вероятно, что многие люди могут попробовать и ошибиться ... с катастрофическими последствиями.

Итак, я повторю еще раз ...что, особенно в этом случае , , что - вот почему « никогда не анализирует ls output!» это определенно правильный способ сформулировать это.

[ОБНОВЛЕНИЕ 2014-05-18: разъяснена причина ответа (см. Выше) для ответа на комментарий OP; следующее дополнение является ответом на добавления OP к вчерашнему вопросу]

[ОБНОВЛЕНИЕ 2014 -11-10:добавлены заголовки и реорганизован / переработан контент; а также: переформатирование, переформулировка, уточнение и эм ... "краткое уточнение" ... я хотел, чтобы это было просто очисткой, хотя это превратилось в небольшую переработку. Я оставил его в плачевном состоянии, поэтому в основном пытался навести порядок. я действительно чувствовал, что важно оставить первую секцию нетронутой; так что там только два незначительных изменения: лишнее «но» удалено и «то» подчеркнуто.]

† Изначально я задумал это исключительно как пояснение к моему оригиналу; но решил внести другие дополнения после размышлений

‡ см. https://unix.stackexchange.com/tour , чтобы ознакомиться с рекомендациями по сообщениям

0
23.11.2018, 05:47
3 ответа

Вот что я бы сделал:

UUID=1CAAFBA7AAFB7B98   /mnt/work   ntfs-3g  defaults,windows_names,locale=en_US.utf8  0 0

Эти настройки позволяют читать и записывать разделы/диски Windows NTFS при загрузке.

0
28.01.2020, 02:41

После некоторых расследований и просмотров я получил ответ.

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

2 )Если ваш FTBT находится в вашем домашнем каталоге, Thunar попытается переместить его в ~/.local/share/Trash. Если папка находится в другом разделе, операция завершится ошибкой.

3 )Если ваш FTBT находится в какой-то другой файловой системе (другой раздел, диск или монтирование nfs )Thunar попытается создать папку .Trash-$UIDв верхней папке файловой системы. У вас может не быть разрешений для этого, и операция завершится ошибкой.

Предположим, у вас есть второй диск, смонтированный в каталоге /disk2:

$ ls -ld /disk2
drwxr-xr-x 5 root root 4096 [some date] /disk2

А у вас естьUID 1000:

$ echo $UID
1000

Затем создайте папку для корзины:

$ sudo mkdir /disk2/.Trash-1000
$ sudo chown 1000 /disk2/.Trash-1000
$ chmod og-rwx /disk2/.Trash-1000

Thunar должен сделать остальную (структуру подкаталогов ), и ваша корзина должна работать.

Надеюсь, это поможет.

2
28.01.2020, 02:41

Немного покопавшись, я нашел ответ на свой вопрос. Я щелкнул значок своего общего раздела на боковой панели в Thunar, чтобы вызвать автоматическое монтирование, а затем нашел команду в process. параметры автоматического монтирования


/sbin/mount.ntfs /dev/sdb1 /mnt/work -o rw,nodev,nosuid,uid=1000,gid=1000,uhelper=udisks2

так что мой fstabвыглядит как:

UUID=1CAAFBA7AAFB7B98   /mnt/work   ntfs  rw,nodev,nosuid,uid=1000,gid=1000,uhelper=udisks2

Теперь я могу удалить свои файлы в корзину или Shift + удалить их навсегда, и разделы автоматически монтируются в нужную папку во время загрузки.

2
28.01.2020, 02:41

Теги

Похожие вопросы