git clone/checkout error: unable to create file ... File name too long

[jacque006]

OS: Ubuntu 21.04 x64
git version: 2.30.2

Problem

In a folder in my home directory (/home/USER/...):

$ git clone git@github.com:ethers-io/ethers.js.git
Cloning into 'ethers.js'...
remote: Enumerating objects: 36045, done.
remote: Counting objects: 100% (2958/2958), done.
remote: Compressing objects: 100% (1381/1381), done.
remote: Total 36045 (delta 1610), reused 2696 (delta 1411), pack-reused 33087
Receiving objects: 100% (36045/36045), 72.74 MiB | 4.53 MiB/s, done.
Resolving deltas: 100% (21063/21063), done.
error: unable to create file packages/testcases/input/wallets/wallet-secretstorage_password-88a5c2d9919e46f883eb62f7b8dd9d0cc45bc290-f03e581353c794928373fb0893bc731aefc4c4e234e643f3a46998b03cd4d7c5-foo.json: File name too long
fatal: unable to checkout working tree
warning: Clone succeeded, but checkout failed.
You can inspect what was checked out with 'git status'
and retry with 'git restore --source=HEAD :/'

Attempted Workaround

$ git config --global core.longpaths true
$ git clone git@github.com:ethers-io/ethers.js.git

Fails for same reason

Working Workaround

$ cd /tmp # or another non-home root based dir
$ git clone git@github.com:ethers-io/ethers.js.git

My home directory is encrypted, I'm assuming that is limiting file name lengths.

Expected

Would be nice if the file names for the testdata (and potentially other dirs/files) could be shortened so this repo can be cloned on file systems with more limited file name lengths.

Seemed based on repo issue creation template that this was more appropriate for Discussion, happy to create an issue as well.

[ricmoo]

I think this is better suited for discussions. The filenames are actually used as part of the testcase generation process (each field is part of the password, etc. for example, and the file is a vanilla file out of geth and friends), so it would be extra effort to change that, which I don’t really have the time for now.

But I plan to move testcase generation out of the repo into its own in v6.

What is the length restriction?

You should able to clone it into a non-encrypted volume for now, or possibly configure the name length in your file system? Although, in my experience, those are often compile-time restrictions and require rebuilding the entire fs module after modifying some #defines. :s

[jacque006]

Yeah, as I stated above I've been able to work around it by cloning to a different non-home dir. I'm a bit hesitant to try to manually upping the length as I don't want to bork my setup but may try that later.

According to getconf NAME_MAX ., byte size limitations on my system are:

• /home (encrypted): 143
• /tmp (and I assume other non-encrypted dirs): 255

[jacque006]

Also, are there any tricks to using npm link with this repo? I'm attempting to track down an issue we have (thehubbleproject/hubble-contracts#612) and believe the recent EIP-1559 merge may resolve it. After I npm link from master on ether.js and then npm link ethers in our repo, nodejs/typescript is no longer able to require/import ethers, so previously working imports like:

import { BigNumber } from "ethers";

...

No longer resolve.

⨯ Unable to compile TypeScript:
scripts/simulate.ts:2:27 - error TS2307: Cannot find module 'ethers' or its corresponding type declarations.

2 import { BigNumber } from "ethers";

[ricmoo]

Yeah, I would be careful about changing those system properties... You don't want to render your system inoperative... Filesystems are pretty critical. :)

I have had limited success with npm link in general, but you might try:

/home/ricmoo/someDir> git clone https://github.com/ethers-io/ethers.js.git
/home/ricmoo/someDir> cd ethers.js
# This builds the rat nest of crazy needed for the monorepo
/home/ricmoo/someDir/ethers.js> npm install
# You want to link to the ethers in the packages/
/home/ricmoo/yourProiject> ln -s /home/ricmoo/someDir/ethers.js/packages/ethers node_modules/ethers

Let me know if that works. :)

[jacque006]

Corrected: ln -s /home/ricmoo/someDir/ethers.js/packages/ethers node_modules

⨯ Unable to compile TypeScript:
ts/client/contexts.ts:54:47 - error TS2345: Argument of type 'import("/home/jacque006/workspaces/hubble/hubble-contracts/node_modules/@ethersproject/contracts/lib/index").Event' is not assignable to parameter of type 'import("/tmp/ethers.js/packages/contracts/lib/index").Event'.
  The types returned by 'getTransaction()' are incompatible between these types.
    Type 'Promise<import("/home/jacque006/workspaces/hubble/hubble-contracts/node_modules/@ethersproject/abstract-provider/lib/index").TransactionResponse>' is not assignable to type 'Promise<import("/tmp/ethers.js/packages/abstract-provider/lib/index").TransactionResponse>'.
      Type 'import("/home/jacque006/workspaces/hubble/hubble-contracts/node_modules/@ethersproject/abstract-provider/lib/index").TransactionResponse' is not assignable to type 'import("/tmp/ethers.js/packages/abstract-provider/lib/index").TransactionResponse'.
        The types returned by 'wait(...)' are incompatible between these types.
          Type 'Promise<import("/home/jacque006/workspaces/hubble/hubble-contracts/node_modules/@ethersproject/abstract-provider/lib/index").TransactionReceipt>' is not assignable to type 'Promise<import("/tmp/ethers.js/packages/abstract-provider/lib/index").TransactionReceipt>'.
            Property 'type' is missing in type 'import("/home/jacque006/workspaces/hubble/hubble-contracts/node_modules/@ethersproject/abstract-provider/lib/index").TransactionReceipt' but required in type 'import("/tmp/ethers.js/packages/abstract-provider/lib/index").TransactionReceipt'.

54         return await this.strategy.parseBatch(event);
                                                 ~~~~~

  ../../../../../tmp/ethers.js/packages/abstract-provider/lib/index.d.ts:77:5
    77     type: number;
           ~~~~
    'type' is declared here.

I'm guessing that I would also need to symbolically link all of the other related 5.4.0 update to packages as well one by one to get in sync. This is not a huge showstopper for us as we can use geth v1.10.3 for now and re-test issue once ethers@v5.4.0 is out on geth v1.10.4. Appreciate the help!