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