[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150918180824.GE2213@vapier.lan>
Date: Fri, 18 Sep 2015 14:08:24 -0400
From: Mike Frysinger <vapier@...too.org>
To: Andreas Dilger <adilger@...ger.ca>
Cc: "linux-ext4@...r.kernel.org" <linux-ext4@...r.kernel.org>
Subject: Re: [PATCH e2fsprogs] subst: use 0644 perms
On 18 Sep 2015 10:52, Andreas Dilger wrote:
> On Sep 18, 2015, at 01:54, Mike Frysinger <vapier@...too.org> wrote:
> > When running on NFS, opening files with 0444 perms for writing can
> > sometimes fail. Since there's no real reason for these files to be
> > read-only, give the owner write permission.
>
> Actually, there IS a reason for subst to make these files read-only. They are auto-generated and any edits to these files can be overwritten and lost if their origin files are modified.
>
> I'd lost edits to these auto generated files many time because they are the ones that "tags" or "cscope" will jump to when searching for symbols.
>
> There really isn't any reason for them to be writable, so the fact that you are getting an error trying to open them for writing is a hint that you are doing, or going to do, the wrong thing and the read-only nature of the file is preventing you from going down the wrong path.
i think you misread my report. this has nothing to do with people trying
to modify the files after the fact. NFS can (and sometimes does) throw an
error at the time of the *open* call even if the file doesn't exist.
if you want to try to "protect" people, then it needs to be a chmod after
all the data has been written & closed. this is how it used to behave,
but commit 2873927d15ffb9ee9ed0e2700791a0e519c715aa changed it.
-mike
Download attachment "signature.asc" of type "application/pgp-signature" (820 bytes)
Powered by blists - more mailing lists