Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Create hash directory in SaveBlob if isHashed #11

Closed
wants to merge 1 commit into from
Closed

Create hash directory in SaveBlob if isHashed #11

wants to merge 1 commit into from

Conversation

avelner
Copy link

@avelner avelner commented Jun 19, 2017

Hi, got errors from rest server when setting a repo name rest:http://user:pass@127.0.0.1:8000/XXX
the "hash" dir was not created.

@fd0
Copy link
Member

fd0 commented Jun 19, 2017

Hm, what's the exact version number of the rest-server (use git describe) and restic (run restic version)?

The subdirs for the data dir are created, here: https://github.com/restic/rest-server/blob/master/handlers.go#L332-L338

@avelner
Copy link
Author

avelner commented Jun 19, 2017 via email

@zcalusic
Copy link
Member

Huh, but how was it created then? Even if you created local repo and later on decided to serve it via rest-server, you'd still have all hash folders created on init, from what I remember.

I don't like adding extra os.Stat() call in the hot path, however cheap it may be, to allow for code that should basically be a noop. Unless you can explain how you ended up with a working repo, but no hash directories? Maybe there's a better solution which would not slow down every access?

@fd0
Copy link
Member

fd0 commented Jun 20, 2017

I'll address this in restic. @avelner in the meantime, you can just create the directories yourself, like this:

for i in {0..255}; do mkdir $(printf "data/%02x" $i); done

Run this in the repository directory.

@zcalusic
Copy link
Member

zcalusic commented Jun 20, 2017

Ah, I stand corrected. Local backend really doesn't pre create all hash folders, but creates them on the fly.

But, it's still better to fix this slight incompatibility in the client itself, so then we won't need to have extra code/system calls in either of them.

Anyways, thank you very much @avelner for PR and noticing this issue, which somehow flew below radar for a rather long time. :)

@avelner
Copy link
Author

avelner commented Jun 22, 2017 via email

@zcalusic
Copy link
Member

I believe people already asked about read-only, what is actually append-only or something. I'm fine with that. @fd0, what's your take on it, can it work that way?

There's a possibility restic client might need a slight update to better cope with errors from this mode. Lest we get some panics or something. :)

But, please open a new issue/PR for that. I'm keeping this one open just to remember to update the documentation when @fd0 releases the new versions with fixes for this issue.

@fd0
Copy link
Member

fd0 commented Jun 25, 2017

Nice, a read-only option for the rest-server is a great idea. It should prevent removing data, index, key and snapshot files. Only lock files may be removed.

@avelner
Copy link
Author

avelner commented Jun 25, 2017 via email

@fd0 fd0 mentioned this pull request Jun 28, 2017
@zcalusic zcalusic closed this in 9a6bb5e Jul 22, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants