Comments on: The Problem with Rename (on Ports)
In my prior article, I wrote about the problem with
delete. There's another offender: rename.
In many ways rename has similar issues to delete regarding the
inefficiency of reading an entire directory before taking action, but
the problems go even deeper...
If you stick with the series model whereby you can only change an
entry in a specific directory port, you can never move files
between directories. Use source on rename to see what
I'm talking about.
So, let's say you have a 5GB movie file, and you want to move it to a
different directory. With the current rename function, you can't (without hacking up the whole port series model). You
are forced to do a copy -- which can be painfully slow. (That's one of the
reasons why products like REBOL/IOS and AltME don't allow you to move
files! The server side of the rename action is too limited, forcing
the program to use external calls or functions instead.)
Again, just like with delete, R3.0 abstracts rename and makes it a
port action. So, if your port scheme (protocol) allows you to request
that dir/file gets moved to dir/new/file, you can do it. For a scheme
like FTP, that means the client can simply tell the server to "rename"
the file. Easy.
4 Comments Comments:
Anton Rolls
25-Mar-2007 0:54:06 |
I don't think "rename" should be able to move a file
anywhere. Its job should be restricted to just renaming.
A new "move" function should be added which chooses between two helper functions "move-by-rename" and "move-by-copy", depending on if old-dir and new-dir are in the same volume and what is supported by the protocol etc.
But the two, more public, functions, "move" and "rename", should have a clear meaning. | Henrik
25-Mar-2007 4:30:39 |
I would prefer if the file functions simply mirror standard unix file functions in behaviour as it makes it simpler to migrate from bash shell scripting to REBOL for such jobs. | Volker
27-Mar-2007 22:21:09 |
With the current behaviori always get confused.
i use
rename dir/old-name dir/new-name
and next thing is a way to console using help.
which is why i dont demonstrate how thecurrent rename works ;)
iprefer to call it rename, with move iwould think about moving content. Andthatsmy secondary intention, i want it to be called backup-dir/:file and thats it. | Brian Hawley
28-Mar-2007 15:55:43 |
I think that the rationale for the move behavior (in the original Unix mv) was thinking that the directory path of a file was part of the file name. If you could change one part of the file name, why not other parts? |
Post a Comment:
You can post a comment here. Keep it on-topic.
|
