How to rename a backup set and/or fix the issue?

[igory...@gmail.com]

I've created a backup set with a slash '/' in the path, or, at least, I think, this is causing the problem. with the following commands:

bup index /mnt/cifs/0.12.$var_shar/
bup index --check /mnt/cifs/0.12.lotus_f/lotusChAO/
bup save -n 0.12.lotus_f/lotusChAO /mnt/cifs/0.12.lotus_f/lotusChAO/

It successfully indexed and saved everything, but I cannot list the backup after it.
When I do:

bup ls

It shows me:

0.12.lotus_f/lotusChAO

When I try to do either of the following commands:

bup ls 0.12.lotus_f/lotusChAO
bup ls 0.12.lotus_f/lotusChAO/
bup ls 0.12.lotus_f/
bup ls lotusChAO
bup ls lotusChAO/
bup ls 0.12.lotus_f\/lotusChAO/
bup ls 0.12.lotus_f/lotusChAO/latest/

I get errors (depending on the path, given) like that:

error: no file '0.12.lotus_f' in '/'
error: no file 'lotusChAO' in '/'

Tried to ls with a hash:

bup ls -s

After getting the hash, tried to do:

bup ls a917e01b8ae0c207a8993b1211361ec18c119c5c/

It gave me:

error: no file 'a917e01b8ae0c207a8993b1211361ec18c119c5c' in '/'

How to rename the backup set from '0.12.lotus_f/lotusChAO' to, like '0.12.lotus_f', or some other way to fix this issue.
I've read all the docs, that I could find and searched on the internet, but couldn't find anything, that could help.

My environment, where bup is installed:

Ubuntu server 16.04.1 LTS, kernel: 4.4.0-89-generic, x86_64
BUP version: debian/0.27-2 (the latest from the binary ubuntu repo).

[Rob Browning]

igory...@gmail.com writes:

> I've created a backup set with a slash '/' in the path, or, at least, I
> think, this is causing the problem. with the following commands:

>> bup save -n 0.12.lotus_f/lotusChAO /mnt/cifs/0.12.lotus_f/lotusChAO/

Yes, I suspect that might be the problem. For the time being I'd avoid
slashes in save names. While git doesn't care, the current bup vfs
(and/or the tools built on it might not work right).

I think we figured out a way we might address that a while back, but
I don't think anything's been implemented.

> How to rename the backup set from '*0.12.lotus_f/lotusChAO*' to, like '
> *0.12.lotus_f*', or some other way to fix this issue.

> I've read all the docs, that I could find and searched on the internet, but
> couldn't find anything, that could help.

I suspect this should work (you might want to save a copy of
BUP_REPO/refs in case something goes wrong):

git --git-dir BUP_REPO branch some-other-new-name 0.12.lotus_f/lotusChAO

Then if everything's fine, you could remove the old name, but it won't
hurt anything to just leave it alone (unless you plan to use rm/gc):

git --git-dir BUP_REPO branch --delete 0.12.lotus_f/lotusChAO

Hope this helps.
--
Rob Browning
rlb @defaultvalue.org and @debian.org
GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A
GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4

[Iar De]

Thank You:

git --git-dir $BUP_DIR branch some-other-new-name 0.12.lotus_f/lotusChAO

worked, and the new name is browsable, but --delete 0.12.lotus_f/lotusChAO didn't work. It gave me:

fatal: Couldn't look up commit object for HEAD

when tried to delete the old name. So, I am, probably, stuck with it for eternity :).

понедельник, 11 сентября 2017 г., 18:23:32 UTC+12 пользователь Rob Browning написал:

[Greg Troxel]

Iar De <igory...@gmail.com> writes:

> Thank You:
>
> *git --git-dir $BUP_DIR branch some-other-new-name 0.12.lotus_f/lotusChAO*
>
> worked, and the new name is browsable, but *--delete 0.12.lotus_f/lotusChAO*

> didn't work. It gave me:
>

> *fatal: Couldn't look up commit object for HEAD*

>
> when tried to delete the old name. So, I am, probably, stuck with it for
> eternity :).

Try using raw git, not bup.

If all else fails, you can manually adjust refs/heads, but make sure you
really understand git repo structure first!

It might be good for bup to throw an error on having / in a save name.
Even if it can be made to work mostly, it's still going to be trouble
that I think it's a net win to just ban it.

(I don't even like using / inside a git ref, because git uses
origin/name, and I therefore view / as reserved, even though it isn't.)

[Iar De]

Well, the error is from raw git:

git --git-dir $BUP_DIR branch --delete 0.12.lotus_f/lotusChAO

I will, probably look into editing refs/heads after reading ProGit or some similar book.

понедельник, 11 сентября 2017 г., 23:19:20 UTC+12 пользователь Greg Troxel написал:

[Rob Browning]

Iar De <igory...@gmail.com> writes:

> worked, and the new name is browsable, but *--delete 0.12.lotus_f/lotusChAO*

> didn't work. It gave me:
>

> *fatal: Couldn't look up commit object for HEAD*

>
> when tried to delete the old name. So, I am, probably, stuck with it for
> eternity :).

Hah, no - I suspect it's just that "branch --delete" is grouchy about
the (bare) repo. How about this?

git --git-dir "$BUP_DIR" update-ref -d 0.12.lotus_f/lotusChAO

[Rob Browning]

Greg Troxel <g...@lexort.com> writes:

> It might be good for bup to throw an error on having / in a save name.
> Even if it can be made to work mostly, it's still going to be trouble
> that I think it's a net win to just ban it.

Actually we did:

commit 52a98179490c6ccb990e221bbdeb511f1de59de4
Author: Rob Browning <r...@defaultvalue.org>
Date: Mon Jan 27 14:51:47 2014 -0600

save-cmd.py: disallow backup set names containing "/".

There's no way to refer to them via the VFS, because the VFS (as
expected) treats all forward slashes as path separators.

Before this change, it was possible to create backup sets with names
like "x/y/z" that were inaccessible via ls, restore, etc.

Thanks to Laura Morrissey <laura.m...@gmail.com> for the report.

and then I backed it out before the release (0.26):

commit a5189a69a8e37f7ed5b43af314f9ec35bbfbb910
Author: Rob Browning <r...@defaultvalue.org>
Date: Wed May 14 10:24:00 2014 -0500

Re-allow backup set names containing "/"

Revert the prohibition because all releases up to now have allowed
"/", and so that's nothing new. Disabling "/" in 0.26 would be a
regression, and one we're not ready to commit to -- in fact, we may
eventually do the opposite, and add comprehensive support for "/".

This reverts commit 52a98179490c6ccb990e221bbdeb511f1de59de4.

But of course that doesn't mean we have to leave it that way.

I believe there was discussion on the list, but don't recall the details
offhand. In any case, it seems worth thinking about as we consider
vfs2.

Thanks

[Iar De]

git --git-dir "$BUP_DIR" update-ref -d 0.12.lotus_f/lotusChAO

worked without errors, but doing 'bup ls' still showed '0.12.lotus_f/lotusChAO' in list.
So, I thought, that I probably need to follow the above command with the '--delete' version and I did:

git --git-dir "$BUP_DIR" update-ref -d 0.12.lotus_f/lotusChAO

git --git-dir $BUP_DIR branch --delete 0.12.lotus_f/lotusChAO

the 1st command performed without error, the second command gave me the same error, as before:

fatal: Couldn't look up commit object for HEAD

bup ls still shows '0.12.lotus_f/lotusChAO' in listing.

вторник, 12 сентября 2017 г., 18:06:58 UTC+12 пользователь Rob Browning написал:

[Rob Browning]

Iar De <igory...@gmail.com> writes:

> git --git-dir "$BUP_DIR" update-ref -d 0.12.lotus_f/lotusChAO
>
> worked without errors, but doing 'bup ls' still showed
> '0.12.lotus_f/lotusChAO' in list.
> So, I thought, that I probably need to follow the above command with the
> '--delete' version and I did:
>
> git --git-dir "$BUP_DIR" update-ref -d 0.12.lotus_f/lotusChAO
> git --git-dir $BUP_DIR branch --delete 0.12.lotus_f/lotusChAO
>
> the 1st command performed without error, the second command gave me the
> same error, as before:

At this point, I wouldn't expect branch --delete to work, but I wonder
why update-ref didn't get rid of the branch. Do you still see that
branch here?

find "$BUP_DIR"/refs/heads

[Iar De]

понедельник, 18 сентября 2017 г., 4:37:55 UTC+12 пользователь Rob Browning написал:

Iar De <igory...@gmail.com> writes:

> git --git-dir "$BUP_DIR" update-ref -d 0.12.lotus_f/lotusChAO
>
> worked without errors, but doing 'bup ls' still showed
> '0.12.lotus_f/lotusChAO' in list.
> So, I thought, that I probably need to follow the above command with the
> '--delete' version and I did:
>
> git --git-dir "$BUP_DIR" update-ref -d 0.12.lotus_f/lotusChAO
> git --git-dir $BUP_DIR branch --delete 0.12.lotus_f/lotusChAO
>
> the 1st command performed without error, the second command gave me the
> same error, as before:

At this point, I wouldn't expect branch --delete to work, but I wonder
why update-ref didn't get rid of the branch.  Do you still see that
branch here?

  find "$BUP_DIR"/refs/heads

Given, that my BUP_DIR='/mnt/nas/0.232/bkp/_bup/lotus/0.12', I've got the following results:

/mnt/nas/0.232/bkp/_bup/lotus/0.12/refs/heads/0.12.lotus_f
/mnt/nas/0.232/bkp/_bup/lotus/0.12/refs/heads/0.12.lotus_f/lotusChAO

and cat /mnt/nas/0.232/bkp/_bup/lotus/0.12/refs/heads/0.12.lotus_f/lotusChAO gives me a hash content:

a917e01b8ae0c207a8993b1211361ec18c119c5c

[Tim Riemenschneider]

That's because "git branch --delete" checks if the branch-to-be-deleted is merged upstream or in HEAD, which fails because there is no HEAD or upsteam.

you can use "git branch -D" to delete the branch (see also "man git-branch")

[Tim Riemenschneider]

Yes, quite some time ago Stefan Buller made branchnames with slashes work, which I rebased some time to newer versions of bup.

But most user here on the list considered names with slashes a bad idea, so that was never merged.

(My last rebase is still available on https://github.com/timri/bup/commits/proposed/ref-names-with-slashes , but look at the dates ;-)

I do not maintain that branch anymore, since I don't use that feature anymore.

(Before there was a working "rm" in bup, I used branches like "home/2016-01-01" in a one-save-per-branch way. I could then remove older saves by "git branch -D home/2016-01-01".

I eventually moved to branchnames "home_2016_01_01" for some time.

Now with a working "bup rm", I moved over to using a single branch per LVM ("home" in this example), since specially "bup prune-older" does not work otherwise ;-) )

The main problem with slashes in branchnames is the fact, that the vfs (v1) spans ALL commits as one big tree, whereas git makes a distinction between branchnames and pathnames.

So (if a slash is allowed in branchnames), there is no indication where the branchname ends, the commit timestamp is and a path inside a save begins.

(save/with/slashes/latest/latest/latest/some/path:

Is that

- the most current commit in the branch "save/with/slashes" with containing a path "latest/latest/some/path"?

- or the most current commit in "save/with/slashes/latest" with a path "latest/some/path"?

- or even the most current commit in "save/with/slashes/latest/latest" with path "some/path"?)

So I would see these options:

- disallow "/" on save / split (like your reverted commit) (or at least warn about them)

- bring the "ref-names-with-slashes"-branch up to current master, and only warn/document the ambiguity

- use different separators for the different meanings (just like git does), f.e. in your vfs2 (since this breaks backward compatibility)

(f.e.

"bup restore save/with/slashes@latest:some/path/into/the/save"

"bup restore save/with/slashes@2017-09-19-120102:some/path/into/the/save"

or even more like "git rev-parse" (man git-rev-parse):

bup restore save/with/slashes@{datespec}:path/spec

bup restore save/with/slashes@{one week ago}:path/to/file

or maybe even:

bup restore save/with/slashes latest some/path

)