filelist calculation algoritm
Aaron Morris
aaronmorris at mindspring.com
Sat Jan 4 21:01:01 EST 2003
Please bear in mind that I am quickly approacing areas where I have
little expertise.
Commenting on the recursion issue:
I thought rsync already takes intermediate directories into account. If
you specify -p, does not rsync create the intermediate directories with
the same perms as the source (and change them to the source perms if the
directory already exists with different perms).
I may not understand what you mean by disabling recursion, but I think
it would defeat half the purpose of being able to use a file for a file
list. Instead of being able to just specify a directory and rsync
transfer the directory and contents recursively, you would have to
specify all the files in the directory.
jw schultz wrote:
> On Sat, Jan 04, 2003 at 08:00:20PM +0100, wim delvaux wrote:
>
>>On Saturday 04 January 2003 19:49, Aaron Morris wrote:
>>
>>>It has already been suggested in this list, as well as by myself in the
>>>rsync wishlist for a new option to specify a file that has a list of
>>>files to be transferred.
>>
>> Perhaps i need to have a look a the sources and see what it takes
>> to put that option in (say --files)
>
>
> This appears to be the most frequently requested feature.
>
> I think it will be reasonable to do we just need correctly
> add the list entries to flist with the proper basename.
>
> We keep the source argument on the command-line so that a
> top-of-the-tree is specified. I think we need two types of
> file lists. One specifying subpaths and the other for those
> having a shared prefix. I lean to using two forms to
> specify the list rather than a list specifier and a list
> mode option. Regardless of the type of list the argument
> count remains the same. I my examples below is show
> reading the list from stdin by using the "-" convention. I
> expect that an actual filename would also be valid.
>
> The one specifying subpaths I'd call --file-list-relative
> and each entry would be relative to the top of the tree.
>
> doing
> rsync --file-list-relative - src dest <<EOL"
> file1
> file2
> dir1/file3
> EOL
> would actually sync
> src/file1
> src/file2
> src/dir1
> src/dir1/file3
> to
> dest/file1
> dest/file2
> dest/dir1
> dest/dir1/file3
>
> In this way you could construct a file list and leave it in
> a file for reuse without requiring that the CWD of the rsync
> process be always in the same location. This should
> automatically ignore a ./ prefix in the list.
>
> The --file-list-relative would be independent of --relative
> It might be that someone else will have a better name for
> this.
>
> The shared prefix form would be the default and would
> require each entry to be prefixed by the source path.
> This form does mean that the contents of the file-list will
> determine the required CWD for the rsync process.
>
> doing
> rsync --file-list - src dest <<EOL"
> src/file1
> src/file2
> src/dir1/file3
> EOF
> would sync
> src/file1
> src/file2
> src/dir1/file3
> to
> dest/file1
> dest/file2
> dest/dir1/file3
>
> This would allow constructions like
> find srcdir | myfilter | rsync --file-list - srcdir destloc
>
> One thing this will need to do is to cope with implied
> directories. What i mean by that is that any intermediate
> directories that are not explicitly specified but require
> existence should be added to the list. In the examples
> above dir1 is implied so it is synced. I bring this up
> because it would be undesirable to have a directory on the
> destination created with less stringent permissions than on
> the source.
>
> For this implicit directory stuff to work recursion should
> be disabled. I would recommend that the --file-list*
> options explicitly disable recursion even if it was
> otherwise specified. Recursion disablement will avoid
> confusion and allow continued use of combo-options like
> -a.
>
--
Aaron W Morris
decep
PGP Key ID: 259978D1
More information about the rsync
mailing list