Page MenuHomePhabricator
Create Task
Maniphest T11431

./bin/* files don't seem to be valid executables
Closed, ResolvedPublic
Actions

Description

On a 64-Bit CentOS release 6.8 (Final) PC with a few non-standard repos enabled, and all dependencies installed.
Executing command from within the phabricator folder:

chmod ug+rx ./bin/* && ./bin/storage upgrade

yields:

-bash: ./bin/storage: cannot execute binary file

This file at least seems to be corrupted. I've redone my checkout a few time, but same result....
None of these binaries are recognized by my machine for some reason. I've tried other commands in that bin folder as well. Same result!

Phabricator Version from git show:

commit 8f4a63d7083d07836e6851f2aeb238bda5141c98
Author: epriestley <git@epriestley.com>
Date:   Wed Aug 3 16:14:17 2016 -0700
    Use consistent tag order in Maniphest list views and workboard cards
    Summary: Fixes T11420. These are selected in newest-to-oldest order from the database, but we should show them in olde
    Test Plan:
    Tagged a couple tasks with "A, B, C" projects, saw correct order in UI:
    {F1749351}
    {F1749352}
    Reviewers: chad
    Reviewed By: chad
    Maniphest Tasks: T11420
    Differential Revision: https://secure.phabricator.com/D16367

Arcanist Version from git show:

commit 3aa47195ef0832aa9d7c86b4ebf320226f097ffc
Author: epriestley <git@epriestley.com>
Date:   Wed Aug 3 08:06:09 2016 -0700
    Set "history.immutable" to "false" explicitly in .arcconfig in Arcanist
    Summary: Depends on D16364. See that revision for discussion.
    Test Plan: Ran `arc get-config history.immutable` in `arcanist/`, saw setting.
    Reviewers: chad, fooishbar
    Reviewed By: fooishbar
    Differential Revision: https://secure.phabricator.com/D16365

libphutil Version from git show:

commit 8b2800566ab972b83307cab8073ca62312d1b0cb
Author: epriestley <git@epriestley.com>
Date:   Wed Aug 3 08:07:31 2016 -0700
    Set "history.immutable" to "false" explicitly in .arcconfig in libphutil
    Summary: Depends on D16364. See that revision for discussion.
    Test Plan: Ran `arc get-config history.immutable --verbose` in `libphutil/`.
    Reviewers: chad, fooishbar
    Reviewed By: fooishbar
    Differential Revision: https://secure.phabricator.com/D16366

Related Objects

Event Timeline

ryanniehaus created this task.Aug 4 2016, 7:14 PM
epriestley added a subscriber: epriestley.EditedAug 4 2016, 7:22 PM

They should be symlinks. As git represents both symlinks and the executable flag, it should be unnecessary to chmod them.

It is vaguely possible that you may have used rsync to transfer the working copy between hosts without -l or an equivalent flag (often -a).

chad edited projects, added Bug Report (Needs Information); removed Bug Report.Aug 4 2016, 9:52 PM
ryanniehaus added a comment.Aug 4 2016, 10:06 PM

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..

epriestley closed this task as Resolved.Aug 4 2016, 10:27 PM
epriestley claimed this task.

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.

We could also possibly change these bin/* files to be real files that include the underlying .php files, but I'm not sure that's worth it given how rare this issue is.

(These files are symlinks so that the code can live in files named *.php, and respond to grep, lint, syntax highlighting, etc., easily. That's not a strong reason not to just put the code directly in the files, but is at least some sort of reason.)

ryanniehaus added a comment.EditedAug 5 2016, 2:19 PM

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.

Perhaps some Note somewhere in the setup instructions? (probably by the bin/storage upgrade command; where I encountered it) I think what I'm going to try is creating a tar archive on the machine I used to perform the checkouts and then untarring it on the destination machine.

Thanks again for the help.

chad added a subscriber: chad.Aug 5 2016, 2:41 PM

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.

Phabricator · Built by Phacility