Yes, and sorry if redraw the syntax of my thought cause my no sleepness of this days.. the doubt was really the atomicity of a mv, expecially the source, after a break or a ctrl+c.. -Dan
------ bsd.gaoxio.com - Repo: https://code.5mode.com Please reply to the mailing-list, leveraging technical stuff. 18 ago 2025 14:56:09 Otto Moerbeek <o...@drijf.net>: > On Mon, Aug 18, 2025 at 08:17:14AM -0400, Kenneth Gober wrote: > >> On Sun, Aug 17, 2025 at 9:42 AM dan <d...@nnnne-o-o-o.com> wrote: >> >>> I suggested I'm just watching at the behavior of the mv on Open Indiana >>> and it seems to get that it always behave like a sequential cp + rm despite >>> the presence of two different fs. And that it sounds safer after all.. >>> >> >> When the source and destination are on different file systems, cp + rm is >> required, because the bits >> must be physically copied to the new file system. >> >> When the source and destination are on the same file system, the file does >> not actually get moved. >> Instead, the directory entry (which points to the inode for the file) is >> moved. The inode itself (which >> holds all the information about the file other than its name(s)) does not >> get moved or copied. It's >> like ln + rm, instead of cp + rm. Just moving the directory entry is much >> safer (and faster) than >> actually moving the data to new disk sectors. > > For the ln + rm case, a syscall exists: rename(2), which does that > operation atomically. It's all there in the source code of mv. > >> >> -ken
