Search code examples
windowsversion-controlperforcefile-permissions

Perforce claims file is different when it's not

I have this file that seems to have gotten into a weird state. Perforce claims it's modified and unopened:

> p4 diff -se
data.xml

Normally, when a file is modified and unopened, I can use sync -f to fix it. But, for some reason, this particular file is being really stubborn:

> p4 sync -f data.xml
//Depot/Stream/data.xml#19 - refreshing data.xml

> p4 diff -se
data.xml

Like with sync -f, clean appears to work, but it still claims it's modified:

> p4 clean data.xml
//Depot/Stream/data.xml#19 - refreshing data.xml

> p4 diff -se
data.xml

Unsurprisingly, the same thing happens when I try to reconcile -w:

> p4 reconcile -w data.xml
//Depot/Stream/data.xml#19 - refreshing data.xml

> p4 diff -se
data.xml

If I use reconcile (without -w), the file is opened, but P4Merge shows the files as identical even without ignoring whitespace or line endings:

> p4 reconcile data.xml
//Depot/Stream/data.xml#19 - opened for edit

> p4 diff -se

> p4 diff -sa
data.xml

Using revert just puts it back into the state it was in before:

> p4 revert data.xml
//Depot/Stream/data.xml#19 - was edit, reverted

> p4 diff -sa

> p4 diff -se
data.xml

What gives? I had previously copied over this file without opening it for edit first by accident. Did that put it into an irreversible state, perhaps regarding Windows permissions?

I tried deleting the file (del data.xml) and getting it again, but the new copy created by Perforce had the same problem.

Solution

  • Two possibilities come to mind:

    1. The server's checksum of the file doesn't match its contents (which means a diff will always show it as different). Your admin can check this with the p4 verify command.
    2. The line endings in the file are inconsistent and you have the share LineEnd option, which essentially does an implicit dos2unix line ending conversion on every file whenever it's read from local disk. If the dos2unix is a no-op the file will show as identical; if there are \rs in the file then their removal will show as a diff.

    In either case submitting is likely to "fix" the file by creating a revision with a checksum that matches whatever is in your workspace -- but I'd recommend having an admin check p4 verify since if a file has gone bad it's likely to be a symptom of a larger problem (disk failure, etc).