3 ms·

Not on Linux

klodolph 5y ago
I was unable to reproduce your success. I just tested in GEdit, it failed, just as I expected. I could move the file, but this broke the association with the open document. I saved to ~/test.txt, then moved it to ~/Documents/test.txt, and saved a second time. The second time I saved it, it saved the file to ~/test.txt, which is incorrect and useless. Now I have two files, but no action I took as a user should have created two files--moving a file should not create a second copy, and saving an open file should not have created a second copy, so why should moving and saving create a second copy? On Windows, you typically get an error message, because you can't move an open file. (Not all applications keep the file open, so this doesn't always happen.) Personally, I think that enforcing exclusive locks is the worst, most significant design flaw in the entire history of the Windows operating system. Only on macOS do you get the nice, expected behavior... it does not matter if you move a file while it is open in an application. When a file is open in an application, the open file is associated with the file, not with the pathname. You can rename a file in the Finder or reorganize a bunch of files in the Finder (or do the same in the terminal) and it does not matter whether those files are open in any applications. You can reorganize files in the Finder, and then when you save open documents, they save to the new location, not the old one. If you rename files in the Finder or rename a bunch of files with a script in the terminal, the windows for open documents you renamed will update their titles to match the new names. The problem here is that (opinion time) the standard filesystem API is a really terrible interface. What you want is some way to create durable references to files. File handles can do that, but only while your application is open. Paths can do it while your application is closed, but the reference is lost if you move the file. On macOS, there's a standard API which provides something more persistent than file handles and more durable than paths. I think they're called "bookmarks" now, but they used to be called "aliases".

Not on Linux

I was unable to reproduce your success. I just tested in GEdit, it failed, just as I expected. I could move the file, but this broke the association with the open document. I saved to ~/test.txt, then moved it to ~/Documents/test.txt, and saved a second time. The second time I saved it, it saved the file to ~/test.txt, which is incorrect and useless. Now I have two files, but no action I took as a user should have created two files--moving a file should not create a second copy, and saving an open file should not have created a second copy, so why should moving and saving create a second copy? On Windows, you typically get an error message, because you can't move an open file. (Not all applications keep the file open, so this doesn't always happen.) Personally, I think that enforcing exclusive locks is the worst, most significant design flaw in the entire history of the Windows operating system. Only on macOS do you get the nice, expected behavior... it does not matter if you move a file while it is open in an application. When a file is open in an application, the open file is associated with the file, not with the pathname. You can rename a file in the Finder or reorganize a bunch of files in the Finder (or do the same in the terminal) and it does not matter whether those files are open in any applications. You can reorganize files in the Finder, and then when you save open documents, they save to the new location, not the old one. If you rename files in the Finder or rename a bunch of files with a script in the terminal, the windows for open documents you renamed will update their titles to match the new names. The problem here is that (opinion time) the standard filesystem API is a really terrible interface. What you want is some way to create durable references to files. File handles can do that, but only while your application is open. Paths can do it while your application is closed, but the reference is lost if you move the file. On macOS, there's a standard API which provides something more persistent than file handles and more durable than paths. I think they're called "bookmarks" now, but they used to be called "aliases".