D15837 appears to have deployed cleanly here.

I'm going to merge this into T10748: the modern diffusion.repository.edit endpoint it provides is the pathway forward here.

I'm going to merge this into T10748. It should technically be fixed by D15829 on its own, but will be fixed even harder once we cut over to the changes in T10748.

I'm going to merge this into T10748: this should be fixed by D15829, but won't go live until after we cut over to the new UI as part of the changes in T10748.

@storrgie, since it was a test environment, I disabled it

Great, I'm glad to hear things are working for you. Thanks for your help testing this out!

Can confirm that on latest stable my lfs-test repository now succeeds with both jars and jpegs. Huzzah!

I'm going to merge this into T10748, which is now more clearly the way forward.

I'm going to merge this into T10748, since that's now clearly the way forward.

See also T10884 for related work: ranking similar nodes more intelligently.

This also reproduced locally for me (OS X Yosemite, openssh-6.7p1), and chmod on the parent directory alone was reliably sufficient to prevent SSH from working. The instructions already suggest a root-owned location, but D15794 notes this requirement explicitly.

I can confirm T9560 locally, at least, so that might be the problem or part of it -- maybe start there? If you can provide details we're happy to fix this properly.

Thanks @epriestley, i will try to investigate further. It seems that i have still something misconfigured. I'll get back as soon as i have to add something useful. :-)

Yes, you should NOT set AuthorizedKeysCommandUser root, this is needlessly dangerous and gives the script substantially more permission than it needs.

I ran into the same issue, it turned out, that the permissions for /phabricator, /libphutil and /phabricator as well as for the preceding parent-directory had to be 755.

After we receive a push, try very very very very hard to release the lock if we're the thread holding it, even if we lost the global lock

Thanks!
Yes, we will consider setting up alternate file domain

I think D15784 should fix the issue. It should land in master later today and be available in stable in about 24 hours. Let me know if you're still seeing issues once you update past that.

I think I know what's going on, although I'm unsure why the <2MB files would work, unless you happened to push those to a public ("Visible To: Public (No Login Required)") repository and pushed the large files to a private repository?

1. It's not configured
2. Yes
3. I'm not sure, these are my install versions (stable branch) :
   • phabricator f75b1cf562c0c3646324864851d693ef1069a068 (Mon, Apr 18)
   • arcanist 01b6fe8bb0239a4bce03f58d6288a3a52ad83a91 (Sat, Apr 16)
   • phutil b8c65df2a910a7028d39bec602d181428b6ce01f (Sat, Apr 16)

(edit, it has rP37b93f4)

• Is security.alternate-file-domain configured on your install?
• When you say "redirect to the correct file", do you mean you get taken to the file detail page /F1234?
• Also, do you have rP37b93f4 locally (April 7)? (You can grab the hashes in Config → Versions if you aren't immediately sure and I can figure it out from there.)

Ah, is the auth token (first [shortened]) same for every user? It is in my case

1. If I visit the URI while being logged in to the app, the browser redirects to the correct file, the download link works
2. The download URI is the same as the logged URI
3. Visiting the URI with private window returns normal 404 page

You shouldn't need to configure diffusion.allow-http-auth -- the auth token is basically the first [shortened] in the URI, so that appears to be working properly.

I'm using S3 as Files storage backend, phabricator runs behind nginx, and the diffusion is hosted over SSH (diffusion.allow-http-auth=false, HTTP is not configured anyway). I'm having an issue:

• pushing and pulling small files (<2MB) tracked as LFS -> works flawlessly
• pushing 11x 1 GB files works, but can't do git clone / git lfs fetch (got the same issue as @benjumanji, the lfs_trace log is similar, 404 errors when getting the lfs-* files)
• pushing a 11GB file, doesn't work. forgot the error message, will add it later if needed

Very Useful!

so would you mind closing the task? I can't do it myself.

I have no idea if we plan to add it or not. See Planning for how we prioritize time.

If you don't plan to add it: just reject the task - no problem. I just wanted to let you guys no that there is a slightly more secure way of doing what you provide to all the novice users out there.

The diffusion.querycommits method needs to sync-before-read (at least, if bypassCache is provided?) but currently does not. This can lead to tasks failing on the daemon on an un-synchronized node. Things self-heal, but it would be nice to prevent this.

Accepting contributions isn't free to us. We bear the cost of testing, accepting, documenting, and providing lifetime support. See https://secure.phabricator.com/book/phabcontrib/article/contributing_code/ for more details.

this still applies 2 years after sending a diff. is there missing something?

This is probably ultimately the same as T6878 -- T6878#167273 has the current plans here.

I suspect it's due to the replace status code. Specifically, if a specific path is removed + added, it shows as different than a modify. When this is then copied, it looks like SVN is showing this code for the new path of the file too. See /rSVNTEST8.

Turns out that because all spaces were archived, repositories did not get an space assigned to them, explaining the error. After I re-enabled S1, I saw a box for selecting the space appear.

Yeah we should fix that, for sure. Thanks for digging into this.

Ok, Whoops. I toyed with it a bit earlier and created a space, then had the balls to archive it. I unarchived it and everything starts working again: Repositories get shown again in the Diffusion menu, old broken repos stay broken, but new repos can be edited just fine.

Have you set up Spaces?

I've been looking at this the last couple of days as it's a pain point for me -- I'd like to host my repositories on Diffusion, and I would like to stay with Mercurial rather than git..