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.


Updated 22-Jun-2024 - Edit - Copyright REBOL Technologies -