Visual SourceSafe (VSS): "Access to file (filename) denied" error

Question

Hi, can anybody help with the above SourceSafe error?

I've spent hours trying to find a fix. I've also Googled the heck out of it but couldn't find a scenario matching mine, because in my case only a few files (not all) are affected.

Here's what I found:

• only a few files in my project generate this error
• other files in the same directory (for example, App_Code has one of the problem files) work fine
• I've tried checking out from both the VSS client and Visual Studio
• another developer can check out the main problem file without any problems

This sounds like a permission issue for my user, right? However:

• I found the location of one of the problem files in VSS's data directory (using VSS's naming format, as in 'fddaaaaa.a') and checked its permissions; everything looks fine and its permissions match those of other files I can check out successfully
• I can see no differences in the file properties between working and non-working files

What else can I check? Has anyone encountered this problem before and found a solution?

Thanks.

P.S.: SourceGear, svn or git are not options, unfortunately. P.P.S.: Tried unsuccessfully to add tag "sourcesafe."

EDIT: Hey Paddy, I tried to click 'add comment' to respond to your comment, but I'm getting a javascript error when loading this page in IE8 ("jquery undefined," etc.) so this isn't working.

This is when checking out files, and yes, I've obliterated my local copy more times than I can remember. ;)

EDIT 2: Thanks for the responses, guys (again I can't 'add comment' due to jQuery not loading, maybe blocked as discussed in Meta).

If the problem was caused by antivirus or a bad disk, would other users still be able to check out the file(s)? That's the case here, which makes me think it's a permission issue specific to my account. However I've looked at the permissions and they match both other users' settings and settings on other files which I can check out.

Answer 1

Things to check in order:

1. Antivirus
2. Other software having the file loaded (blend/notepad/whatever) and locked
3. NTFS permissions locally
4. NTFS permissions on the sourced file (fddaaaaaa.a)
5. Perform disk check (bad sectors may cause this)

Answer 2

A belated update and resolution:

Despite confirming I had the necessary permissions on the file I listed above, and confirming that the timestamp and contents of the file matched the one I was working on, it apparently wasn't the correct file. I'll essplain.

I downgraded to VSS client version 6.0 from the 2005 (8.0) version, and unlike 8.0 it identifies the actual file name in the file system it was trying to access when an error occurs.

The file I listed above was a text representation of the file--it seems the actual file VSS was trying to access ('fddaaaaaa,' not 'fdaaaaaa.a') is a binary file. [I assume that relates to how VSS is managing what's a file-based database system.]

For some reason I didn't have the necessary permissions on the binary representation of the file, and fixing this corrected the problem. I still don't know why I didn't have permissions for only a few files while the majority of files were accessible to me. [The files in question weren't newly created.]

Does that make sense? Only to me?

P.S.: Unfortunately I have no say here and SS is and will be our version control software.