Corrupted files on check in with SourceSafe beta

Corrupted files on check in with SourceSafe beta

• MeiXi

  Buddy Lott,

  From DOS times, 0x1A (ascii 27) is the character for end-of-file in text files. Some editors save that extra character, some don't. Other ignore that character and everything that's after it (e.g. try type command on a file that has the character in the middle of the file, see what it displays). I'm not surprised that VSS removes that character from text files. This is not a bug.

  VSS is not translating CR->CR+LF if the file is binary. However, there is a bug that after a checkin, the file type may incorrectly change back to Text (if you have set "Auto-detect encoding of local files"). A workaround is to select the File/Properties and in General tab to turn off encoding's auto-detection, and to make sure that the file type is binary. You can also call product support and ask for the KB923434 (http://support.microsoft.com/kb/923434/EN-US).

  Alin

  
  

• Jose Luu

  All,

  I finally got the right DLL from Microsoft.

  It didn't solve the problem.

  I finally "solved" the problem by deleting the file from the archive and then adding it back while forcing the mode to binary. I lost the check-in history, but in this case there wasn't much to loose.

  I will post again if I find a better solution.

  
  
  

• jhobrown

  I know that we had the same problem when adding PDF files through drag-n-drop from explorer.  It would corrupt all .fdf and .pdf files.  We can't find a way to specify file types, or masks when draging files into a sourcesafe database so this might be the cause.
  

• BryanKinkel

  
  Hi Ben,
  
  Indeed that is the Beta 2 build number.
  
  If you have an MSDN subscription you should be able to download the final RTM version in just a few weeks.
  
  You can also try one of the CTP releases at: http://lab.msdn.microsoft.com/vs2005/, if you want to work on a newer version before that.

  Regards,

  
  
  

• OgaNS

  Hi Mike,
  
  If I understand correctly, you have experienced the corruption by checking in files using an IVSS application.
  
  IVSS interface should be backwards compatible and applications should continue to work unchanged. I remember though in earlier builds of VS2005 I've seen an IVSS application that was loading both ssapi.dll from VSS 6.0 and ssapi.dll from VSS 2005 if both were installed on the machine in different locations, and this was causing other strange behavior. I'd check if this is not the case by using ProcessExplorer from sysinternals.com
  
  Also, there were some bugs in VSS2005 beta2 related to the encoding autodetection, that were fixed in later builds. It's possible these may have affected your scenario.
  
  It may worth opening a product bug though at http://lab.msdn.microsoft.com/productfeedback, and adding enough information that would allows our testers to reproduce the issue (e.g. fragment of code from your application or a small sample application that reproduces the issue)
  
  Alin
  

• tqheel

  Hi, Alin.  Thanks for the quick reply.  I will address your comments one at a time below:
  
  - run ssadmin on the database to verify there isn't any corruption to begin with
    - We have actually completely deleted and recreated the database twice now, and it doesn't seem to be corrupted at creation time.
  
  - temporarily disable the antivirus (on server/client machines) so it wouldn't interfere
    - This was done and we've still had the problem.
  
  - see if the corruption happens when checking in files from the same machine as the database (to eliminate the possibility of network failure, bad network card, etc)
    - This isn't possible - our server runs a different OS.  Also, we can check things in and out of older VSS databases on the same server fine, and we can even use a new VSS database that only contains code and is only accessed through DevStudio.
  
  - see if any corruption pattern can be identified (e.g. happens only for one binary, or only when one specific user checks in, etc)
  If everything fails, you can open a product bug, but we'll need something specific that will help us to reproduce the problem in order to fix it.
    - We've been trying.  The only thing that seems to be consistent is that the corruption always occurs when using the Source Safe SDK to check in files, rather than using the SourceSafe standalone program or IDE integration.  We've been using the SDK of 6.0d for 3 years now without any problem - is there something in the SDK that we need to be doing differently for 2005
  
  Mike.

  
  
  

• yhhuang MSFT

  Actually, we get this corruption from source safe alone, in addition to our IVSS application.  How can we tell if we're using VSS2005 beta2   About reveals "Microsoft SourceSafe Version 8.0.50215.44"
  
  We'd really rather resolve this problem than have to revert to a different source control, at this point.  It only seems to happen with assets, and only since we started using this version of VSS.
  
  

• Morten Teinum

  I just notice this same problem with v8.05-727.42

  I noticed a while back that VSS would strip a character at the end of some specific source code files. These files all seem to have a 0x1A byte as the last byte of file and this byte would be removed.

  Today, I checked in a PDF file and it inserted a single byte into lots of different places in the file.

  When I opened the "good" pdf file and the "corrupted" pdf file in BeyondCompare using a hex comparison, it shows that VSS is translating all of the 0x0D characters to 0x0D0A characters, even though the filetype is marked as binary, at least according to Tools->Options->FileTypes.

  How do you stop this

  
  
  

• iamGary

  Alin,

  Play with the autodetection flag and file type flag does not seem to resolve the issue.

  So I will have to see about getting the dll mentioned in the KB.

  Thanks for you help.

  
  
  

• jorge1234567

  To be clear, the hotfix only prevents the problem going forward. There is no way to recover files that have already been corrupted.
  
  

• Scrypto

  All,

  This is not my day ..

  My attempts to submitt a request via email to get the updated dll have failed due to problems with their forms. I don't have time to sit on a phone making a request. Does anyone know where I can get this dll without the hassle

  Thanks,

  
  
  

• KevS

  Hi Mike,
  
  I haven't heard any reports of a similar corruption.
  
  I'd try to:
  - run ssadmin on the database to verify there isn't any corruption to begin with
  - temporarily disable the antivirus (on server/client machines) so it wouldn't interfere
  - see if the corruption happens when checking in files from the same machine as the database (to eliminate the possibility of network failure, bad network card, etc)
  - see if any corruption pattern can be identified (e.g. happens only for one binary, or only when one specific user checks in, etc)
  If everything fails, you can open a product bug, but we'll need something specific that will help us to reproduce the problem in order to fix it.
  
  As for reverting projects to VS2003 format, you can either use the backup copy created during the migration to VS2005 format (it's normally placed in a folder Backup in the solution's folder), or you can use the files from VSS history.
  If you are interested just in the project/solution files, you can open the History dialog for those files in VSS and get them.
  If you're interested in getting the whole solution as it was before opening it with VS2005, I'd try to look in history when was the migration/checkin done, then use VSS command line to recursively get the files at a date/time before the migration was done ("ss.exe get $/solution.root -r -VD9/30/2005;11:50a",  etc).
  If the solution contained web projects you'll need to add it back in the database in a different location and open it from source control using VisualStudio; this should allow VisualStudio to correctly create web projects enlistments.
  Normally, it's advised that before migrating a solution to a newer format to create a Share&Branch copy of the project, to avoid this getting/adding/getting again in case you need to work on the older version.
  
  Alin
  
  
  
  
  
  
  
  
  
• Corrupted files on check in with SourceSafe beta