ERROR can't move *.svn-work to *.svn-base: access is denied

[Tobias Oetiker-3]

Hi,

Since upgrading to 1.5.5.14361 we  are experiencing a strange
problem

In a checkout (upgraded from svn 1.4) when adding/committing a
folder and then adding/committing a new file in this folder,
tortoise breaks and reacts as follows.

any ideas ?

cheers
tobi


22.12.2008 - 14:22:40
Command              : Commit
Adding               : \\Johan\susanne\checkouts\oep-contracts\spon-oss.oetiker.ch\c9465-hitflip\test
Completed            : At revision: 3534

22.12.2008 - 14:22:46
Command              : Update
Completed            : At revision: 3534

22.12.2008 - 14:23:35
Command              : Add
Added                : \\Johan\susanne\checkouts\oep-contracts\spon-oss.oetiker.ch\c9465-hitflip\test\New Microsoft Word-Dokument.doc
Finished!            :

22.12.2008 - 14:23:55
Command              : Commit
Adding               : \\Johan\susanne\checkouts\oep-contracts\spon-oss.oetiker.ch\c9465-hitflip\test\New Microsoft Word-Dokument.doc
Sending content      : \\Johan\susanne\checkouts\oep-contracts\spon-oss.oetiker.ch\c9465-hitflip\test\New Microsoft Word-Dokument.doc
Error                : Commit succeeded, but other errors follow:
Error                : Error bumping revisions post-commit (details follow):
Error                : In directory '\\Johan\susanne\checkouts\oep-contracts\spon-oss.oetiker.ch\c9465-hitflip\test'
Error                : Error processing command 'committed' in '\\Johan\susanne\checkouts\oep-contracts\spon-oss.oetiker.ch\c9465-hitflip\test': Can't move
Error                : '\\Johan\susanne\checkouts\oep-contracts\spon-oss.oetiker.ch\c9465-hitflip\test\.svn\props\New Microsoft Word-Dokument.doc.svn-work' to
Error                : '\\Johan\susanne\checkouts\oep-contracts\spon-oss.oetiker.ch\c9465-hitflip\test\.svn\prop-base\New Microsoft Word-Dokument.doc.svn-base': Access is denied.
Finished!            :

--
Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland
http://it.oetiker.ch [hidden email] ++41 62 775 9902 / sb: -9900

------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=989766

To unsubscribe from this discussion, e-mail: [[hidden email]].

[Stefan Küng]

Tobias Oetiker wrote:

> Hi,
>
> Since upgrading to 1.5.5.14361 we  are experiencing a strange
> problem
>
> In a checkout (upgraded from svn 1.4) when adding/committing a
> folder and then adding/committing a new file in this folder,
> tortoise breaks and reacts as follows.
>
> any ideas ?

Looks like a permission problem:
http://tortoisesvn.tigris.org/faq.html#samba

Stefan

--
       ___
  oo  // \\      "De Chelonian Mobile"
 (_,\/ \_/ \     TortoiseSVN
   \ \_/_\_/>    The coolest Interface to (Sub)Version Control
   /_/   \_\     http://tortoisesvn.net

------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=989775

To unsubscribe from this discussion, e-mail: [[hidden email]].

[Tobias Oetiker-3]

Hi Stefan,

thanks will try ...

In the mean time I read that the virus scanner could be
interfearing too (some how) so I have tuned it down to not touch
'non problemeatic' extensions and this seems to have helped to the
extent that I have not yet managed to recreate the problem ...

after running svn cleanup on the unix side things seem to run
smoothly.

it may be that with the samba setting suggested in the FAQ the
cleanup may have worked too.

thanks for the quick response
cheers
tobi



Today Stefan Kueng wrote:

> Tobias Oetiker wrote:
> > Hi,
> >
> > Since upgrading to 1.5.5.14361 we  are experiencing a strange
> > problem
> >
> > In a checkout (upgraded from svn 1.4) when adding/committing a
> > folder and then adding/committing a new file in this folder,
> > tortoise breaks and reacts as follows.
> >
> > any ideas ?
>
> Looks like a permission problem:
> http://tortoisesvn.tigris.org/faq.html#samba
>
> Stefan
>
>

--
Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland
http://it.oetiker.ch [hidden email] ++41 62 775 9902 / sb: -9900

------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=989781

To unsubscribe from this discussion, e-mail: [[hidden email]].

[theotheu]

Had success with the following actions:

-1. Removed the repository, both files and hidden directory (rm -fr *
AND (!) rm fr .* for .svn directory).
-2. Perfomed a full checkout with svn co <url> </path/to/repos>

Dit not modify smb.conf, updated to samba 3.2.3



On 22 dec 2008, 15:10, Tobias Oetiker <[hidden email]> wrote:

> Hi Stefan,
>
> thanks will try ...
>
> In the mean time I read that the virus scanner could be
> interfearing too (some how) so I have tuned it down to not touch
> 'non problemeatic' extensions and this seems to have helped to the
> extent that I have not yet managed to recreate the problem ...
>
> after running svn cleanup on the unix side things seem to run
> smoothly.
>
> it may be that with the samba setting suggested in the FAQ the
> cleanup may have worked too.
>
> thanks for the quick response
> cheers
> tobi
>
>
>
> Today Stefan Kueng wrote:
> > Tobias Oetiker wrote:
> > > Hi,
>
> > > Since upgrading to 1.5.5.14361 we  are experiencing a strange
> > > problem
>
> > > In a checkout (upgraded from svn 1.4) when adding/committing a
> > > folder and then adding/committing a new file in this folder,
> > > tortoise breaks and reacts as follows.
>
> > > any ideas ?
>
> > Looks like a permission problem:
> >http://tortoisesvn.tigris.org/faq.html#samba
>
> > Stefan
>
> --
> Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerlandhttp://[hidden email] ++41 62 775 9902 / sb: -9900
>
> ------------------------------------------------------http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMess...
>
> To unsubscribe from this discussion, e-mail: [[hidden email]].

------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=1008341

To unsubscribe from this discussion, e-mail: [[hidden email]].

[Jon Kloske]

Sorry, but I don't understand how this is a samba bug - can someone clarify?

TortoiseSVN is setting readonly on a file or directory or something, and then trying to delete/move/whatever that file or directory and then is complaining that samba won't let them?

Isn't that the correct behavior? Surely if tortoise wants to play with that file, it should unset the readonly bit first?

I've no idea how "upgrading to the latest samba" is supposed to fix this - I'd love to see what changes they put in to allow TortoiseSVN to delete readonly files...

As for turning on delete readonly = yes - this is not the default behavior and in fact samba recommends you leaving this setting alone since it can break some stuff that relies on this behavior (which is the dos/windows default, and unix default and in fact everything default ever, so why does Tortoise require you to break this?)

Either someone needs to explain this in more detail so we don't think that TortoiseSVN developers are dodging the fact they broke something that can be worked around by breaking Samba, or if this truly is a bug (like, it worked in 1.4, so what did you change to break this?) assign a ticket to it and get someone to fix it.

Not all of us have the luxury of being able to switch on a feature recommended against on our file servers - they are used by a lot of other people for a lot of other things and turning this on could break the fileserver from the point of view of a lot of other people.

TortoiseSVN should work regardless of the setting of delete readonly.

------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2358641

To unsubscribe from this discussion, e-mail: [[hidden email]].

[Simon Large-5]

2009/6/2 Jon Kloske <[hidden email]>:
> Sorry, but I don't understand how this is a samba bug - can someone clarify?
>
> TortoiseSVN is setting readonly on a file or directory or something, and then trying to delete/move/whatever that file or directory and then is complaining that samba won't let them?
>
> Isn't that the correct behavior? Surely if tortoise wants to play with that file, it should unset the readonly bit first?

TortoiseSVN doesn't do anything with the files, it is the subversion
library which does that. If you want a detailed explanation you need
to ask on the subversion mailing list. But network shares have been
problematic for a long time because of the limited set of locking
operations that they support.

> I've no idea how "upgrading to the latest samba" is supposed to fix this - I'd love to see what changes they put in to allow TortoiseSVN to delete readonly files...
>
> As for turning on delete readonly = yes - this is not the default behavior and in fact samba recommends you leaving this setting alone since it can break some stuff that relies on this behavior (which is the dos/windows default, and unix default and in fact everything default ever, so why does Tortoise require you to break this?)
>

I believe the delete readonly=yes setting is a temporary workaround
for a bug in SAMBA. In later SAMBA versions it probably isn't needed.

> Either someone needs to explain this in more detail so we don't think that TortoiseSVN developers are dodging the fact they broke something that can be worked around by breaking Samba, or if this truly is a bug (like, it worked in 1.4, so what did you change to break this?) assign a ticket to it and get someone to fix it.

The behaviour of the subversion library changed in 1.5. Something
along the lines of simplifying the code to use standard file access
APIs and less kludges.

> Not all of us have the luxury of being able to switch on a feature recommended against on our file servers - they are used by a lot of other people for a lot of other things and turning this on could break the fileserver from the point of view of a lot of other people.
>
> TortoiseSVN should work regardless of the setting of delete readonly.

Not if the filesystem itself is buggy.

Simon

--
:       ___
:  oo  // \\      "De Chelonian Mobile"
: (_,\/ \_/ \     TortoiseSVN
:   \ \_/_\_/>    The coolest Interface to (Sub)Version Control
:   /_/   \_\     http://tortoisesvn.net

------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2358689

To unsubscribe from this discussion, e-mail: [[hidden email]].

[Tobias Rapp]

Simon Large wrote:
> I believe the delete readonly=yes setting is a temporary workaround
> for a bug in SAMBA. In later SAMBA versions it probably isn't needed.

Does anybody know which samba version has this bug fixed? I had a look at the FAQ (http://tortoisesvn.tigris.org/faq.html#samba) but also no versions are mentioned there.

In my case I have tried both workarounds mentioned in the FAQ without success. Sometimes in my case it helps to remove the read-only property recursively on the base folder of the working copy followed by a SVN clean-up. Most of the time this also doesn't work and I have to do an in-place export and a fresh checkout then.

> The behaviour of the subversion library changed in 1.5. Something
> along the lines of simplifying the code to use standard file access
> APIs and less kludges.

Another example of developers rating code beauty over user experience :-(

/Tobias

------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2362692

To unsubscribe from this discussion, e-mail: [[hidden email]].

[Andy Levy]

On Wed, Jun 17, 2009 at 03:04, Tobias Rapp<[hidden email]> wrote:

> Simon Large wrote:
>> I believe the delete readonly=yes setting is a temporary workaround
>> for a bug in SAMBA. In later SAMBA versions it probably isn't needed.
>
> Does anybody know which samba version has this bug fixed? I had a look at the FAQ (http://tortoisesvn.tigris.org/faq.html#samba) but also no versions are mentioned there.
>
> In my case I have tried both workarounds mentioned in the FAQ without success. Sometimes in my case it helps to remove the read-only property recursively on the base folder of the working copy followed by a SVN clean-up. Most of the time this also doesn't work and I have to do an in-place export and a fresh checkout then.
>
>> The behaviour of the subversion library changed in 1.5. Something
>> along the lines of simplifying the code to use standard file access
>> APIs and less kludges.
>
> Another example of developers rating code beauty over user experience :-(

This isn't about "code beauty." Kludges are bad. Using standard APIs
is good. Overall, it's a net gain because things are now being done
properly, even if that means exposing bugs in other software. At the
end of the day, everyone benefits.

------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2362788

To unsubscribe from this discussion, e-mail: [[hidden email]].

[Simon Large-5]

2009/6/17 Tobias Rapp <[hidden email]>:
> Simon Large wrote:
>> I believe the delete readonly=yes setting is a temporary workaround
>> for a bug in SAMBA. In later SAMBA versions it probably isn't needed.
>
> Does anybody know which samba version has this bug fixed? I had a look at the FAQ (http://tortoisesvn.tigris.org/faq.html#samba) but also no versions are mentioned there.
>
> In my case I have tried both workarounds mentioned in the FAQ without success. Sometimes in my case it helps to remove the read-only property recursively on the base folder of the working copy followed by a SVN clean-up. Most of the time this also doesn't work and I have to do an in-place export and a fresh checkout then.

Open a DOS console, cd to your samba share.
The type

ATTRIB +R +S +H filethatexists

if you get no error, type
ATTRIB filethatexists
and check that it says
ARSH path\to\filethatexists

If it doesn't, then you have to tweak your samba settings until that works.

I have seen another post which conflicts with the information in our
FAQ and suggests force create mode = 0774

Please let us know if you find something that helps.

Simon

--
:       ___
:  oo  // \\      "De Chelonian Mobile"
: (_,\/ \_/ \     TortoiseSVN
:   \ \_/_\_/>    The coolest Interface to (Sub)Version Control
:   /_/   \_\     http://tortoisesvn.net

------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2362801

To unsubscribe from this discussion, e-mail: [[hidden email]].

[Tobias Rapp]

Simon Large wrote:

> Open a DOS console, cd to your samba share.
> The type
>
> ATTRIB +R +S +H filethatexists
>
> if you get no error, type
> ATTRIB filethatexists
> and check that it says
> ARSH path\to\filethatexists
>
> If it doesn't, then you have to tweak your samba settings until that works.

This worked without problems.

> I have seen another post which conflicts with the information in our
> FAQ and suggests force create mode = 0774
>
> Please let us know if you find something that helps.

I will test if there are still errors on commit when I use this setting.
Thanks for the suggestion. Just for the records: My Samba version is
"3.0.28a" (as available on Ubuntu 8.04).

Regards,
Tobias

------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2363077

To unsubscribe from this discussion, e-mail: [[hidden email]].

[Simon Large-5]

2009/6/18 Tobias Rapp <[hidden email]>:

> Simon Large wrote:
>> Open a DOS console, cd to your samba share.
>> The type
>>
>> ATTRIB +R +S +H filethatexists
>>
>> if you get no error, type
>> ATTRIB filethatexists
>> and check that it says
>> ARSH path\to\filethatexists
>>
>> If it doesn't, then you have to tweak your samba settings until that works.
>
> This worked without problems.
>
>> I have seen another post which conflicts with the information in our
>> FAQ and suggests force create mode = 0774
>>
>> Please let us know if you find something that helps.
>
> I will test if there are still errors on commit when I use this setting.
> Thanks for the suggestion. Just for the records: My Samba version is
> "3.0.28a" (as available on Ubuntu 8.04).

That is quite old. I have seen a report somewhere that 3.2.3 fixes a
problem that was not fixed in 3.2.1, not sure if it is exactly the
same problem, and also that 3.2.3 is available for Ubuntu.

Simon

--
:       ___
:  oo  // \\      "De Chelonian Mobile"
: (_,\/ \_/ \     TortoiseSVN
:   \ \_/_\_/>    The coolest Interface to (Sub)Version Control
:   /_/   \_\     http://tortoisesvn.net

------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2363093

To unsubscribe from this discussion, e-mail: [[hidden email]].

[Tobias Rapp]

Simon Large wrote:
> 2009/6/18 Tobias Rapp <[hidden email]>:
> > I will test if there are still errors on commit when I use this setting.
> > Thanks for the suggestion. Just for the records: My Samba version is
> > "3.0.28a" (as available on Ubuntu 8.04).
>
> That is quite old. I have seen a report somewhere that 3.2.3 fixes a
> problem that was not fixed in 3.2.1, not sure if it is exactly the
> same problem, and also that 3.2.3 is available for Ubuntu.

The problem is that my server is used in a production environment and that
samba version 3.0.28a is the latest version available if I want to keep the
system retrieving security updates. If I want to install a later version I
can try to use the latest samba package from Ubuntu but most likely the
versions of library dependecies will not match so I might have to compile it
from sources. Of course this is then necessary each time a new version of
samba gets available after a security fix...

So unfortunately the term "available" has a different meaning on GNU/Linux
systems than on Windows. But of course this thread is getting off-topic now
for TortoiseSVN.

Tobias

------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2364204

To unsubscribe from this discussion, e-mail: [[hidden email]].