Re: [PATCH] Make working copies read-only.

On Fri, Nov 30, 2001 at 10:14:53AM -0500, Greg Hudson wrote:
> On Fri, 2001-11-30 at 09:02, Kevin Pilch-Bisson wrote:
> > > > Also even if we didn't we wind up with a read-only file in the working copy.
>
> We should only wind up with a read-only file in the working copy if we
> open it read-only when we create it or set it read-only afterwards.
We don't create it here, we copy it from .svn.
> We're doing the copy here; we can open the target file with whatever
> mode we want. If svn_io_copy_file() or apr_copy_file() does the wrong
> thing for this purpose, then we should make it more flexible or create a
> variant; playing games with umask to compensate is going in the wrong
> direction.

That's a distinct possibility, and I think what Karl suggested, and I said
I would try and come up with a patch for.
>
> > I'm afraid we might run into problems when try to mv over files in text-base
> > from tmp/text-base, since text-base will be read-only. This would
> > mean we would need to stat the file, make it writable, mv the file,
> > then set it back to its original perms.
>
> There is no problem moving a non-writable file. The only permissions
> issues for moving are on the source and target directories.
>
kevin@pilchie:~ [571]$ ll -d .
drwxr-xr-x 38 kevin users 4.1k Nov 30 10:17 ./
kevin@pilchie:~ [572]$ touch A B
kevin@pilchie:~ [573]$ ll A B
-rw------- 1 kevin users 0 Nov 30 10:18 A
-rw------- 1 kevin users 0 Nov 30 10:18 B
kevin@pilchie:~ [574]$ chmod a-w B
kevin@pilchie:~ [575]$ ll A B
-rw------- 1 kevin users 0 Nov 30 10:18 A
-r-------- 1 kevin users 0 Nov 30 10:18 B
kevin@pilchie:~ [576]$ cp A B
cp: cannot create regular file `B': Permission denied
kevin@pilchie:~ [577]$

The same thing happens with copies too. It may be possible with the rename()
system call, but it won't be with the way apr_copy_file is implemented.
>
> > 1) Put mutexes around the umask calls, AND all calls to open where O_CREAT are
> > specified, or
> >
> > 2) Have apr record the umask before any threads are running, and use that for
> > get operations, and have set record the new value and set the umask.
> >
> >
> > I'm open to either, but I thought that approach 2) causes a fixed amount of
> > memory increase (4bytes), in an apr app, whereas 1) introduces a run-time
> > overhead everytime a file is opened.
>
> Option 2 does, however, impose overhead on all APR applications, even if
> they don't do anything with the umask. So I don't really know. It
> seems sad that Unix doesn't provide a way to get the umask
> nondestructively. Hopefully, though, I'm right above, and we don't need
> to ever get the umask.

Agreed about the overhead, but I don't think a single call to umask, two
functions and a 4 byte variable is a too much.

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Kevin Pilch-Bisson                    http://www.pilch-bisson.net
     "Historically speaking, the presences of wheels in Unix
     has never precluded their reinvention." - Larry Wall
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~