FileSystem changes that would be nice

I think it would be nice if when moving a large file(s) on the HD, the filesystem would simply change the virtual directory the file is located in, rather than copying the file to a new location on the hard drive and deleting the original. For example, I have a folder on my drive, "temp", that is over 300 GB in size. Say I wanted to move this folder to a different location, say "../". Currently (in Windows, at least 1), such a move would require 300 GB to be redirected, which can take hours. If instead, the filesystem were to change a system file that said where all the files were on the hard drive, the process would be cut to seconds no matter how large the files being moved were. Also, defragmentation is lessened because the files aren't actually being moved. The drive would only require files be moved on true copying, new files, or file deletion, processes which would continue to occur often, but there would still be a great advantage.

1: I'm not used to any OS other than Windows. If there is another operating system that has the functionality I'm speaking of, please point it out.

I thought that Windows did work like this.

I've moved 4GB ISO files between folders on my C drive and it's been fast (under a minute), but when I've copied them, it takes a whole lot longer (worst so far was about 15 minutes).

this is the way it is currently on windows / linux

however, it only wokrs if you are doing the moving on the same partition, moving from one partition to another involves re-allocating all the data

because partitions have fixed starts and ends, and can not have the 'fast' copying like you described

It has nothing to do with the operating system, it's the filesystem. Older windows-style filesystems like FAT32 required an actual move operation rather than a reallocation. NTFS is slightly better but still does a lot of extra work. *nix filesystems (like ext3 for instance) do it nearly instantaneously.

There's also the OS layer that has some hurdles to overcome. Try Robocopy, it seems to perform a bit better than the standard drag-and-drop or cut/paste operations.

Also very true. Windows has to update a bunch of other locations, like recent documents, the search file databases, caches, indexes, etc. Applications like robocopy ignore those, trusting windows to fail and recover properly (*guffaw*)

Can you create a hardlink at the new location ? And then delete the original file ? Dunno.

In *nix, yes you can - the 'link count' is incremented by each hard link created and decremented by each rm command, and once link count reaches 0 the file is actually gone.

Not quite. Even DOS (which ran FAT12 and FAT16) would simply update a couple of directory entries, as long as the source and destination are on the same drive. This has been true since DOS 2.0 from the early 1980s. The only time a copy-and-delete operation is needed is if the source and destination are on different drives. The same is true for FAT32, NTFS, ext2, ext3, UFS, HFS (and most other filesystems) as well.

The fun thing about *nix is that it does such a good job of abstracting things away that it isn't easy to tell whether a directory is on a different drive or not. This is why some newbies get confused about why file moves from (say) /usr/src to /usr/local/src may be instantaneous, but moves from (say) /usr/src to /usr/somedir may take a long time. Because *nix does such a good job of abstraction, the user may not be aware that /usr/somedir may actually be on a different drive on the system or perhaps on another machine located on the other side of the planet!

i just tested on fat32 and it did just modify location and not actual copy.

Scorpions is correct, above. I was really just trying to say the beginning of my post: The OS isn't the entire limit, the filesystem has something to do with it.

It's refreshing to see that a few knowledgeable people like Scorp have hung around to correct the inaccurate information given by a number of truly ignorant fatheads.

While there are OSes without file systems, it would be interesting to hear about file systems that are not considered part of the OS. Certainly one could write one, but it would be like the learning exercises where one writes an OS to run on another OS.

Speaking of ignorant fatheads...

You can choose which filesystem to run your OS on, can't you? So if you go to install Ubuntu and it gives you a dozen filesystems to choose from, wouldn't you say that those are distinct from the OS? Or did you not know that was possible.

Your grin is showing, put it away.

that part is correct

but in my head i always assumed the file system is a part of the os, since linux has its filesystem (ext3/4), windows has its different file systems (fat16/32/ntfs), windows xp introduced ntfs ..

Certain operating sytems support certain filesystems, but they are not a part of the operating system. A linux machine can read and write a FAT32-formatted flash drive. Does that mean FAT32 is a part of 6 different operating systems? No. Filesystems are supported by operating systems and used by operating systems, and obviously bundled with operating systems, but I don't consider them a part of operating systems any more than device drivers are. The filesystem can be changed out from underneath an OS.

The discussion is getting a little too meta though. Now we'll probably get into an argument about what actually constitutes "being a part of" another piece of software.