Ok sorry for that - that was a really bad example... The problem is that only complete words are found and not parts of it.
So you'll get a result for "Hello" but not for "Hell".
So searching for "Component" will give no result if the title is "Components". Is that correct?

Slightly easier is:

I was able to reproduce this, possibly, by following these steps:

What specific steps can I follow to reproduce this issue? See Providing Reproduction Steps for help.

I would also maybe check webserver error logs, too. OS/Browser might help to know as well.

I haven't seen more segfaults since I switched.

Presuming this is resolved since we haven't received any more information in about a week.

I cannot reproduce this as stated. Here's what I did.

Issues like this to me (see also T11433) don't really belong in everyday documentation. The main reason being if we continually add these rare or one-time incidents to the documentation, the documentation becomes watered down, difficult to read, and likely admins will miss the more important points. We already provide Maniphest and Ponder for more alternative questions about Phabricator, which Google is good about indexing, as well as our own search engine.

I'm not sure what you could do that would really prevent this, other than changing these to real files. But as you said, it's probably not worth it. As long as users are aware of it, it could prevent these issues from popping up periodically.

Closing for lack of reproduction steps, version information, etc. Please see Contributing Bug Reports and follow our guide if you need help with Phabricator.

Cool -- I don't think we can really detect this because we don't have an opportunity to run any code to check for it. We could possibly have the web UI run a setup check, but I think we get about 1 of these a year and it's reasonably likely that users try to run bin/* before hitting the web UI anyway. If you have any ideas about how we could have caught/prevented this, let us know.

Ah, that was the case, I used sftp to transfer the data because the machine I'm trying to use it on is behind a restrictive firewall. Sorry for the confusion..

Update past rPa5b26104 (Jul 9).

Sorry I missed the previous notification.

Closing this since we haven't seen a response for about a week, this report didn't follow the instructions by omitting version information, and it's very likely that this is resolved by updating.

Specifically if you feel this is a Phabricator issue, please provide steps we can follow on a clean/new install on http://phacility.com/. Test instances there are free to spin up any time.

Please see Contributing Bug Reports for how to file a proper bug report. See Support Resources for what resources are available for getting help configuring or using Phabricator.

I am an admin w/full permissions, but even so I've tried just doing this on my own personal blog that I created myself and can't even do that.

Specifically, if you don't have permissions to edit a blog, you should get a permissions dialog like below. Sounds like someone has been messing with the custom forms.

All files from before you upgrade to D16270 are haunted and subject to ghastly behavior.

I'm going to merge this into T10252, which may not be the same issue, but which has reproduction steps.

• Choose the default colour+icon picture for the project
• In the project history, click the link to the file that has been assigned as the picture
• Note that the file is temporary, so will be cleaned up by the garbage collector

This report isn't actionable. Feel free to file a new one that is:

Additionally, you should use maniphest.edit, not maniphest.update.

Also, for clarification, "Administrators" on Phabricator are just regular users as far as policies go. They don't override them.

Closing for lack of feedback. If you're able to update your install and provide this task with a set of reproducible steps, we can look into it further.

OK, I didn't actually read the 69-chars indent earlier.
The image on the right looks exactly the way I would expect a 69-deep text diff to look - most of the way to the right, breaking when it needs to.
The one on the left looks like it's not indented much; The double-space is because the lines on the right-side are longer.

Click "Try Free" then click "Test Instance" after signup.

$20 to use Phacility?

I'll re-test on our private network w/ latest phab soon, who knows maybe it's fixed.

All I needed to test on my home comp's ie as well was access to a 6 column workboard here, but I felt paying 20$ to use phacility was a little steep to keep the bug open.

Can't find a means to reproduce this locally and haven't seen other reports. Can revisit if either of those change.

The recent changes to the local filestore permission did not seem to resolve this (my truck went missing again). However, now that the logs aren't totally polluted I may see the exception related to this. I'm not positive whether this provides more insight or not, though.

[25-May-2016 13:22:23 America/New_York] [2016-05-25 13:22:23] EXCEPTION: (PhutilProxyException) Permanent failure while executing Task ID 4733388. {>} (PhabricatorWorkerPermanentFailureException) Unable to load transactions: PHID-XACT-DREV-vl56ah6csf7wlan. at [<phabricator>/src/applications/transactions/worker/PhabricatorApplicationTransactionPublishWorker.php:112]
[25-May-2016 13:22:23 America/New_York] arcanist(head=stable, ref.master=d54cb072facd, ref.stable=1439aaa87183), phabricator(head=stable, ref.master=7cc8a73d1efd, ref.stable=2c67d9c8ace2, custom=2), phutil(head=stable, ref.master=83f09f6c5a03, ref.stable=76425eaa8125)
[25-May-2016 13:22:23 America/New_York]   #0 <#2> PhabricatorApplicationTransactionPublishWorker::loadTransactions(DifferentialRevision) called at [<phabricator>/src/applications/transactions/worker/PhabricatorApplicationTransactionPublishWorker.php:19]
[25-May-2016 13:22:23 America/New_York]   #1 <#2> PhabricatorApplicationTransactionPublishWorker::doWork() called at [<phabricator>/src/infrastructure/daemon/workers/PhabricatorWorker.php:122]
[25-May-2016 13:22:23 America/New_York]   #2 <#2> PhabricatorWorker::executeTask() called at [<phabricator>/src/infrastructure/daemon/workers/storage/PhabricatorWorkerActiveTask.php:171]
[25-May-2016 13:22:23 America/New_York]   #3 <#2> PhabricatorWorkerActiveTask::executeTask() called at [<phabricator>/src/infrastructure/daemon/workers/PhabricatorTaskmasterDaemon.php:22]
[25-May-2016 13:22:23 America/New_York]   #4 PhabricatorTaskmasterDaemon::run() called at [<phutil>/src/daemon/PhutilDaemon.php:183]
[25-May-2016 13:22:23 America/New_York]   #5 PhutilDaemon::execute() called at [<phutil>/scripts/daemon/exec/exec_daemon.php:125]

In T10460#162318, @teror4uks wrote:

I am solving this problem. Reason was in empty Callsign in setting repository. After I added callsing, revisions became openable for audits.

P.S. Sorry for my english.

yes, problem resolved.

It sounds like this is resolved.

Seems to be happening on quite a lot of Wikimedia's phabricator projects: https://phabricator.wikimedia.org/T128160 ... At least I think it's the same bug. I have no idea what might be causing this.

Do phabricator ghosts dream of mustard trucks

more of a mustard, really.

The last exception in daemons.log:

06-May-2016 20:36:27 America/New_York] [2016-05-06 20:36:27] EXCEPTION: (FilesystemException) Failed to remove file '/var/local/phacility/phabricator/filestore/1a/3e/94c5ea8fadb9f60811517d0eaca9'! at [<phutil>/src/filesystem/Filesystem.php:325]

OK so I've been keeping an on my icons this week to see when it would happen. The ghosts indeed came back and I grabbed logs during the shortest timeframe I could narrow it down to - roughly between 1pm and 8pm today ("narrow", sorry).

I have a mental scarmemory of this exception because there was a period there where I had to be manually cancelling tasks every week to clear broken commit imports out of the queue so the builds would run :3

nice sleuthing!

(@chad you might want to just merge this into T5955 instead of me adding a blocking task, I wasn't sure and figured adding a blocking task was the least destructive thing to do)

Here's the official upstream task: T5955. Here's another report of the same issue: T7260.

This is related to JSON not supporting other character sets than UTF-8. It's a known issue (let me see if I can find the task).

have old legacy project (probably with lots of badly-encoded files)

I suspect this might be related to T4752, or similar. I'm open to other ideas on data to try and collect about this scenario. I'll try to keep an eye on the project to see when the icon reverts and get logs at the relevant time.

Is there any news about this issue ?

@chad @epriestley arcanist works straight of the master branch in cmd on windows for me. But git for windows does not work.

@hach-que thanks for your suggestion, you helped me. I get different directors from different command line so cmd throughs C:\Program Files\Git\cmd\git.ex whereas git for windows throughs /mingw64/bin/git

I'm hesitant to provide further discussion on this issue because of conversation above, but never-the-less in case anyone else using Windows stumbles across this issue, then here's the following advice:

In T10717#168288, @chad wrote:

I tried to reproduce everything. I have never personally developed on Windows, so everything was done from scratch.

• Windows 10
• Installed git from https://git-scm.com/download/win (2.8.0)
• Installed PHP from http://windows.php.net/download/ (5.6.20, Non thread safe)
• Installed phabricator, arcanist, libphutil from master/HEAD over ssh
• Add PHP/Arcanist to global paths
• Un-comment libcurl in php.ini
• Install arcanist certificate
• use arc patch to pull down patch (see D15596)
• use arc land to push to master (see 7694a6729f6a)

Or keep the patch locally yourself, that's fine as well.

That is, you are still required to provide a valid bug report (steps to reproduce) against a supported environment so that we may observe the bug and verify any fix.

And you understand any "fix" against a beta/unsupported environment is not valid in the upstream, correct?

Yes. It seems it may not be able to find the git. Since git for windows updated a lot of things so I doint know if that check works now. But also I doint know if your check will find git in the 64-bit folder or 32-bit.

Are you still working on a beta of Windows?

@epriestley and @chad ive done some digging at it seems to be this

I'm also not trying to waste your time.

In T10717#168291, @epriestley wrote:

You did not test the patch. As I noted, the patch runs git fetch --queit instead of git fetch --quiet.

You also ignored the large explanatory comment immediately above the changed code which explains why it uses passthru and the specific problem that passthru solves, with a reference to the original issue.

In T10717#168291, @epriestley wrote:

You did not test the patch. As I noted, the patch runs git fetch --queit instead of git fetch --quiet.

You also ignored the large explanatory comment immediately above the changed code which explains why it uses passthru and the specific problem that passthru solves, with a reference to the original issue.

You did not test the patch. As I noted, the patch runs git fetch --queit instead of git fetch --quiet.

In T10717#168285, @epriestley wrote:

@paladox, your interactions with this upstream have consistently wasted our time and energy.

I warned you about untested patches in D14813. D15597 obviously hasn't been tested either since it misspells --quiet.

You need to read Support Resources, Contributing Bug Reports, and Providing Reproduction Steps very carefully and follow the rules they set out. You need to apply common sense, critical thinking, and basic software engineering skills in interactions with this upstream. If you are unable to do these things, you need to stop interacting with the upstream.

I tried to reproduce everything. I have never personally developed on Windows, so everything was done from scratch.

@paladox, your interactions with this upstream have consistently wasted our time and energy.

@chad it seems to be working now

And doing

Oh ok, I'm not sure why I'm getting it and your not.