Newer versions of Windows will sometimes allow a file to be silently "deleted" but it won't actually be removed from the file system until all open file handles have been closed. I'll double check to make sure that the plugin at least throws a warning if a file isn't deleted, but I don't believe there is a lot else that can be done.

Rob, I know windows file locking can make it tricky to delete files. However in this case, there were probably 1500 or more class files, and the only file not deleted was the only listed above. I was able to consistently reproduce this bug, so it wasn't just a one-off case. If there is some debug information I can turn on, then I can get you the output from Jenkins.

Assuming you have double checked to ensure the file in question has never been tracked by perforce, then I can't see why that file would be the only one ever missed. Unfortunately, there's no other debug information available. I will need to provide you with a custom build that contains additional debug output.

It seems unlikely that file has been tracked before. I checked that is not currently tracked. If there is any other valid p4 command that I can run to check, let me know.

Code changed in jenkins
User: Rob Petti
Path:
src/main/java/hudson/plugins/perforce/QuickCleanerCall.java
http://jenkins-ci.org/commit/perforce-plugin/644ad886249dbd8f2356fae1d1148a429a2ee95f
Log:
JENKINS-17439 add a warning if a file still exists after it is deleted

Are you getting any warnings? What os are you using? This works fine for me in production.

Windows 7 SP1 x32|x64 + Debian 7 x32|x64

No warnings.
As far I understood p4 'quick clean' option does't try remove untracked files.
It only restore changed tracked files.

Using remote perforce client: boatwright_hidden-debian7
[hidden-debian7] $ p4 workspace -o boatwright_hidden-debian7
'Don't update client' is set. Not saving the client changes.
Note: .repository directory in workspace (if exists) is skipped during clean.
Quickly cleaning workspace...
[hidden-debian7] $ p4 d views/hidden-debian7 -x have
Workspace is clean.
Restoring changed and deleted files...
[hidden-debian7] $ p4 d views/hidden-debian7 -x sync -f
[hidden-debian7] $ p4 -d views/hidden-debian7 diff -se
//mts/cn/3rdparty/Google/Chromium/Streams/34.0/src/build/gyp_helper.pyc#8 - refreshing /home/user/views/hidden-debian7/3rdparty/Chromium/src/build/gyp_helper.pyc
...
//mts/cn/Applications/ProPlus_SDK/Streams/v06/build/cmake/version.inc#2 - refreshing /home/user/views/hidden-debian7/mts/cmake/version.inc
[hidden-debian7] $ p4 d views/hidden-debian7 -x sync -f
[hidden-debian7] $ p4 -d views/hidden-debian7 diff -sd
Files restored.
Clean complete, took 863814 ms

That log looks fine to me... Are you able to confirm that files are left behind?

Yes. All non tracked files is present after quick clean.
Don't forget that .p4config file - is exception. It shouldn`t be removed during clean.

Again, this is working fine for me in production, so I honestly don't know how to debug it.

File a separate ticket for the .p4config issue. It's more complicated than you think, because your .p4config file can actually be named anything you want (as it is configurable by the P4CONFIG environment variable, which the p4 plugin clears when it runs).

Which Perforce client and server versions do you use?
Each us ws has .p4client configuration.
Which exact command should remove untracked files?

PS. We use perforce with local proxies.

Server version: P4D/LINUX26X86_64/2011.1/428451 (2012/03/08)
Proxy version: P4P/LINUX26X86/2010.2/341251 (2011/08/05)
...
Broker version: P4BROKER/LINUX26X86_64/2011.1/370818

PPS. Perforce promises native 'p4 clean' command in ver. 2014.1
http://www.p4ideax.com/ideas/434/add-a-clean-operation-to-p4-and-p4v

I use 2012.1, also with proxies in each office.

There is no single command to remove untracked files. The plugin compares what you have to your p4 have list (which is presumably empty, since you appear to be using a read-only replica) then removes anything that peforce doesn't think you have synced.

Yes, p4 clean support will come in a future version of the plugin.

You will probably want to ensure that the broker is not configured to prevent any commands from running. That's caused the plugin problems in the past, and may be what you are experiencing.

Update p4proxy 2010.2/341251 to 2013.3/740675 solve the issue.
Before update p4proxy (2010.2/341251) version was less then p4d version (2011.1/428451).