SOS 5.0.1 Unknown status and CRC, how does it work ?

[guillaume]

Hi,

Maybe I misunderstand the "Use Checksums (CRC) to Determine "Unknown" File Status", since it still works exactly as bad in SOS 5 as it did in SOS 4.

I thought that when this checbox was set, client and server (each on their side) computed a CRC of the file and if the 2 CRC matched, the file was considered as synchronized (not unknown nor renegade).

However it does not work as expected.

a simple example on project $/project1 containing only files:

- in SOS client, "get latest" of whole project $/project1 to local root path c:\project1
- in SOS client, all files get no status (synchronized)
- rename c:\project1 to c:\_project1
- switch back to SOS client, all files get status "missing"
- rename back c:\_project1 to c:\project1
- switch back to SOS client, all files get status "unknown"
- (do not refresh the list, nor click another folder, be sure to stay on $/project1)
- right click on $/project1 and chose "get latest". All files are fetched again.

Why doesn't SOS find out (from CRC) that local files in c:\project1 are already synchronized ?

beyond this problem of unnecessarily getting already synchronized files, it is rather annoying when you check out a file in VS2008 to get warning messages saying that the local version is not the same as the remote one, although you know for sure that they are synchronized.
If CRC was properly checked, it would not happen.

Best regards,
Guillaume

[lbauer]

- switch back to SOS client, all files get status "unknown"
- (do not refresh the list, nor click another folder, be sure to stay on $/project1)

What happens if you have Checksums (CRC's) enabled in the SOS Client and you do a refresh? Does the Unknown file status change?

As long as the file status is Unknown, SOS will retrieve all the files when you do a get. You need to first try to resolve the Unknown status by doing a refresh with Checksums enabled.

[guillaume]

Hi,

If I do a refresh on the list, the unknown status changes to no status (synchronized) and the files of this list are not fetched again.

But let's say now that I have a big project with 10 subdirectories that each contains 10 subdirectories containing files.
If for some reasons (like renaming local folder, or shifting working folder), SOS does no longer know the status of all these files ("unknown"), even if none have been modified since get latest, then I need to manually click on 100 folders (and wait until their lists are refreshed), to be sure none of them will be fetched again on "get latest" or that I won't get any nagging warning message in VS2008 telling me that the local version may be overwritten by the remote one, each time I check out a file.
Despite the fact it is boring to validate each message box, it can make you wonder if you are not actually overwritting a different version.
There is also a potential risk of loss of data, because after 25 machinally clicks to approve the overwritting of files that were actually synchronized, you may by mistake overwrite a file that was different.
SOS should check CRC before getlatest or check out of a file.

Regards,
Guillaume

[lbauer]

A refresh won't overwrite a locally modified file when the status is Unknown. SOS keeps a local cache with information about the status of files in the working folder, so if you often change working folders to a folder where files already exist, the cache may get out of sync. A get latest should resolve this, but you may need to backup any changes first.

If CRCs were to be turned on for all SOS file operations, it would slow things down too much. The main reason users use SOS is because it's fast connectivity to a VSS database over the Internet.

[guillaume]

I agree with the performance issue if SOS client performed an "on-the-fly" status resolution on getting or checking out files.
But I think that it could at least try to refresh its cache in background, on idle, so that the user did not need to refresh it manually.

Regards,
Guillaume

[lbauer]

I've logged feature request 15121 for an automatic refresh when the client is idle. Note however that a refresh may take several minutes if you have a large project tree.