find-new possibility of showing modified and deleted files/directories

find-new possibility of showing modified and deleted files/directories

[Shane Spencer]

Currently find-new only shows certain operations and probably for a great
reason.

I'm trying to use find-new to preseed a file list to rsync so that I don't
have to traverse incredibly large directory trees.

Unfortunately find-new doesn't show deletion and a few other modifications.

I'm very tempted to use snapshots and decode a transfer log to get at this
information since that seems the most supportable way of doing this at the
moment.

Is it possible to enable all file modification types into the results of
find-new including unlink?

- Shane

Re: find-new possibility of showing modified and deleted files/directories

[Shane Spencer]

That's Plan B.  I'll be making a btrfs stream decoder and doing in
place edits.  I need to move stuff around to other filesystem types
otherwise I'd just store the stream or apply the stream to a remote
snapshot.

On Wed, Oct 31, 2012 at 4:13 PM, cwillu <cwillu@gmail.com> wrote:
> Probably easier to decode the btrfs-send stream, or even just use btrfs-send
> itself instead.

Re: find-new possibility of showing modified and deleted files/directories

[Arne Jansen]

On 11/01/2012 02:28 AM, Shane Spencer wrote:
> That's Plan B.  I'll be making a btrfs stream decoder and doing in
> place edits.  I need to move stuff around to other filesystem types
> otherwise I'd just store the stream or apply the stream to a remote
> snapshot.

That's the whole point of the btrfs-send design: It's very easy to
receive on different filesystems. A generic receiver is in preparation.
And to make it even more generic: A sender using the same stream
format is also in preparation for zfs.

> 
> On Wed, Oct 31, 2012 at 4:13 PM, cwillu <cwillu@gmail.com> wrote:
>> Probably easier to decode the btrfs-send stream, or even just use btrfs-send
>> itself instead.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Re: find-new possibility of showing modified and deleted files/directories

[Gabriel]

On Thu, 01 Nov 2012 06:06:57 +0100, Arne Jansen wrote:
> On 11/01/2012 02:28 AM, Shane Spencer wrote:
>> That's Plan B.  I'll be making a btrfs stream decoder and doing in
>> place edits.  I need to move stuff around to other filesystem types
>> otherwise I'd just store the stream or apply the stream to a remote
>> snapshot.

> That's the whole point of the btrfs-send design: It's very easy to
> receive on different filesystems. A generic receiver is in preparation.
> And to make it even more generic: A sender using the same stream format
> is also in preparation for zfs.

Consider the rsync bundle format as well.
That should provide interoperability with any filesystem.

Re: find-new possibility of showing modified and deleted files/directories

[Arne Jansen]

On 01.11.2012 12:00, Gabriel wrote:
> On Thu, 01 Nov 2012 06:06:57 +0100, Arne Jansen wrote:
>> On 11/01/2012 02:28 AM, Shane Spencer wrote:
>>> That's Plan B.  I'll be making a btrfs stream decoder and doing in
>>> place edits.  I need to move stuff around to other filesystem types
>>> otherwise I'd just store the stream or apply the stream to a remote
>>> snapshot.
> 
>> That's the whole point of the btrfs-send design: It's very easy to
>> receive on different filesystems. A generic receiver is in preparation.
>> And to make it even more generic: A sender using the same stream format
>> is also in preparation for zfs.
> 
> Consider the rsync bundle format as well.
> That should provide interoperability with any filesystem.

Rsync is an interactive protocol. The idea with send/receive is that
the stream can be generated without any interactions with receiver.
You can store the stream somewhere, or replay it to many destinations.

> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: find-new possibility of showing modified and deleted files/directories

[Gabriel]

On Thu, 01 Nov 2012 12:29:36 +0100, Arne Jansen wrote:
> On 01.11.2012 12:00, Gabriel wrote:
>> On Thu, 01 Nov 2012 06:06:57 +0100, Arne Jansen wrote:
>>> On 11/01/2012 02:28 AM, Shane Spencer wrote:
>>>> That's Plan B.  I'll be making a btrfs stream decoder and doing in
>>>> place edits.  I need to move stuff around to other filesystem types
>>>> otherwise I'd just store the stream or apply the stream to a remote
>>>> snapshot.
>> 
>>> That's the whole point of the btrfs-send design: It's very easy to
>>> receive on different filesystems. A generic receiver is in
>>> preparation.
>>> And to make it even more generic: A sender using the same stream
>>> format is also in preparation for zfs.
>> 
>> Consider the rsync bundle format as well.
>> That should provide interoperability with any filesystem.
> 
> Rsync is an interactive protocol. The idea with send/receive is that the
> stream can be generated without any interactions with receiver. You can
> store the stream somewhere, or replay it to many destinations.

Same with rsync's batch mode. Here is more about it:

http://manpages.ubuntu.com/manpages/precise/man1/rsync.1.html#contenttoc21

Re: find-new possibility of showing modified and deleted files/directories

[Shane Spencer]

On Wed, Oct 31, 2012 at 9:06 PM, Arne Jansen <sensille@gmx.net> wrote:
>
> On 11/01/2012 02:28 AM, Shane Spencer wrote:
> > That's Plan B.  I'll be making a btrfs stream decoder and doing in
> > place edits.  I need to move stuff around to other filesystem types
> > otherwise I'd just store the stream or apply the stream to a remote
> > snapshot.
>
> That's the whole point of the btrfs-send design: It's very easy to
> receive on different filesystems. A generic receiver is in preparation.
> And to make it even more generic: A sender using the same stream
> format is also in preparation for zfs.
>

You just made my day. I will probably be approaching a lot of this
from Python as well so I'm very interested in the stream format
itself.