Even if that means data loss?

My expectation is "archive" means "mark as deleted" in Phabricator.

I disagree that this is the expected behavior, especially if this occurs on hosted repositories (which I can't confirm because I don't have any). If this occurs with hosted repositories, then archived repositories will be forever lost when replacing the repository hosting tier.

I'm missing something I think, this sounds like expected behavior with a reasonable workaround. What's the bug?

test:

• test script:
  test.php490 BDownload
• dumped POST:
  test.txt.gz9 KBDownload
• run:

php test.php 31 && tail test.txt
php test.php 30 && tail test.txt

In T10264#160688, @epriestley wrote:

Does changing window to 31 actually fix it for you?

Does changing window to 31 actually fix it for you?

Still hang...
dumping decompressed result shows input was truncated.

Thanks for verifying the fix!

I can confirm it now works properly for me (5.6) at HEAD.

I think this is now resolved for PHP 5.6 at HEAD of master.

Never mind, that patch doesn't work.

Yeah, I'd like to avoid that "simple workaround" of 200 lines of spaghetti if I can, since I'd guess this task is going to go through 50 more rounds if I have to implement that.

This comment seem to indicate 5.6 indeed broke file_get_contents("compress.zlib://php://input"). I didn't delve much into the proposed workaround yet but it might give a hint of what's going on.

Alright, thanks. Both you and @ppggff have PHP 5.6, I'll see if I can reproduce with 5.6.

@epriestley yes, pretty much the same ones :

[Sat Feb 20 09:04:56.337247 2016] [:error] [pid 5801] [client 86.219.113.93:56185] PHP Warning:  file_get_contents(): cannot represent a stream of type Input as a File Descriptor in /home/w4w/domains/REDACTED/phabricator/support/PhabricatorStartup.php on line 144
[Sat Feb 20 09:04:56.350142 2016] [:error] [pid 5801] [client 86.219.113.93:56185] PHP Warning:  file_get_contents(compress.zlib://php://input): failed to open stream: operation failed in /home/w4w/domains/REDACTED/phabricator/support/PhabricatorStartup.php on line 144

Ubuntu 14.04
Apache : 2.4.16
Php : 5.6.12-1
Php being through mod_php

@dpatou Do you have errors in your error log similar to the ones @ppggff describes?

@epriestley Reverting both 5e375482 and 8269fd6e make me able to clone normally again.

This implies a question: Could it be Phabricator which modifies the stream between the client and the server in an illegal way? Or is this some bug in Mercurial itself?

Reading the code around /usr/lib/python2.7/dist-packages/mercurial/sshserver.py:32:

def getargs(self, args):
    data = {}
    keys = args.split()
    for n in xrange(len(keys)):
        argline = self.fin.readline()[:-1]
        arg, l = argline.split()
        if arg not in keys:
            raise util.Abort("unexpected parameter %r" % arg)
        if arg == '*':
            star = {}
            for k in xrange(int(l)):
                argline = self.fin.readline()[:-1]
                arg, l = argline.split()
                val = self.fin.read(int(l))
                star[arg] = val
            data['*'] = star
        else:
            val = self.fin.read(int(l))
            data[arg] = val
    return [data[k] for k in keys]

The expectation is that you create a "Bot" account, and add keys to that account.

I think this issue was fixed by 58c2141 (Feb 16) which hasn't promoted to stable yet. You can either upgrade to master now, or it should promote to stable in about 24 hours. If you want, you can subscribe to the Changelog to keep track of when we promote.

Yes, the affected repositories are mercurial, there are several. The version is the latest stable one (https://secure.phabricator.com/w/changelog/2016.07/). I have not yet found a way to reproduce this behavior nor can I tell what the affected repositories have in common (not all are affected).

Just to confirm, this is a Mercurial repository, right? (I'm assuming it is because of default instead of master, but just want to make sure.)

Please fill out a full bug report, including your version and steps to reproduce. See Contributing Bug Reports.

It sounds like no one can reproduce this problem anymore. If anyone runs into this again and can figure out reproduction steps, feel free to file a new task with details.

I think this issue was fixed by 58c2141 (Feb 16), which is a little ahead of where you are. You can update to master to pick it up right away, or it should be available in stable in about 24 hours (if you want, you can subscribe to the Changelog page to keep an eye on when we promote to stable).

phabricator

70c679110e1d4632d19ca160379f83f6f20d79d1 (Sat, Feb 13)

arcanist

ed476cf8489c4bf41b7a0075f15d40820d640fe4 (Sat, Feb 13)

phutil

9c472e7c9b64395424c6cd25734bf239cb3c113d (Sat, Jan 23)

Can you either confirm that you're running HEAD of master, or tell me what version of Phabricator are you currently running?

Our projects make heavy use of mercurial tags too, for version tagging and it would be great to see them in Phabricator to easily compare files between versions (they're way more easy to remember than changeset hashes).

I got this:

I got the same problem with HEAD of master.
it seems relate to clone a git repo with gziped post data by http.

@epriestley I will try reverting theses commits when I get a stable ssh into my phab instance and keep you posted.

@dpatou Does reverting both 5e375482 and 8269fd6e fix the issue for you?

I still can't git clone, but if I create an empty folder, init a repo in it, put my phab-hosted repo as origin remote and pull/merge into master, it works just fine great (just as cloning would/should)

I'm in the middle of a trip right now so can't test as much as I'd like but i'm still having the issue. On my desktop computer I can pull pretty fine the repos that were previously cloned but on this freshly reinstalled laptop I can't clone repositories, hanging forever after the git-upload-pack with connection left untouched, as the other comments stated here.

The issue disappears today! I don't know why.

To add to this, viewing a Task shows "Projects" whereas editing it shows "Tags". This caused confusion to one of my users, who couldn't find where to update the Projects while editing a task.

Thanks!

Also probably related to T8831.

Thanks.

I think the script was removed around the time AphrontSite was written, because it was using a pretty hacky approach to figure out the right controller. You can now find the current controller in DarkConsole → Request → Controller:

After recent upgrade I no longer have this ./scripts/aphront/aphrontpath.php file. Was it moved to different place?

Deleted JS directory.
/daemon/ link shows no failing task recently:

Delete the JS directory, and visit the /edit page; It should show information about the state of the daemons.
Look also at the daemons console (Navigate to /daemon/), and look for failing daemons and logs.

deamon is running as root user

/var/repo/ needs to be owned by the daemon user (The user that phd runs as), and the daemons need to be running.
When importing git/mercurial repos, the daemons copy all the content to /var/repo/CALLSIGN; That doesn't happen with SVN, which is why you didn't run into this before.

2 days is a very long time to import. I'd wait until it's finished (we should still fix the error if we can reproduce it)

Is the import complete?

In T10341#158952, @chad wrote:

Is this Subversion?

I believe this is now fixed at HEAD of master. It should promote to stable tomorrow morning.

Is this Subversion?

Unfortunately we can't fix bugs we can't see (well, usually). If you have further details (like what type of repository) or errors in your Apache log, please post them.

Hi @chad , I added some info. I don't know the real reason honestly.

Please see Contributing Bug Reports. Specifically we can't take a bug report without you providing the reproduction steps. How can we reproduce this error?

Awesome, thanks for testing! I think this should be an easy fix, now.

I think that may be important:

To prevent confusion with Git/Hg/Svn tags: What about "Label"?

Confirm. After deleting of mentioned line on top of stable everything clones fine.

I just tested it and it seems like removing the line solves the problem.

I'm just going to co-opt this as a subtask for that piece since you already tagged it so nicely.

(This is adjacent to T4245 and should be happening fairly soon -- next big-ticket item I'm currently planning to hit after subprojects/workboards calm down.)

Oh, and make sure you restart fully after changing the code -- I suspect that might have been the cause of the revert not fixing things earlier. Here's a guide if you aren't sure how:

right, I wasn't sure if it was a special case of either of those, but I figured I'd ask just in case.

Can anyone who is able to reproduce this let me know if this fixes it?

This will be supported by diffusion.search out of T5873. See also T10329.