Loading Profile...
cp process + advantages of spawning ssh and exec'ing processes
When you copy data from a remote share through sftp to the same share, but into another folder/directory, PLEASE set it such that it will do the copy directly on the server versus using the remote connection from which one is working as the conduit. If sftp cannot directly do this, it can be accomplished by spawning a new ssh process using the sftp authentication info and then simply issuing a cp command. This would save tremendous headaches for me while moving things from staging folders to production and so forth as we deal with some large images, and so forth. It is simply a matter of efficiency and could help in other areas as well. For example, `du` may be able to be issued to more quickly gather disk usage information.
I’m frustrated
1
person likes this idea
I like this idea!
Tell me when this idea gets some attention.
The more people who like this idea, the more it gets noticed.
The more people who like this idea, the more it gets noticed.
-
Inappropriate?Additionally, it would be very useful to be able to utilize the ssh process to be able to create connections directly between two shares, again vs using the intermediary workstation from which presently working. Thus if you transfer files from server1 to server2 and they have a fatter pipe between themselves as the workstations network connection will nearly always be the limiting speed bottleneck, plus just add to the process, you could ssh with the authentication info from server1 to server2 and then transfer the file(s) directly. Again, this could yield tremendous speed increases and a much happier userbase. Of course transfer data would need to be captured and translated for Mac OS X to understand, but that can be done without too much work perhaps through hooks that already exist. -
Inappropriate?I really like this idea - unfortunately, there is absolutely no way we could ever implement it.
Consider what happens when you copy data on your hard disk using Finder or plain old cp.
1. cp -r /Users/jeff/somefolder /Users/jeff/work/newfoldername
2. cp/Finder recurse into somefolder figuring out what is in there
3. Next they create newfoldername in the new location, and start copying the data of the file over file by file
What you're suggesting is that we could somehow recognize that a "copy tree" operation is happening and then perform that operation on the remote server. But there is no "copy tree" command - just some application performing the traversal and doing the copy. We can't really even make a guess, with any confidence, that a copy tree was happening between two locations on our volume until the entire operation is entirely complete. -
Inappropriate?You can integrate rsync or such an algorithm into it to walk the tree, parse the list and process it...1 Comment
Add a comment
This is one of the best points
-
Imagine a simpler scenario - you want to copy a 100GB file from one directory on the remote server to another using ExpanDrive. Select the file in Finder, copy, go to the new folder, paste.
You would think we could somehow just issue a 'cp' on the server and it would happen instantly.
What happens, from ExpanDrive's view, is this
1. Open file.iso
2. Open newfile.iso
2. Read 64KB from file.iso
3. Write 64KB to newfile.iso
4. Read 64KB from file.iso
5. Write 64KB to newfile.iso
... and so on
close newfile.iso
close file.iso
We could make a guess that after a few chunks come through matching that pattern that the user intends to copy file.iso to newfile.iso - and then just perform a cp on the server, and quietly "digest" all of the read/writes that get issued to us, and then perform the close
But what if the user/script stops the "copy" halfway through. What if they only intended to copy half of file.iso to newfile.iso, for whatever reason. We would have corrupted their file by guessing what they intended to do.
This is the same problem we face when potentially guessing that a copy tree might be happening. We can't actually know what happened until it is over, and at that point, it's too late.
EMPLOYEE
