How to fix Perforce error "Can't clobber writable file" or Perforce Error Message - Can't Clobber Writable File

Question

Error: Can't clobber writable file : //file name//

Solution: When you try to sync a file, perforce expects your files in workspace will have read-only permissions. If a file is not checked out (by p4 edit) but has write permission then it will throw the above error. Changing the file to read-only and syncing again will solve the issue. Or try removing the workspace and get the latest revision again.

Doom

Or set the clobber option in your workspace definition.perforce.com/perforce/doc.current/manuals/cmdref/Content/CmdRef/… – Hemihydrate

For those who prefer using p4v, can set the clobber option by going to Connections > Edit Current Workspace > Advanced and checking the Clobber checkbox. – Munshi

Answer 1

The "can't clobber writable file" error happens because Perforce is very cautious about accidentally overwriting ("clobbering") work that you've done in your workspace.

The normal Perforce workflow is to p4 sync a file (which puts it into your workspace as read-only) and then to p4 edit it if you want to modify it (this makes it writable). A file that has been opened with p4 edit will always be skipped by p4 sync (except to safely schedule a resolve if needed), and will be included by a p4 submit.

If a file is not open, but is writable, it means that something has gone wrong in this workflow, e.g. you manually made the file writable to make changes to it, and if sync updates this file, your changes will be lost! So the default behavior of sync is to skip updating writable files.

With that explanation out of the way, here are some options:

1. p4 sync -f FILENAME will force an unopened file to be updated, whether or not it is out of date, and whether or not it is writable. (Open files are still skipped.)

2. p4 edit FILENAME will open the file. From there your options are p4 revert (discarding your changes) or p4 submit (submitting your changes).

3. Changing noclobber to clobber in your client spec removes safeguards against clobbering writable files.

4. Changing noallwrite to allwrite makes all files writable by default, which implicitly removes the noclobber safeguard. In current versions of the server it also enables the "safe sync" option (p4 sync -s) by default, forcing digest computations on all files before updating them. This is slower than relying on the write bit, but much more accurate. Note that if you work on files without opening them, you still run the risk of not having them included in your submit -- the p4 reconcile command is your friend here.

Ashanti

I would just add that for #1, p4 sync -f should be used to force sync only those specific files. Someone might be tempted to just run p4 sync -f on their depot to avoid the clobber message, and pay the price of fully synching every file. – Mcguigan

p4 sync -f can be too "heavy" and can take a lot of time in case of big work tree. I would not put this one as the first option. – Reproductive

p4 edit require that user will repeat that for every problematic file. This is not one-for-all-files solution. – Reproductive

I like the clobber option proposal. Here's how to switch to it from noclobber: #16277831 . – Reproductive

If this is a situation that you hit routinely on a large number of files, you probably have some much larger problem in your workflow. (Maybe these are generated files that shouldn't even be under version control, or should be typed as +w? This is the sort of best-practices question that probably deserves its own post.) – Ashanti

Updated the answer to clarify that p4 sync -f and p4 edit should both be applied to the particular writable file, NOT the entire tree. Most of the time p4 sync -f is the one you want to do (i.e. the file got made writable by accident and you just want to fix it), which is why it's the first option, but you DON'T want to do it to the entire workspace. The later options (noclobber and allwrite) are much less desirable IMO because they make permanent changes to the entire workspace that increase the likelihood of more problems down the line. – Ashanti

what boggles my mind is that p4 doesn't flat out fail upon seeing a writable file. A common mistake i see in normal workflow is that people run p4 integrate, do not notice some files were skipped, do p4 resolve and p4 submit and end up with a partial change. How is this okay?? – Autointoxication

sync and integrate aren't atomic across the board (people would probably complain if they were -- as it is a lot of people complain about rename being atomic even though there are pretty compelling reasons for it to be). With both commands, though, you can re-run the command and you should get an "up to date" result almost instantly if the first time was completely successful, which is what I usually do if it was a big operation and I can't visually skim the results, but the catch is that you need to know to do that. – Ashanti

And how does one perform this in P4V? – Dialecticism

Cross your fingers and start checking boxes. P4V changes its interface too often for me to try to keep up with, but usually a command line flag will correspond to a checkbox on the associated dialog (however, the name may have nothing to do with the CLI command/flag, so some level of trial and error is usually required). – Ashanti

Answer 2

Perforce keeps its files read-only until they are opened for editing. I had for some reason made this file writeable and Perforce was complaining about that with this error message.

The error was fixed and the sync worked once I made the file read-only:

$ chmod -w /home/Nisha/p4_workspace/foobar.txt

Also below will fix the problem-

p4 sync -f file-name

Carpospore

Simple and works (for the terminal people at least).. – Heyes

Answer 3

I was using Perforce Software version not the CLI. What worked for me was, I changed the entire project permission to read only and closed the Perforce and opened it again. And then it was able to sync with the cloud.

Meseems

Answer 4

Perforce throws this error when your file is not in Read-Only mode.

The best way to resolve this issue is to open the file in file explorer and right click to open properties and just check the Read-only attributes to move it back to Read-Only mode.

This works for me every single everytime!!

Cavalry

Answer 5

p4 sync -f will force an unopened file to be updated, whether or not it is out of date, and whether or not it is writable. (Open files are still skipped.)

It works

Lowland

This is the very first option listed in Sam Stafford's Jan 2020 answer. Cautions apply. – Coinage