search

loh-tar / cpd

A pure bash script to collect copy jobs and start them only if the target drive is not busy by any other job under supervision of cpd
GNU General Public License v2.0
2 stars 1 forks source link

Why isn't -R a cp-opt? #2

Closed Ambrevar closed 6 years ago

Ambrevar commented 6 years ago

-R is a cpd option and I see in the source that cpd has a special provision for it in the cp-opt. Why not leaving it to cp?

loh-tar commented 6 years ago

I had always in mind to track all files which will copied. Giving simply -r/-R to cp would contradict this.

Well, I know, this all looks pretty peculiar and deprives of power the copy command, things like -x.

Ambrevar commented 6 years ago

If I understand correctly, you mean that the daemon should know about the files which will be copied since it needs to track which physical drive will be under use. Good point, that.

But since there is code to scan (and remove) for the -R/-r argument in cp-opt, why not simply use that check to let the daemon know whether to go recursive or not?

Right now the commandline interface is inconsistent. I think the following synopsis is easier to grok:

cpd [-o <cp-opt>]

as opposed to

cpd [-r|-R|-o <cp-opt>]

The last one also leaves the users to wonder what happens if they set both -R and -oR.

loh-tar commented 6 years ago

Yes, should be possible.

If you check the commit log, you can see -R comes before -o, so it is something obsolete now. But you can also read that I am pretty unsure if -o make sense. Currently I think there should be the option to call something like a "raw copy command" where the files not be tracked and every thing is done by cp. Similar to new optNoProgress.

Ambrevar commented 6 years ago

If you check the commit log, you can see -R comes before -o, so it is something obsolete now.

I don't understand.

But you can also read that I am pretty unsure if -o make sense.

Why not?

What about simply scanning for symlink options and recursive options passed in -o? For GNU cp, that'd be -d, -L/--dereference, -P/--no-dereference, -r/-R/--recursive I believe. I'm not sure about the -x/--one-file-system option.

loh-tar commented 6 years ago

> But you can also read that I am pretty unsure if -o make sense. Why not?

Because there are so many options an average user rarely need, and probably never with a tool like cpd. I have no clue why you ask for such a tool. The only use case a have rarely in my mind is to copy some data collections from one drive to another. In old days these copy jobs was started all at once when drag/drop in some file explorer, pretty annoying! But nowadays I think they handle this properly by there own queue. Not sure. Well, in the Arch post was some hint to some special GUI tool IIRC, how ever. I really rarely copy files around.

So, with this, I hope you understand a little better why I have introduce -R after I have successful copied some files. From my point is no need for much more options, and things like no-/dereference are not on my "must have list" yet.

Ambrevar commented 6 years ago

So that would mean that cpd would have no support for choosing whether to follow symbolic links or not. That can be a critical issue for some users.

loh-tar commented 6 years ago

I hope it is still working (regarding #1), and you can do some test with it. I guess, right now, it is not working as it should when giving --[no-]dereference because I run a find on my own.

Ambrevar commented 6 years ago

That's an interesting thought: what about leaving the task of finding files to a dedicated tool like find? Then the question of supporting -x, -L, etc. would not be important. Furthermore, we could use any tool to perform the copy: GNU cp, BSD cp, mv, rsync...

cpd should be able to read a file list, say, from a file or from stdin. ffmpeg does that.

A file list can be as simple as "one file per line". The drawback is that it does not support file with linebreaks. Another relatively simple solution would be to embed the file list in a json structure.

Ambrevar commented 6 years ago

That would also solve this very issue, i.e. we would not need -R anymore.

loh-tar commented 6 years ago

Giving a file where the to be copied files are listed should now easy to code. Feel free to give a hint how the call have to look, perhaps:

cpd -f FILE-WITH-LIST DESTDIR

The way reading from stdin? Hmm, by omit the SOURCE when using the normal call should be works somehow.

cpd DESTDIR

The issue with new-lines in file names exist now. I read very often about this when some one give a solution for some problem at some forum. Always I ask me, "Does really anyone have newlines in his filename?" POSIX standard or not, that is strange and should be fixed; in the standard.

In which way this all give us the possibility to use any copy tool I do not understand, sorry.

But mv is an interesting idea.

After reading these BSD cp man page I see the urgency to get rid of -t/--parents in my intern used call.

Get you all new issues? If not, look at #7