I could see it going both ways. If the filesystem stores it's directory structure and list of files in each directory, and then points to the disk location of each of the files, it shouldn't require the file's data to actually be moved on disk in order to 'move' a file. On the other hand, I could see the 'move' being implemented by copying the file, checking the copy, and then deleting the original if the copy checks out. Does the answer depend on the type of filesystem?
Yes, this depends on the type of filesystem. But all the modern filsystems I know of use a pointer scheme of some kind. The linux/unix-filesystems (like ext2, ext3, ext4, ...) do this with INODES.
You can use
ls -i on a file to see which inode-number is referenced by the filename (residing as meta-information in the directory-entry). If you use
mv on these filesystems the resulting action will be a new pointer within the filesystem or a
rm if you cross FS-borders.
No, the file is not copied, it stays where it is. What changes is the directory listing. This is why moving even the most gigantic of files on the same partition does not take any time.
Keeping files contiguous on (traditional spinning) disks is advantageous, since it makes reading from and writing to them faster -- the head does not have to jump around the platter. However, there is no need to keep directories contiguous on disk.
I could see the 'move' being implemented by copying the file, checking the copy, and then deleting the original if the copy checks out. Does the answer depend on the type of filesystem?
I'm not an expert on filesystems, but I can't imagine there are any normal ones that do as this would be a huge performance penalty and also increase wear and tear on the hardware.