"unable to make file read-only"

kgothe · Post by **kgothe** » Tue Sep 27, 2005 3:45 am

When pressing "Get latest version" on a project folder I sometimes get the popup message "unable to make file read-only" for a retrieved file. This problem seems to occur randomly.

As a consequence the file changes attribute to writeable and is vulnerable for changes without checking it out.

Any suggestions how to solve this problem?

We now use SourceOffSite version 4.1 on both client and server side but this problem occured in previous version 3.5.3 as well.

I have Windows XP pro. on my client and the server runs Windows 2003 Server.

Post by **Tonya** » Tue Sep 27, 2005 10:11 am

As a consequence the file changes attribute to writeable and is vulnerable for changes without checking it out.

Under Tools, Options, Files tab, there's an option "Use read-only flag for files that are not checked out", make sure this option is enabled if you don't want your files to be read/write when retrieved using the "get latest" command.

Thanks,

Tonya Nunn
SourceGear Support

kgothe · Post by **kgothe** » Mon Oct 03, 2005 5:26 am

Thanks for your fast respons but unfortunately it didn't help me. The option for read-only flag was already enabled.

There seems to be a relation between this error and when the .NET project is opened when getting the latest version from SourceOffsite. In all cases I have seen so far, the file was also opened for editing in .NET studio.

Could there be a timing problem between .NET and SourceOffsite in this case?

I have also got an popup message with something like 'Unable to make file writeable'. In this case a new version of the file was never retrieved.

Post by **Tonya** » Mon Oct 03, 2005 9:10 am

Are you experiencing this problem using the SOS Client or VS.Net? If you are using VS.Net, which version are you using?

Thanks,

Tonya Nunn
SourceGear

kgothe · Post by **kgothe** » Mon Oct 03, 2005 9:43 am

The problem occurs in SOS Client while getting latest versions of files probably already opened in VS.Net for editing.

I'm using
VS.Net 2003 ver. 7.1.3088
.NET Framework 1.1 ver. 1.1.4322 SP1.

Post by **Tonya** » Mon Oct 03, 2005 12:39 pm

The problem occurs in SOS Client while getting latest versions of files probably already opened in VS.Net for editing.

Are you using the SOS Client at the same time as you are integrating VS.Net with SOS?

Are the files that are already opened in VS.Net and being edited checked out files?

Thanks,

Tonya

kgothe · Post by **kgothe** » Tue Oct 04, 2005 5:01 am

My VS.Net is currently disconnected from Source Control but yes, I have VS.Net and SOS Client opened at the same time.

Yesterday, I received the error 'unable to make file...' without having the file opened in VS.Net but VS.Net was running and I was working in a project using the same working folder as the file failed to make writeable.

This error has never occured on files that are checked out.

Post by **Tonya** » Tue Oct 04, 2005 10:01 am

Are you manually changing the attribute flag to be writeable for any of these files?

Tonya

kgothe · Post by **kgothe** » Wed Oct 05, 2005 3:14 am

No, I let SOS manipulate the read-only attribute.

Post by **Tonya** » Wed Oct 05, 2005 12:52 pm

In all cases I have seen so far, the file was also opened for editing in .NET studio.

I assume that this file is checked out? When a "get latest" has been performed on a file that has been chenged in the repository, the file should attempt to be merged.

I am having difficulty reproducing this issue. Could you e-mail me direct steps that you take to reproduce the problem? And maybe send me some screen shots so we can get this problem resolved for you.

Send them to Tonya@SourceGear.com.

Thanks,

Tonya Nunn
SourceGear

kgothe · Post by **kgothe** » Thu Oct 06, 2005 3:33 am

No, the file causing the error is never checked out. We have configured our sourcesafe database not to allow multiple checkouts so merging files is never needed.
As I posted Oct 04, 2005 12:01 pm, it is not necessary that the file is opened in VS.Net. However, it remains a fact that this problem never occurs when VS.Net is not running while getting latest version of a project in SOS Client.

I will take some screen shots next time it happens and send them to you.

Thanks

Post by **Tonya** » Mon Oct 10, 2005 9:14 am

After receiving more details from the user via e-mail, I determined that this problem was probably caused by using the IDE at the same time as the SOS GUI Client.

Tonya Nunn
SourceGear

kgothe · Post by **kgothe** » Thu Oct 20, 2005 3:00 am

I am not completely satisfied with your suggestion to use the SOS functionality within VS.Net.

The reason for this is that it is to slow. I have a solution with 37 sub-projects. It will take about 30 seconds to open it when connected to source control and about 2 seconds when disconnected.

Furthermore, when disconnecting due to working offsite I have to cancel 2*37 popup's for logon to the server! The same procedure repeats when connecting to the server again. This takes about 5 minutes each time.

You will probably suggest that I should check the flag for automatically logon to server but since we have five different source safe databases to choose between this is not an option for me.

So working disconnected in VS.Net with SOS Client handlings source control functions works best for us despite the annoying popup 'unable to make file read-only'.

It would be nice if you recognized this as a bug and fixed it in the next realease of SOS Client.

Post by **Tonya** » Tue Oct 25, 2005 9:57 am

I wanted to let you know that I have been researching more into your problems. I have a couple of more questions for you. In one of the screen shots that you sent over, it displayed a dialog from within VS.Net that stated "The file has been modified outside the source editor. Do you want to reload it?". I am a little confused as to why you are receiving this message because when I work in disconnected mode, this message doesn't appear. Could you confirm that the entire solution is disconnected? Also, what happens if you attempt the same scenario using VSS?

Thanks,

Tonya

kgothe · Post by **kgothe** » Wed Oct 26, 2005 6:13 am

I believe this is a VS.Net option not related to source control.
If you look in Tools->Options->Environment->Documents you will find a setting for 'Detect when file is changed outside the environment'. This applies to all opened files regardless of they are part of your solution or connected to source control.

I have never had these kind of problems using VSS Client concurrent with VS.Net.

kgothe