You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Ivan Zhakov <ch...@gmail.com> on 2005/11/14 18:52:12 UTC
svn_io_file_rename preserves *destination* file permission on Windows
Hi, Brane and Devs!
Today we with Erik Huelsman tried to fix switch_tests.py 17 test
failing on Windows. After investigation we found very strange thing:
svn_io_file_rename preserves *destination* file permissions on
Windows. Please look to code (I have removed all #ifdef to improve
readabilty):
svn_error_t *
svn_io_file_rename (const char *from_path, const char *to_path,
apr_pool_t *pool)
{
apr_status_t status = APR_SUCCESS;
const char *from_path_apr, *to_path_apr;
/* Set the file writable but only on Windows, because Windows will
not allow us to rename files that are read-only. But preserve the
state of the read-only flag on the destination. */
svn_boolean_t was_read_only;
apr_finfo_t finfo;
SVN_ERR (svn_io_set_file_read_write (from_path, FALSE, pool));
SVN_ERR (svn_path_cstring_from_utf8 (&from_path_apr, from_path, pool));
SVN_ERR (svn_path_cstring_from_utf8 (&to_path_apr, to_path, pool));
status = apr_stat (&finfo, to_path_apr, APR_FINFO_PROT, pool);
if (APR_STATUS_IS_ENOENT (status))
{
was_read_only = FALSE;
status = APR_SUCCESS;
}
else if (!status)
{
/* Note: apr_stat doesn't look at just the read-only bit. It's
concievable that we get a positive result here because of
file permissions. But that shouldn't happen in a Subversion
working copy, and then set_read_write will fail, so the end
result is the same. */
was_read_only = !(finfo.protection
& (APR_UWRITE | APR_GWRITE | APR_WWRITE));
if (was_read_only)
SVN_ERR (svn_io_set_file_read_write (to_path, FALSE, pool));
}
if (!status)
{
status = apr_file_rename (from_path_apr, to_path_apr, pool);
WIN32_RETRY_LOOP (status,
apr_file_rename (from_path_apr, to_path_apr, pool));
}
if (status)
return svn_error_wrap_apr (status, _("Can't move '%s' to '%s'"),
svn_path_local_style (from_path, pool),
svn_path_local_style (to_path, pool));
if (was_read_only)
SVN_ERR (svn_io_set_file_read_only (to_path, FALSE, pool));
return SVN_NO_ERROR;
}
This behavior was added in r14304 by Brane for fix issue #2278. I
understand for what we clear destinition file's read-only.
On Linux mv doesn't preserves destination permisions, why we have
different behavior on Windows?
--
Ivan Zhakov
Re: svn_io_file_rename preserves *destination* file permission on Windows
Posted by Erik Huelsmann <eh...@gmail.com>.
On 11/15/05, Ivan Zhakov <ch...@gmail.com> wrote:
> On 11/15/05, Branko Čibej <br...@xbc.nu> wrote:
> > Ivan Zhakov wrote:
> >
> > >On 11/15/05, Erik Huelsmann <eh...@gmail.com> wrote:
> > >
> > >
> > >>On 11/15/05, Ivan Zhakov <ch...@gmail.com> wrote:
> > >>
> > >>
> > >>>On 11/15/05, Branko Čibej <br...@xbc.nu> wrote:
> > >>>
> > >>>
> > >>>>Erik Huelsmann wrote:
> > >>>>
> > >>>>
> > >>>>>So, I suppose I should be testing trunk on a windows box and see what
> > >>>>>happens if I change svn_io_file_rename...
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>Something bad, I'm pretty sure, or I wouldn't have made the original
> > >>>>commit. :)
> > >>>>
> > >>>>
> > >>>I have just removed setting destination read-only after rename and all
> > >>>tests passes on Windows (except propt_tests.py 16 which is failling
> > >>>before change).
> > >>>
> > >>>
> > >>Could you reduce svn_wc__prep_file_for_replacement to 'return
> > >>SVN_NO_ERROR;' and see if tests still pass? (Yes, with the changed
> > >>svn_io_file_rename please.)
> > >>
> > >>Before deciding to really rip that specific part of the code, it would
> > >>be good to find out if any tests were created to test for the
> > >>semantics Branko is referring to (not necessarily asking you to do
> > >>that though).
> > >>
> > >>
> > >All tests pass with no-op svn_wc__prep_file_for_replacement and
> > >changed svn_io_file_rename. What do you think about this?
> > >
> > >
> > Please donćt even consider ripping that code out before you're 100% sure
> > it's not needed (any more). I certainly didn't make those changes for
> > fun. They were needed at the time.
> Of course, I am understand that you changed it for something. I want
> get to know for what this done. For present time I haven't ideas.
Considering what brane and I discussed elsewhere in this thread, I
propose to fix the bug in svn_io_file_rename with the following patch.
Could you test and tell me what your findings are?
Thanks!
Log:
[[[
Fix issue #2306.
Note:
After applying this patch, svn_io_file_rename behaves the
same on Windows and Unix: overwrite readonly files while retaining
readonlyness on the source file.
* subversion/libsvn_subr/io.c
(svn_io_file_rename): Retain readonlyness on the *source* instead of
the target.
]]]
Index: subversion/libsvn_subr/io.c
===================================================================
--- subversion/libsvn_subr/io.c (revision 17362)
+++ subversion/libsvn_subr/io.c (working copy)
@@ -2484,14 +2484,14 @@
svn_boolean_t was_read_only;
apr_finfo_t finfo;
- SVN_ERR (svn_io_set_file_read_write (from_path, FALSE, pool));
+ SVN_ERR (svn_io_set_file_read_write (to_path, FALSE, pool));
#endif /* WIN32 */
SVN_ERR (svn_path_cstring_from_utf8 (&from_path_apr, from_path, pool));
SVN_ERR (svn_path_cstring_from_utf8 (&to_path_apr, to_path, pool));
#ifdef WIN32
- status = apr_stat (&finfo, to_path_apr, APR_FINFO_PROT, pool);
+ status = apr_stat (&finfo, from_path_apr, APR_FINFO_PROT, pool);
if (APR_STATUS_IS_ENOENT (status))
{
was_read_only = FALSE;
@@ -2507,7 +2507,7 @@
was_read_only = !(finfo.protection
& (APR_UWRITE | APR_GWRITE | APR_WWRITE));
if (was_read_only)
- SVN_ERR (svn_io_set_file_read_write (to_path, FALSE, pool));
+ SVN_ERR (svn_io_set_file_read_write (from_path, FALSE, pool));
}
#endif /* WIN32 */
Re: svn_io_file_rename preserves *destination* file permission on Windows
Posted by Ivan Zhakov <ch...@gmail.com>.
On 11/15/05, Branko Čibej <br...@xbc.nu> wrote:
> Ivan Zhakov wrote:
>
> >On 11/15/05, Erik Huelsmann <eh...@gmail.com> wrote:
> >
> >
> >>On 11/15/05, Ivan Zhakov <ch...@gmail.com> wrote:
> >>
> >>
> >>>On 11/15/05, Branko Čibej <br...@xbc.nu> wrote:
> >>>
> >>>
> >>>>Erik Huelsmann wrote:
> >>>>
> >>>>
> >>>>>So, I suppose I should be testing trunk on a windows box and see what
> >>>>>happens if I change svn_io_file_rename...
> >>>>>
> >>>>>
> >>>>>
> >>>>Something bad, I'm pretty sure, or I wouldn't have made the original
> >>>>commit. :)
> >>>>
> >>>>
> >>>I have just removed setting destination read-only after rename and all
> >>>tests passes on Windows (except propt_tests.py 16 which is failling
> >>>before change).
> >>>
> >>>
> >>Could you reduce svn_wc__prep_file_for_replacement to 'return
> >>SVN_NO_ERROR;' and see if tests still pass? (Yes, with the changed
> >>svn_io_file_rename please.)
> >>
> >>Before deciding to really rip that specific part of the code, it would
> >>be good to find out if any tests were created to test for the
> >>semantics Branko is referring to (not necessarily asking you to do
> >>that though).
> >>
> >>
> >All tests pass with no-op svn_wc__prep_file_for_replacement and
> >changed svn_io_file_rename. What do you think about this?
> >
> >
> Please donćt even consider ripping that code out before you're 100% sure
> it's not needed (any more). I certainly didn't make those changes for
> fun. They were needed at the time.
Of course, I am understand that you changed it for something. I want
get to know for what this done. For present time I haven't ideas.
--
Ivan Zhakov
Re: svn_io_file_rename preserves *destination* file permission on Windows
Posted by Erik Huelsmann <eh...@gmail.com>.
On 11/15/05, Branko Čibej <br...@xbc.nu> wrote:
> Erik Huelsmann wrote:
> >>> All tests pass with no-op svn_wc__prep_file_for_replacement and
> >>> changed svn_io_file_rename. What do you think about this?
> >>>
> >>>
> >>>
> >> Please don't even consider ripping that code out before you're 100% sure
> >> it's not needed (any more). I certainly didn't make those changes for
> >> fun. They were needed at the time.
> >>
> >
> > Oh, I know. I wasn't talking about ripping *all* af it, just the part
> > where it retains the read-only bit on the destination.
> >
> > If I consider that:
> > - svn:needs-lock was developed on *nix (linux, probably)
> > - in *nix it's possible to overwrite a read-only file
> > - unix retains the attributes on the file being renamed
> > - on Windows a file cannot be renamed if it or its rename-target is read-only
> > - svn_io_file_rename should behave the same on all platforms
> >
> > I think that the change should not be ripped out, but has a bug: If it
> > were to remove the readonly bit on both files and put back
> > read-onlyness *of the source* it behaves the same on both *nix and
> > windows (instead of the current situation where it does the same
> > thing, but uses the target atts).
> >
> Yes, I suspect that's a bug. However, I can't for the life of me
> remember my reasoning at the time. Oh, well.
The great thing is that if we consider that part a bug (which we do
now), we can remove the windows specific code from
svn_wc__prep_file_for_replace().
Heh. Well, I'll work with zhakov to make sure it's fixed and still passes tests.
Thanks for your time,
Erik.
Re: svn_io_file_rename preserves *destination* file permission on
Windows
Posted by Branko Čibej <br...@xbc.nu>.
Erik Huelsmann wrote:
>>> All tests pass with no-op svn_wc__prep_file_for_replacement and
>>> changed svn_io_file_rename. What do you think about this?
>>>
>>>
>>>
>> Please don't even consider ripping that code out before you're 100% sure
>> it's not needed (any more). I certainly didn't make those changes for
>> fun. They were needed at the time.
>>
>
> Oh, I know. I wasn't talking about ripping *all* af it, just the part
> where it retains the read-only bit on the destination.
>
> If I consider that:
> - svn:needs-lock was developed on *nix (linux, probably)
> - in *nix it's possible to overwrite a read-only file
> - unix retains the attributes on the file being renamed
> - on Windows a file cannot be renamed if it or its rename-target is read-only
> - svn_io_file_rename should behave the same on all platforms
>
> I think that the change should not be ripped out, but has a bug: If it
> were to remove the readonly bit on both files and put back
> read-onlyness *of the source* it behaves the same on both *nix and
> windows (instead of the current situation where it does the same
> thing, but uses the target atts).
>
Yes, I suspect that's a bug. However, I can't for the life of me
remember my reasoning at the time. Oh, well.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn_io_file_rename preserves *destination* file permission on
Windows
Posted by Branko Čibej <br...@xbc.nu>.
Ivan Zhakov wrote:
> On 11/16/05, Branko Čibej <br...@xbc.nu> wrote:
>
>> Ivan Zhakov wrote:
>>> nteresting note: Windows *allow* rename read-only files, but fail if
>>> target is read-only. Could anybody fix me? Brane, what do you think?
>> ikes. It looks like this is actually the case. If that's true, we'd
>> really only have to (optionally) make the destination read-write, and
>> really rip out the rest of the code...
>>
>> Wait a sec, let me try that. (I still can't remember why I looked at the
>> target's read-only-ness... possibly it had something to do with the
>> files in .svn, too, although I've no idea what...)
>>
> Sorry, I have already commited in r17366. So we need fix something after commit.
>
Yep, I saw your commit after I wrote that. It's more or less exactly
what I would've done. :)
I'm running tests on Windows now, and will run some manual tests to
double-check.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn_io_file_rename preserves *destination* file permission on Windows
Posted by Ivan Zhakov <ch...@gmail.com>.
On 11/16/05, Branko Čibej <br...@xbc.nu> wrote:
> Ivan Zhakov wrote:
> > On 11/15/05, Erik Huelsmann <eh...@gmail.com> wrote:
> >
> >>>> All tests pass with no-op svn_wc__prep_file_for_replacement and
> >>>> changed svn_io_file_rename. What do you think about this?
> >>>>
> >>>>
> >>>>
> >>> Please don't even consider ripping that code out before you're 100% sure
> >>> it's not needed (any more). I certainly didn't make those changes for
> >>> fun. They were needed at the time.
> >>>
> >> Oh, I know. I wasn't talking about ripping *all* af it, just the part
> >> where it retains the read-only bit on the destination.
> >>
> >> If I consider that:
> >> - svn:needs-lock was developed on *nix (linux, probably)
> >> - in *nix it's possible to overwrite a read-only file
> >> - unix retains the attributes on the file being renamed
> >> - on Windows a file cannot be renamed if it or its rename-target is read-only
> >>
> > Interesting note: Windows *allow* rename read-only files, but fail if
> > target is read-only. Could anybody fix me? Brane, what do you think?
> >
> Yikes. It looks like this is actually the case. If that's true, we'd
> really only have to (optionally) make the destination read-write, and
> really rip out the rest of the code...
>
> Wait a sec, let me try that. (I still can't remember why I looked at the
> target's read-only-ness... possibly it had something to do with the
> files in .svn, too, although I've no idea what...)
Sorry, I have already commited in r17366. So we need fix something after commit.
--
Ivan Zhakov
Re: svn_io_file_rename preserves *destination* file permission on
Windows
Posted by Branko Čibej <br...@xbc.nu>.
Ivan Zhakov wrote:
> On 11/15/05, Erik Huelsmann <eh...@gmail.com> wrote:
>
>>>> All tests pass with no-op svn_wc__prep_file_for_replacement and
>>>> changed svn_io_file_rename. What do you think about this?
>>>>
>>>>
>>>>
>>> Please don't even consider ripping that code out before you're 100% sure
>>> it's not needed (any more). I certainly didn't make those changes for
>>> fun. They were needed at the time.
>>>
>> Oh, I know. I wasn't talking about ripping *all* af it, just the part
>> where it retains the read-only bit on the destination.
>>
>> If I consider that:
>> - svn:needs-lock was developed on *nix (linux, probably)
>> - in *nix it's possible to overwrite a read-only file
>> - unix retains the attributes on the file being renamed
>> - on Windows a file cannot be renamed if it or its rename-target is read-only
>>
> Interesting note: Windows *allow* rename read-only files, but fail if
> target is read-only. Could anybody fix me? Brane, what do you think?
>
Yikes. It looks like this is actually the case. If that's true, we'd
really only have to (optionally) make the destination read-write, and
really rip out the rest of the code...
Wait a sec, let me try that. (I still can't remember why I looked at the
target's read-only-ness... possibly it had something to do with the
files in .svn, too, although I've no idea what...)
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn_io_file_rename preserves *destination* file permission on Windows
Posted by Ivan Zhakov <ch...@gmail.com>.
On 11/15/05, Erik Huelsmann <eh...@gmail.com> wrote:
> > >All tests pass with no-op svn_wc__prep_file_for_replacement and
> > >changed svn_io_file_rename. What do you think about this?
> > >
> > >
> > Please don't even consider ripping that code out before you're 100% sure
> > it's not needed (any more). I certainly didn't make those changes for
> > fun. They were needed at the time.
>
> Oh, I know. I wasn't talking about ripping *all* af it, just the part
> where it retains the read-only bit on the destination.
>
> If I consider that:
> - svn:needs-lock was developed on *nix (linux, probably)
> - in *nix it's possible to overwrite a read-only file
> - unix retains the attributes on the file being renamed
> - on Windows a file cannot be renamed if it or its rename-target is read-only
Interesting note: Windows *allow* rename read-only files, but fail if
target is read-only. Could anybody fix me? Brane, what do you think?
--
Ivan Zhakov
Re: svn_io_file_rename preserves *destination* file permission on Windows
Posted by Erik Huelsmann <eh...@gmail.com>.
On 11/15/05, Erik Huelsmann <eh...@gmail.com> wrote:
> > >All tests pass with no-op svn_wc__prep_file_for_replacement and
> > >changed svn_io_file_rename. What do you think about this?
> > >
> > >
> > Please don't even consider ripping that code out before you're 100% sure
> > it's not needed (any more). I certainly didn't make those changes for
> > fun. They were needed at the time.
>
> Oh, I know. I wasn't talking about ripping *all* af it, just the part
> where it retains the read-only bit on the destination.
>
> If I consider that:
> - svn:needs-lock was developed on *nix (linux, probably)
> - in *nix it's possible to overwrite a read-only file
> - unix retains the attributes on the file being renamed
> - on Windows a file cannot be renamed if it or its rename-target is read-only
> - svn_io_file_rename should behave the same on all platforms
>
> I think that the change should not be ripped out, but has a bug: If it
> were to remove the readonly bit on both files and put back
> read-onlyness *of the source* it behaves the same on both *nix and
> windows (instead of the current situation where it does the same
> thing, but uses the target atts).
BTW: Before sending the aforementioned reply, I searched the mailing
list and read the issue: nowhere does it say we need to retain
readonlyness on the target of the rename operation; it *does* say that
you can't rename a readonly file, or even rename another file over a
readonly file.
bye,
Erik.
Re: svn_io_file_rename preserves *destination* file permission on Windows
Posted by Erik Huelsmann <eh...@gmail.com>.
> >All tests pass with no-op svn_wc__prep_file_for_replacement and
> >changed svn_io_file_rename. What do you think about this?
> >
> >
> Please don't even consider ripping that code out before you're 100% sure
> it's not needed (any more). I certainly didn't make those changes for
> fun. They were needed at the time.
Oh, I know. I wasn't talking about ripping *all* af it, just the part
where it retains the read-only bit on the destination.
If I consider that:
- svn:needs-lock was developed on *nix (linux, probably)
- in *nix it's possible to overwrite a read-only file
- unix retains the attributes on the file being renamed
- on Windows a file cannot be renamed if it or its rename-target is read-only
- svn_io_file_rename should behave the same on all platforms
I think that the change should not be ripped out, but has a bug: If it
were to remove the readonly bit on both files and put back
read-onlyness *of the source* it behaves the same on both *nix and
windows (instead of the current situation where it does the same
thing, but uses the target atts).
bye,
Erik.
Re: svn_io_file_rename preserves *destination* file permission on
Windows
Posted by Branko Čibej <br...@xbc.nu>.
Ivan Zhakov wrote:
>On 11/15/05, Erik Huelsmann <eh...@gmail.com> wrote:
>
>
>>On 11/15/05, Ivan Zhakov <ch...@gmail.com> wrote:
>>
>>
>>>On 11/15/05, Branko Čibej <br...@xbc.nu> wrote:
>>>
>>>
>>>>Erik Huelsmann wrote:
>>>>
>>>>
>>>>>So, I suppose I should be testing trunk on a windows box and see what
>>>>>happens if I change svn_io_file_rename...
>>>>>
>>>>>
>>>>>
>>>>Something bad, I'm pretty sure, or I wouldn't have made the original
>>>>commit. :)
>>>>
>>>>
>>>I have just removed setting destination read-only after rename and all
>>>tests passes on Windows (except propt_tests.py 16 which is failling
>>>before change).
>>>
>>>
>>Could you reduce svn_wc__prep_file_for_replacement to 'return
>>SVN_NO_ERROR;' and see if tests still pass? (Yes, with the changed
>>svn_io_file_rename please.)
>>
>>Before deciding to really rip that specific part of the code, it would
>>be good to find out if any tests were created to test for the
>>semantics Branko is referring to (not necessarily asking you to do
>>that though).
>>
>>
>All tests pass with no-op svn_wc__prep_file_for_replacement and
>changed svn_io_file_rename. What do you think about this?
>
>
Please donćt even consider ripping that code out before you're 100% sure
it's not needed (any more). I certainly didn't make those changes for
fun. They were needed at the time.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn_io_file_rename preserves *destination* file permission on Windows
Posted by Ivan Zhakov <ch...@gmail.com>.
On 11/15/05, Erik Huelsmann <eh...@gmail.com> wrote:
> On 11/15/05, Ivan Zhakov <ch...@gmail.com> wrote:
> > On 11/15/05, Branko Čibej <br...@xbc.nu> wrote:
> > > Erik Huelsmann wrote:
> > > > So, I suppose I should be testing trunk on a windows box and see what
> > > > happens if I change svn_io_file_rename...
> > > >
> > > Something bad, I'm pretty sure, or I wouldn't have made the original
> > > commit. :)
> > I have just removed setting destination read-only after rename and all
> > tests passes on Windows (except propt_tests.py 16 which is failling
> > before change).
>
> Could you reduce svn_wc__prep_file_for_replacement to 'return
> SVN_NO_ERROR;' and see if tests still pass? (Yes, with the changed
> svn_io_file_rename please.)
>
> Before deciding to really rip that specific part of the code, it would
> be good to find out if any tests were created to test for the
> semantics Branko is referring to (not necessarily asking you to do
> that though).
All tests pass with no-op svn_wc__prep_file_for_replacement and
changed svn_io_file_rename. What do you think about this?
--
Ivan Zhakov
Re: svn_io_file_rename preserves *destination* file permission on Windows
Posted by Erik Huelsmann <eh...@gmail.com>.
On 11/15/05, Ivan Zhakov <ch...@gmail.com> wrote:
> On 11/15/05, Branko Čibej <br...@xbc.nu> wrote:
> > Erik Huelsmann wrote:
> > > So, I suppose I should be testing trunk on a windows box and see what
> > > happens if I change svn_io_file_rename...
> > >
> > Something bad, I'm pretty sure, or I wouldn't have made the original
> > commit. :)
> I have just removed setting destination read-only after rename and all
> tests passes on Windows (except propt_tests.py 16 which is failling
> before change).
Could you reduce svn_wc__prep_file_for_replacement to 'return
SVN_NO_ERROR;' and see if tests still pass? (Yes, with the changed
svn_io_file_rename please.)
Before deciding to really rip that specific part of the code, it would
be good to find out if any tests were created to test for the
semantics Branko is referring to (not necessarily asking you to do
that though).
bye,
Erik.
Re: svn_io_file_rename preserves *destination* file permission on Windows
Posted by Ivan Zhakov <ch...@gmail.com>.
On 11/15/05, Branko Čibej <br...@xbc.nu> wrote:
> Erik Huelsmann wrote:
> > So, I suppose I should be testing trunk on a windows box and see what
> > happens if I change svn_io_file_rename...
> >
> Something bad, I'm pretty sure, or I wouldn't have made the original
> commit. :)
I have just removed setting destination read-only after rename and all
tests passes on Windows (except propt_tests.py 16 which is failling
before change).
--
Ivan Zhakov
Re: svn_io_file_rename preserves *destination* file permission on
Windows
Posted by Branko Čibej <br...@xbc.nu>.
Erik Huelsmann wrote:
> So, I suppose I should be testing trunk on a windows box and see what
> happens if I change svn_io_file_rename...
>
Something bad, I'm pretty sure, or I wouldn't have made the original
commit. :)
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn_io_file_rename preserves *destination* file permission on Windows
Posted by Erik Huelsmann <eh...@gmail.com>.
On 11/14/05, Branko Čibej <br...@xbc.nu> wrote:
> Erik Huelsmann wrote:
> >> This behavior was added in r14304 by Brane for fix issue #2278. I
> >> understand for what we clear destinition file's read-only.
> >> On Linux mv doesn't preserves destination permisions, why we have
> >> different behavior on Windows?
> >>
> >
> > To jump in:
> >
> > On unix, you can rename over a read-only file. The *source*
> > permissions in this operation are preserved (and -ofcourse- attached
> > to the destination after the rename).
> >
> First let me point out that there is a big difference between the
> read-only flag and file permissions on Windows.
>
> As far as I can remember, this change was made in order to preserve
> svn:needs-lock semantics during update in the Windows working copy. It's
> possible that it would work just as well if was_read_only was read off
> the source, not the target; I certainly wouldn't want to blindly change
> things.
> I think that, if you trace back through the update sequence, you'll find
> that when replacing a file's contents in the working copy, the temporary
> file (i.e., before svn_io_file_rename is called) will have the same
> read-only state as the target file.
On unix, we set the read-only property after moving the file into
place. Also, the source doesn't have the read-only state - neither on
windows nor on unix. That's due to the fact that every translated file
is recreated from scratch (on windows that means w/o readonly attr).
So, I suppose I should be testing trunk on a windows box and see what
happens if I change svn_io_file_rename...
Thanks for the info!
bye,
Erik.
Re: svn_io_file_rename preserves *destination* file permission on
Windows
Posted by Branko Čibej <br...@xbc.nu>.
Erik Huelsmann wrote:
>> This behavior was added in r14304 by Brane for fix issue #2278. I
>> understand for what we clear destinition file's read-only.
>> On Linux mv doesn't preserves destination permisions, why we have
>> different behavior on Windows?
>>
>
> To jump in:
>
> On unix, you can rename over a read-only file. The *source*
> permissions in this operation are preserved (and -ofcourse- attached
> to the destination after the rename).
>
First let me point out that there is a big difference between the
read-only flag and file permissions on Windows.
As far as I can remember, this change was made in order to preserve
svn:needs-lock semantics during update in the Windows working copy. It's
possible that it would work just as well if was_read_only was read off
the source, not the target; I certainly wouldn't want to blindly change
things.
I think that, if you trace back through the update sequence, you'll find
that when replacing a file's contents in the working copy, the temporary
file (i.e., before svn_io_file_rename is called) will have the same
read-only state as the target file.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn_io_file_rename preserves *destination* file permission on Windows
Posted by Erik Huelsmann <eh...@gmail.com>.
> This behavior was added in r14304 by Brane for fix issue #2278. I
> understand for what we clear destinition file's read-only.
> On Linux mv doesn't preserves destination permisions, why we have
> different behavior on Windows?
To jump in:
On unix, you can rename over a read-only file. The *source*
permissions in this operation are preserved (and -ofcourse- attached
to the destination after the rename).
bye,
Erik.