On Sat, 14 Aug 2021 at 16:49, bruno zanetti <bzanett...@gmail.com> wrote: > > Il giorno sab 14 ago 2021 alle ore 20:20 Adriano Vilela Barbosa > <adriano.vil...@gmail.com> ha scritto: >> >> On Sat, 14 Aug 2021 at 12:54, bruno zanetti <bzanett...@gmail.com> wrote: >> > >> > Il giorno sab 14 ago 2021 alle ore 15:39 Adriano Vilela Barbosa >> > <adriano.vil...@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
