Comments on: The Problem with Rename (on Ports)

Carl Sassenrath, CTO
REBOL Technologies
23-Mar-2007 17:06 GMT

Article #0071
Main page || Index || Prior Article [0070] || Next Article [0072] || 4 Comments || Send feedback

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.



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.

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.
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.


Blog id:



 Note: HTML tags allowed for: b i u li ol ul font span div a p br pre tt blockquote

This is a technical blog related to the above topic. We reserve the right to remove comments that are off-topic, irrelevant links, advertisements, spams, personal attacks, politics, religion, etc.

Updated 24-Mar-2017 - Edit - Copyright REBOL Technologies -