On Thu, 2005-08-25 at 13:41 -0400, Shailabh Nagar wrote: > Matthew Helsley wrote: > > Is eliminating rename such a great idea? I realize it makes the code > > simpler, but doesn't it also violate the principle of least suprise by > > preventing a user from mv'ing things around?
In practice at least, it shouldn't prevent mv from working. mv looks like it compensates for that. But, sys_rename() itself, of course still has issues, as do things that use it directly like perl's rename(). from mv.c::do_move() > /* This may mean SOURCE and DEST referred to different devices. > It may also conceivably mean that even though they referred > to the same device, rename wasn't implemented for that device. > > E.g., (from Joel N. Weber), > [...] there might someday be cases where you can't rename > but you can copy where the device name is the same, especially > on Hurd. Consider an ftpfs with a primitive ftp server that > supports uploading, downloading and deleting, but not renaming. > > Also, note that comparing device numbers is not a reliable > check for `can-rename'. Some systems can be set up so that > files from many different physical devices all have the same > st_dev field. This is a feature of some NFS mounting > configurations. > > We reach this point if SOURCE has been successfully copied > to DEST. Now we have to remove SOURCE. > > This function used to resort to copying only when rename > failed and set errno to EXDEV. */ -- Dave ------------------------------------------------------- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf _______________________________________________ ckrm-tech mailing list https://lists.sourceforge.net/lists/listinfo/ckrm-tech
