Some usability issues with dat-store and local folders

[gohai]

Hello @RangerMauve,

Here some observations I had trying to use dat-store. Those might not be bugs at all, so feel free to close!

I am running the dat-store service as an unprivileged (nodejs) user, in order to contain any possible damage... When I am running dat-store add . on a directory as my main user, I am getting the following error

{ Error: socket hang up
    at createHangUpError (_http_client.js:323:15)
    at Socket.socketOnEnd (_http_client.js:426:23)
    at Socket.emit (events.js:203:15)
    at endReadableNT (_stream_readable.js:1145:12)
    at process._tickCallback (internal/process/next_tick.js:63:19) code: 'ECONNRESET' }

This is caused by the service user not being able to write to the files in /.dat. It starts working when I set mode 0666 on all files inside /.dat. Perhaps a more descriptive error message could help young players (like myself)? (I hadn't initially considered permissions to be an issue, since I was running the dat-store command in the context of my main user that also owned the files.)

Secondly: I presumed that The store will load up the dat archive inside your folder, watch for changes, and share them with the rest of the network. would mean that the dat-store service would watch for files that get modified in the directory, and automatically add them to the Dat archive, but it looks like one still manually does dat sync?

Thanks & best

[RangerMauve]

Thank you for the bug report @gohai! 💜

I'm not sure why that error would be popping up from. Do you have any suggestions as to how to safely detect if the process has sufficient permission to access a file?

Also, what do you think about breaking compatilbility with the current dat cli and just using dat-store add ./ to create archives and not having a dat init step at all.

Regarding file sync, what did you do test it? The unit tests seem to be working correctly for the file watching test. 🤔

[gohai]

Thank you for looking into this @RangerMauve

Regarding the error: I believe this is shown when some part of dat-store add is writing to files contained in ./.dat/. I don't understand the structure of dat-store that well myself, but at least addFolder() in library.js calls saveFolders()...? (not sure if adding exception handling code there would make a difference, or why the stack trace above is in the context of process._tickCallback ¯_(ツ)_/¯)

Regarding file sync - here is my test case:

mkdir /tmp/foo
cd /tmp/foo
dat init .
chmod a+w -R .dat/
dat-store add .
echo "foo" > bar

But when I try to clone the archive (e.g. via dat clone dat:// in a different terminal), I am not ever seeing the file bar show up. It does when I run dat sync, and then exit out.

[RangerMauve]

Hmmm, the stack trace looks like it was caused by a network error of some sort. 🤔

I'll try to reproduce the file watching case locally this week. It seems like it should be working.

[RangerMauve]

Did you dat init with the same user as the store? The private key for an archive gets saved to the ~/.dat folder for the current user with the CLI. If the store can't load the private key, it won't be able to sync changes from the folder.

[gohai]

You're right - different user. The secret_keys inside ~/.dat would actually even be readable to everyone (seems to be the default), but I presume dat-store doesn't know in which user directory to look for them :(

My motivation why I rather not run dat-store as my regular user is that it has sudo rights (w/o a password).

[RangerMauve]

I'm going to be adding the ability for dat-store to turn a directory into a Dat archive (by the store's process) so we won't need the CLI to create the initial folder.

[gohai]

That would certainly help!

(Another idea I had was having dat-store add . read the private key from the current user's ~/.dat and pass it to the daemon to store under its home directory as well - in the case the two are having different uids.)

[RangerMauve]

This has been added in the latest version! 😁