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'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.
> 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.
> 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.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:36:50 2006