KDE 4.10, при редактировании файлов заменяется их владелец

0

1

Это баг или фича? Обнаружил когда не смог отредактировать файлы с правами 664, владельцем которых я не являюсь, но вхожу в группу-владельа. У родительского каталога права 755.

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

Проявляется ли у вас это?

Ссылка

←	Не работает Ctrl+F!

openbox не видит исполняемых файлов

→

что в exports?

~~darkenshvein~~ ★★★★★
(18.02.13 20:55:27 MSK)

Ответ на: комментарий от darkenshvein 18.02.13 20:55:27 MSK

что в exports?

Не понял вопроса.
А, даркшвайн...

~~firestarter~~ ★★★☆
(18.02.13 20:57:42 MSK) автор топика
Последнее исправление: firestarter 18.02.13 20:58:11 MSK (всего исправлений: 1)

Ссылка

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

Предполагаю, что раньше файл открывали и писали прямо в него при сохранении. А теперь начали делать, как рекомендуется: сохранять в файл рядом, а потом переименовывать, стирая старый.

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

i-rinat ★★★★★
(18.02.13 22:56:45 MSK)

Ответ на: комментарий от i-rinat 18.02.13 22:56:45 MSK

А теперь начали делать, как рекомендуется

Кем рекомендуется? Ни один редактор так себя не ведёт.

а рядом создавать файлы нельзя. Тогда второй подход обломится.

Если очень так надо, временный файл можно создавать во временном каталоге. /tmp и /var/tmp/kdecache-$USER на что? В любом случае, это не повод менять владельца файла при редактировании (а он это делает теперь).

~~firestarter~~ ★★★☆
(18.02.13 23:09:47 MSK) автор топика

Ответ на: комментарий от firestarter 18.02.13 23:09:47 MSK

Ни один редактор так себя не ведёт.

vim по умолчанию ведёт себя именно так.

shell-script ★★★★★
(18.02.13 23:12:29 MSK)

Ответ на: комментарий от shell-script 18.02.13 23:12:29 MSK

vim по умолчанию ведёт себя именно так.

Как, прям заменяет владельца редактируемого файла?

~~firestarter~~ ★★★☆
(18.02.13 23:28:56 MSK) автор топика

Ответ на: комментарий от firestarter 18.02.13 23:09:47 MSK

Ни один редактор так себя не ведёт.

Плохо для кармы.

Если очень так надо, временный файл можно создавать во временном каталоге.

Нельзя, он должен быть на той же ФС.

В любом случае, это не повод менять владельца файла при редактировании (а он это делает теперь).

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

Так нужно для минимизации потерь данных при внезапном отключении. Журнал ФС даёт гарантии относительно целостности ФС, а не файлов в ней. Если посередине записи отключится питание, ты либо получишь испорченный файл, либо старую копию + часть новой. Ты какой вариант предпочитаешь?

i-rinat ★★★★★
(18.02.13 23:35:20 MSK)

Ответ на: комментарий от i-rinat 18.02.13 23:35:20 MSK

Нельзя, он должен быть на той же ФС.

Причина?

Если посередине записи отключится питание, ты либо получишь испорченный файл, либо старую копию + часть новой. Ты какой вариант предпочитаешь?

Ну и где тут причина создавать новый файл, а не перезаписывать существующий (во втором случае владелец будет сохранён)? Ничто же не мешает держать временный файл до завершения процесса перезаписи. Так оно видимо раньше и работало, во время правки файла рядом появлялся временный файл, который исчезал после сохранения изменений (проверил, сейчас так же, создаётся файл .имя_редакрируемого_файла.kate-swp). Но какие причины не перезаписывать файл просто?

~~firestarter~~ ★★★☆
(18.02.13 23:49:41 MSK) автор топика

Ответ на: комментарий от firestarter 18.02.13 23:49:41 MSK

Ну и где тут причина создавать новый файл, а не перезаписывать существующий

Первое либо — старое поведение, второе — новое. Ну так какое выбираешь?

i-rinat ★★★★★
(18.02.13 23:55:48 MSK)

Ответ на: комментарий от i-rinat 18.02.13 23:55:48 MSK

Первое либо — старое поведение, второе — новое. Ну так какое выбираешь?

Я выбираю вариант, когда файл просто перезаписывался, чтобы мне не приходилось лишний раз менять владельца после каждого редактирования. А теперь ещё и от рута придётся часто запускать редактор. Зачем вообще придуманы группы?

~~firestarter~~ ★★★☆
(19.02.13 00:04:32 MSK) автор топика

Ответ на: комментарий от firestarter 19.02.13 00:04:32 MSK

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

Ну тогда ищи патч и делай обратный. Вот так и появляются треды «<имя фс> портит файлы!».

i-rinat ★★★★★
(19.02.13 00:37:28 MSK)

Ответ на: комментарий от firestarter 18.02.13 23:28:56 MSK

Как, прям заменяет владельца редактируемого файла?

Нет. Создаёт в директории с редактируемым файлом временную копию.

shell-script ★★★★★
(19.02.13 00:45:37 MSK)

Ответ на: комментарий от shell-script 19.02.13 00:45:37 MSK

Нет. Создаёт в директории с редактируемым файлом временную копию.

Да причём здесь это, редактор стал заменять владельца файла. Это идиотизм.

~~firestarter~~ ★★★☆
(19.02.13 01:12:39 MSK) автор топика

Ответ на: комментарий от firestarter 19.02.13 01:12:39 MSK

Да причём здесь это, редактор стал заменять владельца файла. Это идиотизм.

ls -li

i-rinat ★★★★★
(19.02.13 01:14:49 MSK)

Ответ на: комментарий от i-rinat 19.02.13 00:37:28 MSK

Ну тогда ищи патч и делай обратный. Вот так и появляются треды «<имя фс> портит файлы!».

Делать нефиг, других редакторов полно, Geany, например. Не вижу связи каким образом смена владельца файла поможет спасти файл от сбоя ФС.

~~firestarter~~ ★★★☆
(19.02.13 01:14:50 MSK) автор топика

Ответ на: комментарий от i-rinat 19.02.13 01:14:49 MSK

ls -li

Да чё вы привязались своими инодами. Ничто не мешает писать в существующий файл, сохраняя изменения в отдельном файле, который можно удалить после успешной записи, как это делалось в предыдущей версии.

~~firestarter~~ ★★★☆
(19.02.13 01:19:19 MSK) автор топика

Ответ на: комментарий от firestarter 19.02.13 01:19:19 MSK

Ничто не мешает писать в существующий файл

Ничто не мешает выстрелить себе в ногу. Ты что правда не понимаешь, почему сохранение сделали так?

сохраняя изменения в отдельном файле, который можно удалить после успешной записи

Как это вообще возможно? Я не представляю, как в этом случае атомарность реализовать. Можешь пояснить свою мысль?

как это делалось в предыдущей версии.

Плохая версия стало быть была.

i-rinat ★★★★★
(19.02.13 01:25:26 MSK)

Ответ на: комментарий от i-rinat 19.02.13 01:25:26 MSK

Ничто не мешает выстрелить себе в ногу. Ты что правда не понимаешь, почему сохранение сделали так?

Потому что надо обязательно сделать чтобы пользователю было неудобно. Это линуксвей.

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

~~firestarter~~ ★★★☆
(19.02.13 01:34:59 MSK) автор топика
Последнее исправление: firestarter 19.02.13 01:37:04 MSK (всего исправлений: 1)

Ответ на: комментарий от firestarter 19.02.13 01:14:50 MSK

Geany

тоже так делает

i-rinat ★★★★★
(19.02.13 01:40:22 MSK)

Ответ на: комментарий от firestarter 19.02.13 01:34:59 MSK

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

Хм. И что, этого прям достаточно для восстановления?

По мне так атомарность предпочтительнее: либо файл старой версии, либо новой. Если не дописалась новая версия (софт упал или сбой питания), есть старая. Если дописалась, она заменяет старую атомарно.

Редактор может, конечно, хранить изменения, потом переписывать. Добавить ещё кучу костылей, которые будут следить за всеми файлами, а не являются они недописанными версиями? Поиск, запуск программ восстановления. Да, твой способ гораздо лучше. (Сарказм.)

i-rinat ★★★★★
(19.02.13 01:45:12 MSK)