Hello,

Yesterday I came across a very weird behavior while annotating a pdf
file in Okular. Long story short: I opened a read-only pdf file
(permissions: 400), inserted some comments and hit the save button. At
this point, I thought I had been working on a write-enabled copy of
the file. After a while, I realized that I was actually working on the read-only version of the file, that somehow got saved to disk when I
hit the save icon. Okular was not only able to save the file to disk,
but the file permissions were changed to 644.

I initially thought this was an Okular problem. However, after some
more testing, I was able to reproduce the problem with Xournal. This
makes me think that the problem is not with Okular or Xournal, but
with some common library used by both of these packages (maybe
libpoppler?).

Has anybody had this problem? Can anybody reproduce it?

I'm using Debian testing.

Thanks a lot,

Adriano

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Il giorno sab 14 ago 2021 alle ore 15:39 Adriano Vilela Barbosa < adriano.vilela@gmail.com> ha scritto:

Hello,

Yesterday I came across a very weird behavior while annotating a pdf
file in Okular. Long story short: I opened a read-only pdf file
(permissions: 400), inserted some comments and hit the save button. At
this point, I thought I had been working on a write-enabled copy of
the file. After a while, I realized that I was actually working on the read-only version of the file, that somehow got saved to disk when I
hit the save icon. Okular was not only able to save the file to disk,
but the file permissions were changed to 644.

I initially thought this was an Okular problem. However, after some
more testing, I was able to reproduce the problem with Xournal. This
makes me think that the problem is not with Okular or Xournal, but
with some common library used by both of these packages (maybe
libpoppler?).

Has anybody had this problem? Can anybody reproduce it?

I'm using Debian testing.

Thanks a lot,

Adriano

Hi Adriano,
the read-only permission on the pdf file just prevents it's contents to be changed. It still can be deleted if the directory it belongs to is not
write protected.
Editor programs usually do not directly change the contents of a file but rather save them to a temporary new one (with default permissions), delete
the original and then rename the new file replacing the original one. I
don't know if Okular works this way, but I think it quite likely does.

Have a good release day!

Bruno

<div dir="ltr"><div dir="ltr"><div><div><div><div dir="ltr" class="gmail_attr">Il giorno sab 14 ago 2021 alle ore 15:39 Adriano Vilela Barbosa &lt;<a href="mailto:adriano.vilela@gmail.com">adriano.vilela@gmail.com</a>&gt; ha scritto:<br></div><blockquote
class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hello,<br>

Yesterday I came across a very weird behavior while annotating a pdf<br>
file in Okular. Long story short: I opened a read-only pdf file<br> (permissions: 400), inserted some comments and hit the save button. At<br>
this point, I thought I had been working on a write-enabled copy of<br>
the file. After a while, I realized that I was actually working on the<br> read-only version of the file, that somehow got saved to disk when I<br>
hit the save icon. Okular was not only able to save the file to disk,<br>
but the file permissions were changed to 644.<br>

I initially thought this was an Okular problem. However, after some<br>
more testing, I was able to reproduce the problem with Xournal. This<br>
makes me think that the problem is not with Okular or Xournal, but<br>
with some common library used by both of these packages (maybe<br> libpoppler?).<br>

Has anybody had this problem? Can anybody reproduce it?<br>

I&#39;m using Debian testing.<br>

Thanks a lot,<br>

Adriano<br>
</blockquote><br>Hi Adriano,<br></div>the read-only permission on the pdf file just prevents it&#39;s contents to be changed. It still can be deleted if the directory it belongs to is not write protected.<br></div>Editor programs usually do not directly
change the contents of a file but rather save them to a temporary new one (with default permissions), delete the original and then rename the new file replacing the original one. I don&#39;t know if Okular works this way, but I think it quite likely does.
<br><br></div><div>Have a good release day!<br></div><div><br></div>Bruno<br></div><br><div class="gmail_quote"><br></div></div>

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sat, 14 Aug 2021 at 12:54, bruno zanetti <bzanetti00@gmail.com> wrote:

Il giorno sab 14 ago 2021 alle ore 15:39 Adriano Vilela Barbosa <adriano.vilela@gmail.com> ha scritto:

Hello,

Yesterday I came across a very weird behavior while annotating a pdf
file in Okular. Long story short: I opened a read-only pdf file
(permissions: 400), inserted some comments and hit the save button. At
this point, I thought I had been working on a write-enabled copy of
the file. After a while, I realized that I was actually working on the
read-only version of the file, that somehow got saved to disk when I
hit the save icon. Okular was not only able to save the file to disk,
but the file permissions were changed to 644.

I initially thought this was an Okular problem. However, after some
more testing, I was able to reproduce the problem with Xournal. This
makes me think that the problem is not with Okular or Xournal, but
with some common library used by both of these packages (maybe
libpoppler?).

Has anybody had this problem? Can anybody reproduce it?

I'm using Debian testing.

Thanks a lot,

Adriano

Hi Adriano,
the read-only permission on the pdf file just prevents it's contents to be changed. It still can be deleted if the directory it belongs to is not write protected.
Editor programs usually do not directly change the contents of a file but rather save them to a temporary new one (with default permissions), delete the original and then rename the new file replacing the original one. I don't know if Okular works this

way, but I think it quite likely does.

Have a good release day!

Bruno

Hi Bruno,

Thanks for your reply.

Indeed, what you describe may be what's happening. If I change the
permissions of the directory where the file is to read-only, I get an
error message when trying to save the file. The error message says the
file could not be saved (error: access denied), and also says that it
could not write to file.pdf.part (this .part file must be temporary
file you mentioned).

I understand this mechanism, but I think this is quite controversial
and problematic. I mean, as an end user I don't care what the editor
is doing behind the scenes; it just shouldn't be able to modify a file
marked as read-only.

This is the first time I came across this behavior. No text editor I
ever used does this; LibreOffice doesn't do it either (rather, it
shows a message saying the document is open in read-only and shows an
"Edit Document" button, which allows you to edit the document and then
save it under a different name).

The question is: should I file a bug report somewhere? I really don't
want editors overwriting my read-only documents...

Thanks again,

Adriano

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 14.08.21 20:19, Adriano Vilela Barbosa wrote:

On Sat, 14 Aug 2021 at 12:54, bruno zanetti <bzanetti00@gmail.com> wrote:

Il giorno sab 14 ago 2021 alle ore 15:39 Adriano Vilela Barbosa <adriano.vilela@gmail.com> ha scritto:

Hello,

Yesterday I came across a very weird behavior while annotating a pdf
file in Okular. Long story short: I opened a read-only pdf file
(permissions: 400), inserted some comments and hit the save button. At
this point, I thought I had been working on a write-enabled copy of
the file. After a while, I realized that I was actually working on the
read-only version of the file, that somehow got saved to disk when I
hit the save icon. Okular was not only able to save the file to disk,
but the file permissions were changed to 644.

I initially thought this was an Okular problem. However, after some
more testing, I was able to reproduce the problem with Xournal. This
makes me think that the problem is not with Okular or Xournal, but
with some common library used by both of these packages (maybe
libpoppler?).

Has anybody had this problem? Can anybody reproduce it?

I'm using Debian testing.

Thanks a lot,

Adriano

Hi Adriano,
the read-only permission on the pdf file just prevents it's contents to be changed. It still can be deleted if the directory it belongs to is not write protected.
Editor programs usually do not directly change the contents of a file but rather save them to a temporary new one (with default permissions), delete the original and then rename the new file replacing the original one. I don't know if Okular works

this way, but I think it quite likely does.

Have a good release day!

Bruno

Hi Bruno,

Thanks for your reply.

Indeed, what you describe may be what's happening. If I change the permissions of the directory where the file is to read-only, I get an
error message when trying to save the file. The error message says the
file could not be saved (error: access denied), and also says that it
could not write to file.pdf.part (this .part file must be temporary
file you mentioned).

I understand this mechanism, but I think this is quite controversial
and problematic. I mean, as an end user I don't care what the editor
is doing behind the scenes; it just shouldn't be able to modify a file
marked as read-only.

This is the first time I came across this behavior. No text editor I
ever used does this; LibreOffice doesn't do it either (rather, it
shows a message saying the document is open in read-only and shows an
"Edit Document" button, which allows you to edit the document and then
save it under a different name).

The question is: should I file a bug report somewhere? I really don't
want editors overwriting my read-only documents...

Thanks again,

Adriano

Adriano, I am simply a user, not a developer. I fully agree with you and suggest to file a bug report. In 30 years computing I have never noticed
and assumed something like this, and although the explanation of Bruno
sounds reasonable, the behavior is not reasonable at all from the point
of view of a user! Until you and Bruno mentioned this behavior, I would
not even have expected this to be possible by the filesystem's policy
and initially reading your original post suspect this even to be a
filesystem bug! If data represented by a file name is marked read-only
on the filesystem level, then for this file name the data should not be replaceable. If this technically would be possible, like Bruno suspects
it, then this still doesn't make it right from the users point of view.

---
Just my thoughts!
Marco.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Il giorno sab 14 ago 2021 alle ore 20:20 Adriano Vilela Barbosa < adriano.vilela@gmail.com> ha scritto:

On Sat, 14 Aug 2021 at 12:54, bruno zanetti <bzanetti00@gmail.com> wrote:

Il giorno sab 14 ago 2021 alle ore 15:39 Adriano Vilela Barbosa <

adriano.vilela@gmail.com> ha scritto:

Hello,

Yesterday I came across a very weird behavior while annotating a pdf
file in Okular. Long story short: I opened a read-only pdf file
(permissions: 400), inserted some comments and hit the save button. At
this point, I thought I had been working on a write-enabled copy of
the file. After a while, I realized that I was actually working on the
read-only version of the file, that somehow got saved to disk when I
hit the save icon. Okular was not only able to save the file to disk,
but the file permissions were changed to 644.

I initially thought this was an Okular problem. However, after some
more testing, I was able to reproduce the problem with Xournal. This
makes me think that the problem is not with Okular or Xournal, but
with some common library used by both of these packages (maybe
libpoppler?).

Has anybody had this problem? Can anybody reproduce it?

I'm using Debian testing.

Thanks a lot,

Adriano

Hi Adriano,
the read-only permission on the pdf file just prevents it's contents to

be changed. It still can be deleted if the directory it belongs to is not write protected.

Editor programs usually do not directly change the contents of a file

but rather save them to a temporary new one (with default permissions), delete the original and then rename the new file replacing the original
one. I don't know if Okular works this way, but I think it quite likely
does.

Have a good release day!

Bruno

Hi Bruno,

Thanks for your reply.

Indeed, what you describe may be what's happening. If I change the permissions of the directory where the file is to read-only, I get an
error message when trying to save the file. The error message says the
file could not be saved (error: access denied), and also says that it
could not write to file.pdf.part (this .part file must be temporary
file you mentioned).

I understand this mechanism, but I think this is quite controversial
and problematic. I mean, as an end user I don't care what the editor
is doing behind the scenes; it just shouldn't be able to modify a file
marked as read-only.

This is the first time I came across this behavior. No text editor I
ever used does this; LibreOffice doesn't do it either (rather, it
shows a message saying the document is open in read-only and shows an
"Edit Document" button, which allows you to edit the document and then
save it under a different name).

The question is: should I file a bug report somewhere? I really don't
want editors overwriting my read-only documents...

Thanks again,

Adriano

Well, some editors take care of not overwriting read-only files, some
others (like kate, kwite) don't...
But I second your reasoning, the right behaviour IMHO would be to respect
the file permissions, regardless of the mechanism of the underlying
filesystem.
I'd suggest you report the issue on bugs.kde.org since it doesn't seem to
be a debian specific issue.

Best

Bruno

<div dir="ltr"><div dir="ltr"><div dir="ltr" class="gmail_attr">Il giorno sab 14 ago 2021 alle ore 20:20 Adriano Vilela Barbosa &lt;<a href="mailto:adriano.vilela@gmail.com" target="_blank">adriano.vilela@gmail.com</a>&gt; ha scritto:<br></div><
blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Sat, 14 Aug 2021 at 12:54, bruno zanetti &lt;<a href="mailto:bzanetti00@gmail.com" target="_blank">bzanetti00@gmail.com</a>&gt;
wrote:<br>
&gt;<br>
&gt; Il giorno sab 14 ago 2021 alle ore 15:39 Adriano Vilela Barbosa &lt;<a href="mailto:adriano.vilela@gmail.com" target="_blank">adriano.vilela@gmail.com</a>&gt; ha scritto:<br>
&gt;&gt;<br>
&gt;&gt; Hello,<br>
&gt;&gt;<br>
&gt;&gt; Yesterday I came across a very weird behavior while annotating a pdf<br>
&gt;&gt; file in Okular. Long story short: I opened a read-only pdf file<br> &gt;&gt; (permissions: 400), inserted some comments and hit the save button. At<br>
&gt;&gt; this point, I thought I had been working on a write-enabled copy of<br>
&gt;&gt; the file. After a while, I realized that I was actually working on the<br>
&gt;&gt; read-only version of the file, that somehow got saved to disk when I<br>
&gt;&gt; hit the save icon. Okular was not only able to save the file to disk,<br>
&gt;&gt; but the file permissions were changed to 644.<br>
&gt;&gt;<br>
&gt;&gt; I initially thought this was an Okular problem. However, after some<br>
&gt;&gt; more testing, I was able to reproduce the problem with Xournal. This<br>
&gt;&gt; makes me think that the problem is not with Okular or Xournal, but<br> &gt;&gt; with some common library used by both of these packages (maybe<br> &gt;&gt; libpoppler?).<br>
&gt;&gt;<br>
&gt;&gt; Has anybody had this problem? Can anybody reproduce it?<br> &gt;&gt;<br>
&gt;&gt; I&#39;m using Debian testing.<br>
&gt;&gt;<br>
&gt;&gt; Thanks a lot,<br>
&gt;&gt;<br>
&gt;&gt; Adriano<br>
&gt;<br>
&gt;<br>
&gt; Hi Adriano,<br>
&gt; the read-only permission on the pdf file just prevents it&#39;s
contents to be changed. It still can be deleted if the directory it
belongs to is not write protected.<br>
&gt; Editor programs usually do not directly change the contents of a
file but rather save them to a temporary new one (with default
permissions), delete the original and then rename the new file replacing
the original one. I don&#39;t know if Okular works this way, but I think it
quite likely does.<br>
&gt;<br>
&gt; Have a good release day!<br>
&gt;<br>
&gt; Bruno<br>
&gt;<br>
&gt;<br>

Hi Bruno,<br>

Thanks for your reply.<br>

Indeed, what you describe may be what&#39;s happening. If I change the<br> permissions of the directory where the file is to read-only, I get an<br>
error message when trying to save the file. The error message says the<br>
file could not be saved (error: access denied), and also says that it<br>
could not write to file.pdf.part (this .part file must be temporary<br>
file you mentioned).<br>

I understand this mechanism, but I think this is quite controversial<br>
and problematic. I mean, as an end user I don&#39;t care what the editor<br>
is doing behind the scenes; it just shouldn&#39;t be able to modify a file<br> marked as read-only.<br>

This is the first time I came across this behavior. No text editor I<br>
ever used does this; LibreOffice doesn&#39;t do it either (rather, it<br>
shows a message saying the document is open in read-only and shows an<br> &quot;Edit Document&quot; button, which allows you to edit the document and then<br>
save it under a different name).<br>

The question is: should I file a bug report somewhere? I really don&#39;t<br> want editors overwriting my read-only documents...<br>

Thanks again,<br>

Adriano</blockquote></div><br><div class="gmail_quote">Well, some editors take care of not overwriting read-only files, some others (like kate, kwite) don&#39;t...<br></div><div class="gmail_quote">But I second your reasoning, the right behaviour IMHO
would be to respect the file permissions, regardless of the mechanism of the underlying filesystem.<br></div><div class="gmail_quote">I&#39;d suggest you report the issue on <a href="http://bugs.kde.org" target="_blank">bugs.kde.org</a> since it doesn&#
39;t seem to be a debian specific issue.<br></div><div class="gmail_quote"><br></div><div class="gmail_quote">Best<br><br></div><div class="gmail_quote">Bruno<br></div><div class="gmail_quote"><br></div></div>

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Il giorno sab 14 ago 2021 alle ore 21:01 Marco Möller < talby@debianlists.mobilxpress.net> ha scritto:

On 14.08.21 20:19, Adriano Vilela Barbosa wrote:

On Sat, 14 Aug 2021 at 12:54, bruno zanetti <bzanetti00@gmail.com>

wrote:

Il giorno sab 14 ago 2021 alle ore 15:39 Adriano Vilela Barbosa < adriano.vilela@gmail.com> ha scritto:

Hello,

Yesterday I came across a very weird behavior while annotating a pdf
file in Okular. Long story short: I opened a read-only pdf file
(permissions: 400), inserted some comments and hit the save button. At >>> this point, I thought I had been working on a write-enabled copy of
the file. After a while, I realized that I was actually working on the >>> read-only version of the file, that somehow got saved to disk when I
hit the save icon. Okular was not only able to save the file to disk,
but the file permissions were changed to 644.

I initially thought this was an Okular problem. However, after some
more testing, I was able to reproduce the problem with Xournal. This
makes me think that the problem is not with Okular or Xournal, but
with some common library used by both of these packages (maybe
libpoppler?).

Has anybody had this problem? Can anybody reproduce it?

I'm using Debian testing.

Thanks a lot,

Adriano

Hi Adriano,
the read-only permission on the pdf file just prevents it's contents to

be changed. It still can be deleted if the directory it belongs to is not write protected.

Editor programs usually do not directly change the contents of a file

but rather save them to a temporary new one (with default permissions), delete the original and then rename the new file replacing the original
one. I don't know if Okular works this way, but I think it quite likely
does.

Have a good release day!

Bruno

Hi Bruno,

Thanks for your reply.

Indeed, what you describe may be what's happening. If I change the permissions of the directory where the file is to read-only, I get an
error message when trying to save the file. The error message says the
file could not be saved (error: access denied), and also says that it
could not write to file.pdf.part (this .part file must be temporary
file you mentioned).

I understand this mechanism, but I think this is quite controversial
and problematic. I mean, as an end user I don't care what the editor
is doing behind the scenes; it just shouldn't be able to modify a file marked as read-only.

This is the first time I came across this behavior. No text editor I
ever used does this; LibreOffice doesn't do it either (rather, it
shows a message saying the document is open in read-only and shows an
"Edit Document" button, which allows you to edit the document and then
save it under a different name).

The question is: should I file a bug report somewhere? I really don't
want editors overwriting my read-only documents...

Thanks again,

Adriano

Adriano, I am simply a user, not a developer. I fully agree with you and suggest to file a bug report. In 30 years computing I have never noticed
and assumed something like this, and although the explanation of Bruno
sounds reasonable, the behavior is not reasonable at all from the point
of view of a user! Until you and Bruno mentioned this behavior, I would
not even have expected this to be possible by the filesystem's policy
and initially reading your original post suspect this even to be a
filesystem bug! If data represented by a file name is marked read-only
on the filesystem level, then for this file name the data should not be replaceable. If this technically would be possible, like Bruno suspects
it, then this still doesn't make it right from the users point of view.

---
Just my thoughts!
Marco.

Another subtle effect to pay attention to is that saving that way a file
'a' hard-linked to a file 'b', it will break the link and only 'a' gets
updated because the original linked file is actually deleted! This
behaviour can be desired in some cases, but if it's not, it's quite hard to track down the reason.
Bye

Bruno

<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Il giorno sab 14 ago 2021 alle ore 21:01 Marco Möller &lt;<a href="mailto:talby@debianlists.mobilxpress.net">talby@debianlists.mobilxpress.net</a>&gt;
ha scritto:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 14.08.21 20:19, Adriano Vilela Barbosa wrote:<br>
&gt; On Sat, 14 Aug 2021 at 12:54, bruno zanetti &lt;<a href="mailto:bzanetti00@gmail.com" target="_blank">bzanetti00@gmail.com</a>&gt; wrote:<br>
&gt;&gt;<br>
&gt;&gt; Il giorno sab 14 ago 2021 alle ore 15:39 Adriano Vilela Barbosa &lt;<a href="mailto:adriano.vilela@gmail.com" target="_blank">adriano.vilela@gmail.com</a>&gt; ha scritto:<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; Hello,<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; Yesterday I came across a very weird behavior while annotating a pdf<br>
&gt;&gt;&gt; file in Okular. Long story short: I opened a read-only pdf file<br>
&gt;&gt;&gt; (permissions: 400), inserted some comments and hit the save button. At<br>
&gt;&gt;&gt; this point, I thought I had been working on a write-enabled copy of<br>
&gt;&gt;&gt; the file. After a while, I realized that I was actually working on the<br>
&gt;&gt;&gt; read-only version of the file, that somehow got saved to disk when I<br>
&gt;&gt;&gt; hit the save icon. Okular was not only able to save the file to disk,<br>
&gt;&gt;&gt; but the file permissions were changed to 644.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; I initially thought this was an Okular problem. However, after some<br>
&gt;&gt;&gt; more testing, I was able to reproduce the problem with Xournal. This<br>
&gt;&gt;&gt; makes me think that the problem is not with Okular or Xournal, but<br>
&gt;&gt;&gt; with some common library used by both of these packages (maybe<br> &gt;&gt;&gt; libpoppler?).<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; Has anybody had this problem? Can anybody reproduce it?<br> &gt;&gt;&gt;<br>
&gt;&gt;&gt; I&#39;m using Debian testing.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; Thanks a lot,<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; Adriano<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; Hi Adriano,<br>
&gt;&gt; the read-only permission on the pdf file just prevents it&#39;s contents to be changed. It still can be deleted if the directory it
belongs to is not write protected.<br>
&gt;&gt; Editor programs usually do not directly change the contents of a
file but rather save them to a temporary new one (with default
permissions), delete the original and then rename the new file replacing
the original one. I don&#39;t know if Okular works this way, but I think it
quite likely does.<br>
&gt;&gt;<br>
&gt;&gt; Have a good release day!<br>
&gt;&gt;<br>
&gt;&gt; Bruno<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt; <br>
&gt; Hi Bruno,<br>
&gt; <br>
&gt; Thanks for your reply.<br>
&gt; <br>
&gt; Indeed, what you describe may be what&#39;s happening. If I change the<br> &gt; permissions of the directory where the file is to read-only, I get an<br> &gt; error message when trying to save the file. The error message says the<br> &gt; file could not be saved (error: access denied), and also says that it<br> &gt; could not write to file.pdf.part (this .part file must be temporary<br> &gt; file you mentioned).<br>
&gt; <br>
&gt; I understand this mechanism, but I think this is quite controversial<br> &gt; and problematic. I mean, as an end user I don&#39;t care what the editor<br>
&gt; is doing behind the scenes; it just shouldn&#39;t be able to modify a file<br>
&gt; marked as read-only.<br>
&gt; <br>
&gt; This is the first time I came across this behavior. No text editor I<br> &gt; ever used does this; LibreOffice doesn&#39;t do it either (rather, it<br> &gt; shows a message saying the document is open in read-only and shows an<br> &gt; &quot;Edit Document&quot; button, which allows you to edit the document and then<br>
&gt; save it under a different name).<br>
&gt; <br>
&gt; The question is: should I file a bug report somewhere? I really don&#39;t<br>
&gt; want editors overwriting my read-only documents...<br>
&gt; <br>
&gt; Thanks again,<br>
&gt; <br>
&gt; Adriano<br>
&gt; <br>

Adriano, I am simply a user, not a developer. I fully agree with you and <br> suggest to file a bug report. In 30 years computing I have never noticed <br> and assumed something like this, and although the explanation of Bruno <br> sounds reasonable, the behavior is not reasonable at all from the point <br>
of view of a user! Until you and Bruno mentioned this behavior, I would <br> not even have expected this to be possible by the filesystem&#39;s policy <br> and initially reading your original post suspect this even to be a <br> filesystem bug! If data represented by a file name is marked read-only <br>
on the filesystem level, then for this file name the data should not be <br> replaceable. If this technically would be possible, like Bruno suspects <br> it, then this still doesn&#39;t make it right from the users point of view.<br>

---<br>
Just my thoughts!<br>
Marco.<br></blockquote><div><br></div><div>Another subtle effect to pay attention to is that saving that way a file &#39;a&#39; hard-linked to a file &#39;b&#39;, it will break the link and only &#39;a&#39; gets updated because the original linked file
is actually deleted! This behaviour can be desired in some cases, but if it&#39;s not, it&#39;s quite hard to track down the reason.<br></div><div>Bye<br><br></div><div>Bruno<br></div></div></div>

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sat, 14 Aug 2021 at 16:49, bruno zanetti <bzanetti00@gmail.com> wrote:

Il giorno sab 14 ago 2021 alle ore 20:20 Adriano Vilela Barbosa <adriano.vilela@gmail.com> ha scritto:

On Sat, 14 Aug 2021 at 12:54, bruno zanetti <bzanetti00@gmail.com> wrote:

Il giorno sab 14 ago 2021 alle ore 15:39 Adriano Vilela Barbosa <adriano.vilela@gmail.com> ha scritto:

Hello,

Yesterday I came across a very weird behavior while annotating a pdf
file in Okular. Long story short: I opened a read-only pdf file
(permissions: 400), inserted some comments and hit the save button. At
this point, I thought I had been working on a write-enabled copy of
the file. After a while, I realized that I was actually working on the
read-only version of the file, that somehow got saved to disk when I
hit the save icon. Okular was not only able to save the file to disk,
but the file permissions were changed to 644.

I initially thought this was an Okular problem. However, after some
more testing, I was able to reproduce the problem with Xournal. This
makes me think that the problem is not with Okular or Xournal, but
with some common library used by both of these packages (maybe
libpoppler?).

Has anybody had this problem? Can anybody reproduce it?

I'm using Debian testing.

Thanks a lot,

Adriano

Hi Adriano,
the read-only permission on the pdf file just prevents it's contents to be changed. It still can be deleted if the directory it belongs to is not write protected.
Editor programs usually do not directly change the contents of a file but rather save them to a temporary new one (with default permissions), delete the original and then rename the new file replacing the original one. I don't know if Okular works

this way, but I think it quite likely does.

Have a good release day!

Bruno

Hi Bruno,

Thanks for your reply.

Indeed, what you describe may be what's happening. If I change the
permissions of the directory where the file is to read-only, I get an
error message when trying to save the file. The error message says the
file could not be saved (error: access denied), and also says that it
could not write to file.pdf.part (this .part file must be temporary
file you mentioned).

I understand this mechanism, but I think this is quite controversial
and problematic. I mean, as an end user I don't care what the editor
is doing behind the scenes; it just shouldn't be able to modify a file
marked as read-only.

This is the first time I came across this behavior. No text editor I
ever used does this; LibreOffice doesn't do it either (rather, it
shows a message saying the document is open in read-only and shows an
"Edit Document" button, which allows you to edit the document and then
save it under a different name).

The question is: should I file a bug report somewhere? I really don't
want editors overwriting my read-only documents...

Thanks again,

Adriano

Well, some editors take care of not overwriting read-only files, some others (like kate, kwite) don't...
But I second your reasoning, the right behaviour IMHO would be to respect the file permissions, regardless of the mechanism of the underlying filesystem.
I'd suggest you report the issue on bugs.kde.org since it doesn't seem to be a debian specific issue.

Best

Bruno

Hi Bruno,

At least on my system (Debian Testing), I can't overwrite a read-only
file with either kwrite or kate.

I'm going to report a bug upstream and post the link here.

Adriano

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 14.08.21 20:19, Adriano Vilela Barbosa wrote:

On Sat, 14 Aug 2021 at 12:54, bruno zanetti <bzanetti00@gmail.com> wrote:

Il giorno sab 14 ago 2021 alle ore 15:39 Adriano Vilela Barbosa
<adriano.vilela@gmail.com> ha scritto:

Hello,

Yesterday I came across a very weird behavior while annotating a pdf
file in Okular. Long story short: I opened a read-only pdf file
(permissions: 400), inserted some comments and hit the save button. At
this point, I thought I had been working on a write-enabled copy of
the file. After a while, I realized that I was actually working on the
read-only version of the file, that somehow got saved to disk when I
hit the save icon. Okular was not only able to save the file to disk,
but the file permissions were changed to 644.

I initially thought this was an Okular problem. However, after some
more testing, I was able to reproduce the problem with Xournal. This
makes me think that the problem is not with Okular or Xournal, but
with some common library used by both of these packages (maybe
libpoppler?).

Has anybody had this problem? Can anybody reproduce it?

I'm using Debian testing.

Thanks a lot,

Adriano

Hi Adriano,
the read-only permission on the pdf file just prevents it's contents to be changed.
It still can be deleted if the directory it belongs to is not write protected.
Editor programs usually do not directly change the contents of a file but rather
save them to a temporary new one (with default permissions), delete the original
and then rename the new file replacing the original one. I don't know if Okular
works this way, but I think it quite likely does.

Have a good release day!

Bruno

Hi Bruno,

Thanks for your reply.

Indeed, what you describe may be what's happening. If I change the
permissions of the directory where the file is to read-only, I get an
error message when trying to save the file. The error message says the
file could not be saved (error: access denied), and also says that it
could not write to file.pdf.part (this .part file must be temporary
file you mentioned).

I understand this mechanism, but I think this is quite controversial
and problematic. I mean, as an end user I don't care what the editor
is doing behind the scenes; it just shouldn't be able to modify a file
marked as read-only.

This is the first time I came across this behavior. No text editor I
ever used does this; LibreOffice doesn't do it either (rather, it
shows a message saying the document is open in read-only and shows an
"Edit Document" button, which allows you to edit the document and then
save it under a different name).

The question is: should I file a bug report somewhere? I really don't
want editors overwriting my read-only documents...

Thanks again,

Adriano

Adriano, I am simply a user, not a developer. I fully agree with you and suggest to file a
bug report. In 30 years computing I have never noticed and assumed something like this, and
although the explanation of Bruno sounds reasonable, the behavior is not reasonable at all
from the point of view of a user! Until you and Bruno mentioned this behavior, I would not
even have expected this to be possible by the filesystem's policy and initially reading
your original post suspect this even to be a filesystem bug! If data represented by a file
name is marked read-only on the filesystem level, then for this file name the data should
not be replaceable. If this technically would be possible, like Bruno suspects it, then
this still doesn't make it right from the users point of view.

---
Just my thoughts!
Marco.

Hi Marco,

I totally agree with you. As I said, I also have never seen this
behavior before. However, if the mechanism described by Bruno is what
is actually happening (and I think it is, because of the error message
about the .part file I got when I changed the directory permissions),
I don't see how the file system could prevent that.

I'm going to file a bug report upstream.

Thanks,

Adriano

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Am Samstag, 14. August 2021, 15:21:47 CEST schrieb Adriano Vilela Barbosa:

Has anybody had this problem? Can anybody reproduce it?

I do not think this behavior is wrong.
As the owner of a file, in a folder with write access, I must of course be able
to edit this file.
Otherwise I wouldn't be able to change the authorizations.
Once set to read-only, it would be read-only forever.
And why should you write-protect your own files from yourself?

--
Gruß
Helge

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sat, 14 Aug 2021 at 18:05, Adriano Vilela Barbosa
<adriano.vilela@gmail.com> wrote:

On Sat, 14 Aug 2021 at 16:49, bruno zanetti <bzanetti00@gmail.com> wrote:

Il giorno sab 14 ago 2021 alle ore 20:20 Adriano Vilela Barbosa <adriano.vilela@gmail.com> ha scritto:

On Sat, 14 Aug 2021 at 12:54, bruno zanetti <bzanetti00@gmail.com> wrote: >> >

Il giorno sab 14 ago 2021 alle ore 15:39 Adriano Vilela Barbosa <adriano.vilela@gmail.com> ha scritto:

Hello,

Yesterday I came across a very weird behavior while annotating a pdf
file in Okular. Long story short: I opened a read-only pdf file
(permissions: 400), inserted some comments and hit the save button. At >> >> this point, I thought I had been working on a write-enabled copy of
the file. After a while, I realized that I was actually working on the >> >> read-only version of the file, that somehow got saved to disk when I
hit the save icon. Okular was not only able to save the file to disk, >> >> but the file permissions were changed to 644.

I initially thought this was an Okular problem. However, after some
more testing, I was able to reproduce the problem with Xournal. This
makes me think that the problem is not with Okular or Xournal, but
with some common library used by both of these packages (maybe
libpoppler?).

Has anybody had this problem? Can anybody reproduce it?

I'm using Debian testing.

Thanks a lot,

Adriano

Hi Adriano,
the read-only permission on the pdf file just prevents it's contents to be changed. It still can be deleted if the directory it belongs to is not write protected.
Editor programs usually do not directly change the contents of a file but rather save them to a temporary new one (with default permissions), delete the original and then rename the new file replacing the original one. I don't know if Okular works

this way, but I think it quite likely does.

Have a good release day!

Bruno

Hi Bruno,

Thanks for your reply.

Indeed, what you describe may be what's happening. If I change the
permissions of the directory where the file is to read-only, I get an
error message when trying to save the file. The error message says the
file could not be saved (error: access denied), and also says that it
could not write to file.pdf.part (this .part file must be temporary
file you mentioned).

I understand this mechanism, but I think this is quite controversial
and problematic. I mean, as an end user I don't care what the editor
is doing behind the scenes; it just shouldn't be able to modify a file
marked as read-only.

This is the first time I came across this behavior. No text editor I
ever used does this; LibreOffice doesn't do it either (rather, it
shows a message saying the document is open in read-only and shows an
"Edit Document" button, which allows you to edit the document and then
save it under a different name).

The question is: should I file a bug report somewhere? I really don't
want editors overwriting my read-only documents...

Thanks again,

Adriano

Well, some editors take care of not overwriting read-only files, some others (like kate, kwite) don't...
But I second your reasoning, the right behaviour IMHO would be to respect the file permissions, regardless of the mechanism of the underlying filesystem.
I'd suggest you report the issue on bugs.kde.org since it doesn't seem to be a debian specific issue.

Best

Bruno

Hi Bruno,

At least on my system (Debian Testing), I can't overwrite a read-only
file with either kwrite or kate.

I'm going to report a bug upstream and post the link here.

Adriano

Here's the bug report I filed:

https://bugs.kde.org/show_bug.cgi?id=440986

Adriano

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sonntag, 15. August 2021 00:04:18 CEST Helge Reimer wrote:

Am Samstag, 14. August 2021, 15:21:47 CEST schrieb Adriano Vilela Barbosa:

Has anybody had this problem? Can anybody reproduce it?

I do not think this behavior is wrong.
As the owner of a file, in a folder with write access, I must of course be able to edit this file.
Otherwise I wouldn't be able to change the authorizations.
Once set to read-only, it would be read-only forever.
And why should you write-protect your own files from yourself?

From the file system's perspective the behavior is not wrong. As you

said, the owner of a read-only file A is of course able to create a copy
B of that file, write the changed content into B, make B read-only, make
A writable and remove A.

However, an editor should never do this automatically! It should ask if
the user really wants to change the read-only file.

Write-protecting my own files makes sense to prevent automatic / accidental changes of these files.

Frank

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 15.08.21 00:06, Adriano Vilela Barbosa wrote:

On Sat, 14 Aug 2021 at 18:05, Adriano Vilela Barbosa <adriano.vilela@gmail.com> wrote:

On Sat, 14 Aug 2021 at 16:49, bruno zanetti <bzanetti00@gmail.com> wrote: >>>

Il giorno sab 14 ago 2021 alle ore 20:20 Adriano Vilela Barbosa <adriano.vilela@gmail.com> ha scritto:

On Sat, 14 Aug 2021 at 12:54, bruno zanetti <bzanetti00@gmail.com> wrote: >>>>>

Il giorno sab 14 ago 2021 alle ore 15:39 Adriano Vilela Barbosa <adriano.vilela@gmail.com> ha scritto:

Hello,

Yesterday I came across a very weird behavior while annotating a pdf >>>>>> file in Okular. Long story short: I opened a read-only pdf file
(permissions: 400), inserted some comments and hit the save button. At >>>>>> this point, I thought I had been working on a write-enabled copy of >>>>>> the file. After a while, I realized that I was actually working on the >>>>>> read-only version of the file, that somehow got saved to disk when I >>>>>> hit the save icon. Okular was not only able to save the file to disk, >>>>>> but the file permissions were changed to 644.

I initially thought this was an Okular problem. However, after some >>>>>> more testing, I was able to reproduce the problem with Xournal. This >>>>>> makes me think that the problem is not with Okular or Xournal, but >>>>>> with some common library used by both of these packages (maybe
libpoppler?).

Has anybody had this problem? Can anybody reproduce it?

I'm using Debian testing.

Thanks a lot,

Adriano

Hi Adriano,
the read-only permission on the pdf file just prevents it's contents to be changed. It still can be deleted if the directory it belongs to is not write protected.
Editor programs usually do not directly change the contents of a file but rather save them to a temporary new one (with default permissions), delete the original and then rename the new file replacing the original one. I don't know if Okular works

this way, but I think it quite likely does.

Have a good release day!

Bruno

Hi Bruno,

Thanks for your reply.

Indeed, what you describe may be what's happening. If I change the
permissions of the directory where the file is to read-only, I get an
error message when trying to save the file. The error message says the >>>> file could not be saved (error: access denied), and also says that it
could not write to file.pdf.part (this .part file must be temporary
file you mentioned).

I understand this mechanism, but I think this is quite controversial
and problematic. I mean, as an end user I don't care what the editor
is doing behind the scenes; it just shouldn't be able to modify a file >>>> marked as read-only.

This is the first time I came across this behavior. No text editor I
ever used does this; LibreOffice doesn't do it either (rather, it
shows a message saying the document is open in read-only and shows an
"Edit Document" button, which allows you to edit the document and then >>>> save it under a different name).

The question is: should I file a bug report somewhere? I really don't
want editors overwriting my read-only documents...

Thanks again,

Adriano

Well, some editors take care of not overwriting read-only files, some others (like kate, kwite) don't...
But I second your reasoning, the right behaviour IMHO would be to respect the file permissions, regardless of the mechanism of the underlying filesystem.
I'd suggest you report the issue on bugs.kde.org since it doesn't seem to be a debian specific issue.

Best

Bruno

Hi Bruno,

At least on my system (Debian Testing), I can't overwrite a read-only
file with either kwrite or kate.

I'm going to report a bug upstream and post the link here.

Adriano

Here's the bug report I filed:

https://bugs.kde.org/show_bug.cgi?id=440986

Adriano

I just saw that upstream it indeed was accepted to be a bug, became
discussed, and subsequently became solved. In the correct version there
will now be shown a message "File could not be saved in
[...location...]. Try to save it to another location."
It might take some time to see this corrected version to appear also in
Debian, but I think we have good reasons to assume that it will come.

Adriano, thanks a lot to have brought up this thread, I learned
important things from it, I did not imagine this "overwrite" to be
possible, but learned that in certain situation it indeed is possible by following the idea of first saving to a new file, then deleting the old
one, and finally renaming the new one back to the name of the former
file. The upstream discussion also mentions that some like this
"overwritten" file version then of course does not reflect the original
file attributes (and ACL) no more.

So, from now on I am aware about the risk, that a programm
implementation can decide to go for this pathway and by this working
around a filesystem based write protection which a user for safety might
have placed on a file, that filesystem flags are not as safe as I by now assumed them to be.

Thanks, and best wishes,
Marco

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Adriano Vilela Barbosa - 14.08.21, 20:19:38 CEST:

I understand this mechanism, but I think this is quite controversial
and problematic. I mean, as an end user I don't care what the editor
is doing behind the scenes; it just shouldn't be able to modify a file
marked as read-only.

Welcome to the world of Unix permissions. :)

Whether the application should take extra caution is another question. I
think for many applications it is a sane thing to give at least a hint
to the user.

This is the first time I came across this behavior. No text editor I
ever used does this; LibreOffice doesn't do it either (rather, it
shows a message saying the document is open in read-only and shows an
"Edit Document" button, which allows you to edit the document and then
save it under a different name).

vim for example sets read only mode and only saves with an "!" after the
write command.

I see you filed an upstream bug report. And it got resolved in upstream
version already. Thank you!

Best,
--
Martin

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)