Storing the metadata for a directory.

[Rob Browning]

Given

100644 blob cb55c8403baaa31417c53667da3d66da2bbe7cd8 .bupm
100644 blob f0cf5abf1c6d0b01c40bee1631f8345ff5440981 home/.bupm
100644 blob 1444596eb39adab8a0574aea0b48fb059d20cbc3 home/rlb/.bupm
...

Where should the metadata for a directory like /home/rlb go?

The impression I'd gotten from previous discussions was that it should
go in /home/.bupm, but if so, we'll need to come up with a way to handle
the metadata for '/'.

Thanks
--
Rob Browning
rlb @defaultvalue.org and @debian.org
GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4

[Rob Browning]

Rob Browning <r...@defaultvalue.org> writes:

> Given
>
> 100644 blob cb55c8403baaa31417c53667da3d66da2bbe7cd8 .bupm
> 100644 blob f0cf5abf1c6d0b01c40bee1631f8345ff5440981 home/.bupm
> 100644 blob 1444596eb39adab8a0574aea0b48fb059d20cbc3 home/rlb/.bupm
> ...
>
> Where should the metadata for a directory like /home/rlb go?
>
> The impression I'd gotten from previous discussions was that it should
> go in /home/.bupm, but if so, we'll need to come up with a way to handle
> the metadata for '/'.

Ping.

[Avery Pennarun]

On Thu, Mar 31, 2011 at 12:35 AM, Rob Browning <r...@defaultvalue.org> wrote:
> Given
>
>  100644 blob cb55c8403baaa31417c53667da3d66da2bbe7cd8    .bupm
>  100644 blob f0cf5abf1c6d0b01c40bee1631f8345ff5440981    home/.bupm
>  100644 blob 1444596eb39adab8a0574aea0b48fb059d20cbc3    home/rlb/.bupm
>  ...
>
> Where should the metadata for a directory like /home/rlb go?
>
> The impression I'd gotten from previous discussions was that it should
> go in /home/.bupm, but if so, we'll need to come up with a way to handle
> the metadata for '/'.

Good point. Perhaps we can put the metadata for a tree *and* all its
contents into the .bupm file each tree?

That is, the metadata file has entries for "" (the empty string, ie.
current directory, and conveniently alphabetically first) followed by
all the entries for the files in the current directory, but *not*
including subdirs.

Does that work?

Avery

[Rob Browning]

Avery Pennarun <apen...@gmail.com> writes:

> That is, the metadata file has entries for "" (the empty string, ie.
> current directory, and conveniently alphabetically first) followed by
> all the entries for the files in the current directory, but *not*
> including subdirs.
>
> Does that work?

Offhand, sounds like the same behavior as "." in many filesystems, so it
should work fine.

[Rob Browning]

Avery Pennarun <apen...@gmail.com> writes:

(Back to working on this...)

So at least for save/restore, if the metadata file won't actually have
any path names -- it only contains the metadata records for each file in
the current directory, in the same order they appear in the
corresponding tree object.

But perhaps we could just arrange it so that a .bupm file always
contains one extra initial set of records for ".". i.e.

tree .bupm
metadata for "."
"a" metadata for "a"
"b" metadata for "b"
"c" metadata for "c"

Does that sound reasonable?

[Rob Browning]

Rob Browning <r...@defaultvalue.org> writes:

> Avery Pennarun <apen...@gmail.com> writes:

>> Good point. Perhaps we can put the metadata for a tree *and* all its
>> contents into the .bupm file each tree?
>>
>> That is, the metadata file has entries for "" (the empty string, ie.
>> current directory, and conveniently alphabetically first) followed by
>> all the entries for the files in the current directory, but *not*
>> including subdirs.
>>
>> Does that work?
>
> (Back to working on this...)
>
> So at least for save/restore, if the metadata file won't actually have
> any path names -- it only contains the metadata records for each file in
> the current directory, in the same order they appear in the
> corresponding tree object.
>
> But perhaps we could just arrange it so that a .bupm file always
> contains one extra initial set of records for ".". i.e.
>
> tree .bupm
> metadata for "."
> "a" metadata for "a"
> "b" metadata for "b"
> "c" metadata for "c"
>
> Does that sound reasonable?

OK, that's what I've done, and it works fine.

Thanks