Surfer CLI 5.11.0 fails to upload

[fbartels]

Since this is a docker image in a ci pipeline I opted to just run the stat command manually and indeed the timestamp is way off:

+ surfer --version
5.11.0
+ stat public/.
  File: public/.
  Size: 4096      	Blocks: 8          IO Block: 4096   directory
Device: 811h/2065d	Inode: 6471947     Links: 14
Access: (0755/drwxr-xr-x)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 1754-08-30 22:43:41.000000000
Modify: 2020-12-09 12:33:55.000000000
Change: 2020-12-09 12:33:55.000000000

+ surfer put --token $SURFTOKEN --server blog.9wd.eu public/. /
Using server https://blog.9wd.eu
/usr/local/lib/node_modules/cloudron-surfer/cli/actions.js:63
        atime: stat.atime.toISOString(),
                          ^
...

Afterwards I did touch that directory, but then I get a different error message afterwards from surfer:

+ surfer --version
5.11.0
+ stat public/.
  File: public/.
  Size: 4096      	Blocks: 8          IO Block: 4096   directory
Device: 811h/2065d	Inode: 6471994     Links: 14
Access: (0755/drwxr-xr-x)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 1754-08-30 22:43:41.000000000
Modify: 2020-12-09 13:05:22.000000000
Change: 2020-12-09 13:05:22.000000000

+ touch public/
+ surfer put --token $SURFTOKEN --server blog.9wd.eu public/* /
Using server https://blog.9wd.eu
/usr/local/lib/node_modules/cloudron-surfer/cli/actions.js:315
                if (remote.filePath !== path.join(absoluteDestPath, local.filePath)) return false;
                                                                          ^

TypeError: Cannot read property 'filePath' of undefined
    at /usr/local/lib/node_modules/cloudron-surfer/cli/actions.js:315:75
    at Array.find (<anonymous>)
    at /usr/local/lib/node_modules/cloudron-surfer/cli/actions.js:314:33
    at Array.filter (<anonymous>)
    at /usr/local/lib/node_modules/cloudron-surfer/cli/actions.js:313:36
    at Request.callback (/usr/local/lib/node_modules/cloudron-surfer/node_modules/superagent/lib/node/index.js:894:12)
    at /usr/local/lib/node_modules/cloudron-surfer/node_modules/superagent/lib/node/index.js:1127:20
    at IncomingMessage.<anonymous> (/usr/local/lib/node_modules/cloudron-surfer/node_modules/superagent/lib/node/parsers/json.js:22:7)
    at Stream.emit (events.js:314:20)
    at Unzip.<anonymous> (/usr/local/lib/node_modules/cloudron-surfer/node_modules/superagent/lib/node/unzip.js:53:12)

[nebulon]

Interesting behavior. For a start I've published the latest cli version to npm (so cloudron-surfer@5.12.1 )
This version has the syncing/uploading parts rewritten to avoid re-uploading unchanged files.
Could you update this and see where it breaks then?

[fbartels]

Updating is easy.

+ surfer --version
5.12.1
+ stat public/.
  File: public/.
  Size: 242       	Blocks: 0          IO Block: 4096   directory
Device: 21h/33d	Inode: 4999809     Links: 1
Access: (0755/drwxr-xr-x)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 1754-08-30 22:43:41.000000000
Modify: 2020-12-09 13:41:18.000000000
Change: 2020-12-09 13:41:18.000000000

+ touch public/
+ surfer put --token $SURFTOKEN --server blog.9wd.eu public/* /
Using server https://blog.9wd.eu
/usr/local/lib/node_modules/cloudron-surfer/cli/actions.js:324
                if (remote.filePath !== path.join(absoluteDestPath, local.filePath)) return false;
                                                                          ^

TypeError: Cannot read property 'filePath' of undefined
    at /usr/local/lib/node_modules/cloudron-surfer/cli/actions.js:324:75
    at Array.find (<anonymous>)
    at /usr/local/lib/node_modules/cloudron-surfer/cli/actions.js:323:33
    at Array.filter (<anonymous>)
    at /usr/local/lib/node_modules/cloudron-surfer/cli/actions.js:322:36
    at Request.callback (/usr/local/lib/node_modules/cloudron-surfer/node_modules/superagent/lib/node/index.js:894:12)
    at /usr/local/lib/node_modules/cloudron-surfer/node_modules/superagent/lib/node/index.js:1127:20
    at IncomingMessage.<anonymous> (/usr/local/lib/node_modules/cloudron-surfer/node_modules/superagent/lib/node/parsers/json.js:22:7)
    at Stream.emit (events.js:326:22)
    at Unzip.<anonymous> (/usr/local/lib/node_modules/cloudron-surfer/node_modules/superagent/lib/node/unzip.js:53:12)

[nebulon]

Hm looking at the code I can't seem to figure out how that could ever be undefined, I need to debug this and thus be able to reproduce it. Do you have any idea how we could do that?
Given the other atime issue, I am a bit worried about either the node version in your image or some other stripped down dependency causing this. I don't want to put code guards in to just not make it crash without understanding the root cause.

I guess I have to spin up a node:lts-alpine3.12 container and see if I can reproduce this, or do you have your exact setup as a public image I could just docker pull?

[fbartels]

The timestamp issue seems to be already known for Hugo (which is what I am using for my blog): https://github.com/gohugoio/hugo/issues/6161

You could pull my image from https://hub.docker.com/r/fbartels/cloudron-surfer.

If you think this could have something to do with the alpine image I am also open to converting it into a Debian based one.

[nebulon]

@fbartels who do you run surfer within that image in your case? Is there a volume mounted into the container which you then run the surfer put against?

[vjvanjungg]

@nebulon Also experiencing this issue (Surfer CLI 5.12.1). Seems to happen with Hugo. Last I tried with Gridsome it worked.

/usr/local/lib/node_modules/cloudron-surfer/cli/actions.js:324
                if (remote.filePath !== path.join(absoluteDestPath, local.filePath)) return false;
                                                                          ^
TypeError: Cannot read property 'filePath' of undefined
    at /usr/local/lib/node_modules/cloudron-surfer/cli/actions.js:324:75
    at Array.find (<anonymous>)
    at /usr/local/lib/node_modules/cloudron-surfer/cli/actions.js:323:33
    at Array.filter (<anonymous>)
    at /usr/local/lib/node_modules/cloudron-surfer/cli/actions.js:322:36
    at Request.callback (/usr/local/lib/node_modules/cloudron-surfer/node_modules/superagent/lib/node/index.js:894:12)
    at /usr/local/lib/node_modules/cloudron-surfer/node_modules/superagent/lib/node/index.js:1127:20
    at IncomingMessage.<anonymous> (/usr/local/lib/node_modules/cloudron-surfer/node_modules/superagent/lib/node/parsers/json.js:22:7)
    at Stream.emit (events.js:315:20)
    at Unzip.<anonymous> (/usr/local/lib/node_modules/cloudron-surfer/node_modules/superagent/lib/node/unzip.js:53:12)

[nebulon]

Hm I can't really reproduce this on my side, neither with using @fbartels alpine based image nor otherwise.

Maybe I am misunderstanding the use-case though, so if I simply run:

run fbartels/cloudron-surfer:5.12.1 surfer put --server https://files.nebulon.space  --token $TOKEN /var/ /

this works just fine.

[fbartels]

In my case the surfer container is run as part of a Drone pipeline, so the pwd is /drone/src at the time of execution. Based on @vjvanjungg comment I also tried it now directly on my system and while an almost blank Hugo blog succeeds in uploading with the server cli, a build of my blog shows the exact same error (maybe that makes it easier to debug, since I can then easily modify files).

@nebulon said in Surfer CLI 5.11.0 fails to upload:

Maybe I am misunderstanding the use-case though, so if I simply run:

yes, almost. except that I am using a * to upload all files in that folder.

Hmm. also their example site uploads just fine... https://github.com/gohugoio/hugoBasicExample. So it must be something in relation to the file that get generated for my blog.

[girish]

@nebulon Could it be crash is because of https://git.cloudron.io/cloudron/surfer/-/blob/master/cli/actions.js#L56 ? It should be returning tmp ? Because it then gets passed to concat (as undefined) and thus the crash ?

[nebulon]

@girish that must be it! I will prepare a new update for the cli then.

[nebulon]

At least for the undefined bug this should then hopefully be fixed with cloudron-surfer@5.12.2 cli.

[fbartels]

@nebulon thanks! Indeed the upload now succeeds with the new version. For the wrong timestamp i'll just touch the folder once before calling surfer. Maybe it eventually gets fixed in hugo itself.