Create hash directory in SaveBlob if isHashed

[avelner]

Hi, got errors from rest server when setting a repo name rest:http://user:[email protected]:8000/XXX
the "hash" dir was not created.

[fd0]

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]

Hi, problem is with repositories which are not created via the rest-server. $ git describe v0.9.2-4-g6b82113 $ restic version restic 0.6.1 (v0.6.1-115-g53f8026) compiled with go1.8.3 on linux/amd64 Met vriendelijke groet,

…

-- Arjan Velner 2017-06-19 15:25 GMT+02:00 Alexander Neumann <[email protected]>:

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 — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#11 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AJmE8ljJIiH3vbh5CrH30PSe6lq770_sks5sFnbPgaJpZM4N-M28> .

[zcalusic]

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]

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]

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]

Hi, sorry for the late reply, was at google next in amsterdam yesterday. have also an option for the restic server which makes it "readonly", it's baiscly the following lines in DeleteBlob, only need to add a commandline flag to enable it, but haven't done that yet, still testing if it works correct. if /* readonly flag is set && */ dir != "locks" { http.Error(w, http.StatusText(http.StatusMethodNotAllowed), http.StatusMethodNotAllowed) return } Do you want it for the rest-server? My use is that a server should not be able to delete its own bakcup files. 2017-06-20 22:37 GMT+02:00 Zlatko Čalušić <[email protected]>:

…

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 neither of them. Anyways, thank you very much @avelner <https://github.com/avelner> for PR and noticing this issue, which somehow flew below radar for a rather long time. :) — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#11 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AJmE8rW8J7TP58IjesDidIvRis91HW0Lks5sGC2QgaJpZM4N-M28> .

-- Met vriendelijke groet,

-- Arjan Velner

[zcalusic]

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]

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]

Hi, already made andere tested, wil make an issue and pull request, bit busy the last few days, cliënt does not yet give nice messages when doing write operations. Will change that too. Met vriendelijke groet,

…

-- Arjan Velner Op 25 jun. 2017 10:02 schreef "Alexander Neumann" <[email protected]

: 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. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#11 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AJmE8ufdv6Tt7OxGWINJqcYNd94t8fKeks5sHhQDgaJpZM4N-M28> .