<strong>You could accidentally cut something else to the pasteboard, thereby erasing the file, because in the process of cutting the file (as opposed to copying) to the pasteboard, it's the only place the file now exists.
No, in windows it does not work like this. The computer doesn't do anything other than keep track of the file's location until you paste and it does nothing until the entire content has been moved successfully.
The file doesn't dissapear when you do cut nor is it totally moved onto the clipboard.
If you don't decide to paste it, the file will still be at the same place.
Even if your computer crashes, nothing will happen.
So, sorry, but I still don't understand what you mean by it being dangerous.
<strong>The file doesn't dissapear when you do cut nor is it totally moved onto the clipboard.</strong><hr></blockquote>
Then it's not a true "cut" behavior and is inconsistent with "cut" in every other context. I'm assuming you treat files, text, images, everything in the same way. That's what I hate about windows. The same commands do different things in different apps and contexts. If it doesn't work like cut, then they shouldn't call it that. It would be more intelligent to create a "move" command where you can paste an item to the clipboard in the manner you described, leaving the original intact until you pasted it somewhere else in the filesystem, than to call it something it isn't.
Yes, and if you use the cut command on a file, it should just make it invisible but keep it where it originally was. When you press paste, it moves the file. If you accidentally copy or cut something else, pushing the original out, it should return it to its original spot.
See, there should be something easy like that that is still safe. I don't want to have to copy something, paste it somewhere else, and then find the original to delete it. It's like how stuffit expander leaves .sit files on my desktop... I just went into expander's prefs and told it to delete the compressed files after expanding them. There should be something like that in finder, akin to "always open folders in new windows."
I agree with you completely, bauman. I think that too much of what software developers do is create features that help a few users at the expense of hurting many more users.
this brings to mind a phrase I've heard about interfacce design that "simple things should be easy and complicated things should be possible." Apple can add robust copy/cut/paste file featuresm and it will make a complicated task easy but now the easy tasks are difficult. That doesn't make any sense.
Apple is great at making things easy yet powerful. Take Safaari vs. all other web browsers for example. Where other browsers may have complex appearance preferences Safari has a simple, logical, style sheet option. It may not be as easy to do complicated stuff as with dedicated appearance controls but it is certainly possible to have powerful control over the way your browser renders web pages. At the same time it is still easy to comprehend the browser's functionality.
I think this is a fundamental paradigm to Apple's design and i know it is why I can only tolerate using a Mac.
<strong>You could accidentally cut something else to the pasteboard, thereby erasing the file, because in the process of cutting the file (as opposed to copying) to the pasteboard, it's the only place the file now exists.
That seems trivial to handle, but I think we are on to something.
Here's how I would handle it, and then I'll describe why it may not work... I think both Copy and Paste would be trivial to implement. The only issue would be how to "non-destructively" cut something and the answer is "move it to the trash" and also place it on the clipboard. Then, if you accidently use the clipboard for something else, or if your computer crashes, you can still retrieve the file.
Now, why that doesn't work. When you connect to network drives, moving an item to the trash doesn't actually put it into your trash. Instead, it actually deletes the file. (The OS provides a nice warning about this, though). If the mechanism that I prescribed were to be used, you could potentially lose a lot of network files that way. My guess is that Apple has some network connectivity cleanup to do, and when that's finished, we may get cut/paste actions on files. (Just a guess, though)
[quote] I have no complaints about OS X's networking - it's been, on the whole, much easier even than OS 9 for me.<hr></blockquote>
I have found absolutely nothing consistent with OSX's networking.
For instance:
1.) I can share a USB printer on a Mac w/OSX with my PCs, but I cannot share the same printer with my other OSX machines.
2.) Depending on which of my Macs I use, I can either easily connect to my PCs, or I have to use smb://xxx.xxx.xxx.xx. Which I hate
I shouldn't have to do a voodoo dance. It shouldn't be that difficult , nothing should be that difficult. I have since given up hope that I will ever get my network to work correctly.
I have found absolutely nothing consistent with OSX's networking.
For instance:
1.) I can share a USB printer on a Mac w/OSX with my PCs, but I cannot share the same printer with my other OSX machines.
2.) Depending on which of my Macs I use, I can either easily connect to my PCs, or I have to use smb://xxx.xxx.xxx.xx. Which I hate
I shouldn't have to do a voodoo dance. It shouldn't be that difficult , nothing should be that difficult. I have since given up hope that I will ever get my network to work correctly.</strong><hr></blockquote>
I completely agree. Networking on the Mac has a _LONG_ way to go, which seems kind of silly since it is something that has been handled for so well and for so long by other operating systems.
My complaints:
1) When I connect to a network drive and then switch to another network (something that occurs frequently with my laptop), the OS won't let me unmount the old system and remount it on the new network.
2) If I mount a network drive and then log out without unmounting the drive, it causes huge problems if somebody else logs into the box.
3) There is no easy way to have a drive be mounted when I log in. Yes, I've seen the "place the drive into your login items", but that doesn't work for SMB drives.
4) I like to password protect my webDAV servers. The only webDAV server that Mac OSX will remember the password for, is the iDisk (.mac) server. This makes it a huge annoyance to automatically mount my webDAV server (unless I try to trick the mac into thinking that my home servers are actually the iDisk)
5) Anytime I do a software upgrade, I better hope I don't have my network drives mounted, because the stupid "optimizing system" check actually searchs all of my drives. Searching my 100GB network drive takes forever.
Now, let's compare this with Windows... I click on "Map Network Drive", provide the details of where the drive is, and I'm given a choice that says "Mount this drive at startup?". Clicking that automatically mounts the drive for me at startup (duh). Also, when my network connection closes, it automatically unmounts the drive for me and it remounts it when I regain my network connection.
With the amount of hangups I have on my Mac System, I have basically given up trying to mount a network drive and instead I ssh into the server directly to do work.
In fairness, perhaps 10.2.3 is better. To be honest, I have given up hope a while ago because I hate having my computer freeze, do a forced reboot and then wait the 20 minutes while the fsck happens.
some of these ideas are good, but they make some terrible UI concepts when you think deeper about them. I'll give my thoughts on the Finder Copy/Paste/Cut issue here... [quote]Originally posted by Brian Paulsen:
<strong>Here's how I would handle it, and then I'll describe why it may not work... I think both Copy and Paste would be trivial to implement.</strong><hr></blockquote>I think you guys are overlooking a very important point. By making this command so complicated with hiding/unhiding files and so on, you are breaking the basic meaning of the Copy/Cut/Paste tools. Cut by its very nature SHOULD be destructive. It has been that way since it started being used in the early 80s. Making the Finder behave differently makes this tool inconsistent with how it works in every single app. That is a Bad Thing (TM).
Rather than have to either make a special case for Cut in the Finder or allow the "correct" destructive behavior of Cut, if it is to have this full behavior, the Finder should implement some *new* menu items with different (but similar) names in the File menu. That would immediately make it visible to the user that this is not the standard Cut menu item that he has grown to know from all the other apps.
I read a good article about this some time ago... I'll see if Google can bring it up...
<strong>some of these ideas are good, but they make some terrible UI concepts when you think deeper about them. I'll give my thoughts on the Finder Copy/Paste/Cut issue here... I think you guys are overlooking a very important point. By making this command so complicated with hiding/unhiding files and so on, you are breaking the basic meaning of the Copy/Cut/Paste tools. Cut by its very nature SHOULD be destructive. It has been that way since it started being used in the early 80s. Making the Finder behave differently makes this tool inconsistent with how it works in every single app. That is a Bad Thing (TM).
Rather than have to either make a special case for Cut in the Finder or allow the "correct" destructive behavior of Cut, if it is to have this full behavior, the Finder should implement some *new* menu items with different (but similar) names in the File menu. That would immediately make it visible to the user that this is not the standard Cut menu item that he has grown to know from all the other apps.
</strong>
<hr></blockquote>
I agree with your earlier statement. Cut/Copy/Paste should work just like everything else does. (Make sure that Undo also works on these operations)
I'm not sure how arguing that we need special operations for files make a better UI design. Let me make sure that I have it right though.
"Copy" lets you copy things. Oh, do you want to copy a "file"? Well, that's a different copy command. Do you want to move a file, well that's a different "Cut" command. Oh, and by the way, the normal "Copy" and "Cut" commands don't work on files and the "File Copy" and "File Cut" commands don't work on anything else. If we find a couple of other things that have the same issues, then we are going to have a huge menu of slightly different Copy/Cut/Paste commands.
<strong>
[quote]
I read a good article about this some time ago... I'll see if Google can bring it up...
That's an interesting article that makes some valid points. However, it is fairly weak in the Copy/Paste argument. Here's what I got out of it:
1) Macs can do Copy/Paste if you download some program that does it (so what? I want something supported natively as I can do anything if I install software to do it)
2) The average user who copies/pastes files must be really stupid as they tend to forget what they copied and then we get unknown stuff on the clipboard. Somehow though, they are smart enough to use copy/paste for every other activity, but not when they use it for files.
When the author mentions troubles about Cut/Paste, then he has some very valid points abouts failings of Windows. However, he never really explains why he thinks it's a bad UI, he just points out that Windows does it wrong.
Actually, many of the arguments in his article are so biased towards the Apple way of doing things, it's hard to tell if he's just trying to slam Windows or if he really believes that the Apple way is correct.
<strong>Actually, many of the arguments in his article are so biased towards the Apple way of doing things, it's hard to tell if he's just trying to slam Windows or if he really believes that the Apple way is correct.</strong><hr></blockquote>
Welcome to the world of David Every.
To me, I'd love to see a more robust clipboard management system/window for users. Plus, I think the whole cut/copy/paste files issue could be solved with a slight change to the terminology: move and copy, with different keystrokes and under the File menu, not the Edit menu. The basic idea is to use the kayboard/keystrokes to move and copy files, and it's a good feature to have. But as a file organizer and like any other app, the Finder should have cut/copy/paste reserved for text/image functions (renaming, changing icons, etc.) alone. I think keeping all these commands present but discrete would be a good move.
Main feature I'd like to see is the ability to click on a file in a save dialogue and have it's name appear in the "name" field. This helps out when saving many related files.
This article actually brings up another minor annoyance of the Mac operating system. If I drag a file across drives, it copies the file rather than moves it. The article then goes on about how Windows does it wrong, and then tries to justify how "if Windows does it, and Mac doesn't, it must obviously be a bad UI design." (Not a real quote, there)
Personally, while I completely agree that the Windows way has shortcomings, I think it's a bit silly that a Finder window that looks like every other window acts different just because it's a different drive. If I move a file from one window to another, I expect it to move, not copy. Now I'm forced to guess when is a file going to be copied and when is it going to be moved.
It gets even worse when I try to move files on a network drive. The network drive could actually be on many separate drives and that information is hidden from me (and from the OS). Now, if I start moving files, the Mac lets me think I'm doing a move, when really (behind the scenes) a copy and delete is actually happenning. We now get into the exact same problems that the author was saying was bad about Windows. But now, it's actually worse - at least Windows was smart enough to tell the user something was happenning.
Personally, I thought the drag and drop style of moving files was supposed to be a cute graphical interface to the 'mv' command. It doesn't make a lot of sense to me why sometimes it's a 'cp' command and other times it's a 'mv' command. The OS already has a nice "Duplicate" command. If I wanted to copy a file, I would use that and then move the copy. If Apple really wanted to be consistent, they would modifiy Darwin so that 'mv' actually does a 'cp' when you are moving files across drives.
Of course some of my mindset may be due to years and years of programming under Unix and thinking the nicest thing about a windowing system is giving me multiple xterms on one terminal. For the most part (even on the Mac) when I want to move, copy, or delete a file, I feel FAR more comfortable opening up the terminal and doing it that way.
Copy again is the better design because of the greater chance of file corruption in the process of moving the file across the network. Copying means you have an intact original. You do have the option of moving the file anyway with the option key, and the threat of file corruption in networks is lower today, but still not negligible. Besides, is copying that unpopular when moving files across a network? Maybe it's because I know I'm making a backup in the process, but I usually prefer to copy to the network.
<strong>Copy again is the better design because of the greater chance of file corruption in the process of moving the file across the network. Copying means you have an intact original. You do have the option of moving the file anyway with the option key, and the threat of file corruption in networks is lower today, but still not negligible. Besides, is copying that unpopular when moving files across a network? Maybe it's because I know I'm making a backup in the process, but I usually prefer to copy to the network.</strong><hr></blockquote>
If that's true, then any drag-and-drop on a network drive should always be a copy, not a move. When you connect to network drives, you don't actually know whether or not those drives are also connecting to another network drive.
For example, I may connect to /home/foo and I want to move a file to /home/foo/bar. It's quite possible that /home/foo/bar is actually mounted somewhere else by the machine that is hosting /home/foo. You now have the same chance of file corruption that you are claiming for moving a file from your local drive to /home/foo.
If we arguing that Apple is making the file transfer safe for us, then the only logical thing for them to do is make sure that any file operations on network drives are copies and not moves.
[quote]When you connect to network drives, you don't actually know whether or not those drives are also connecting to another network drive.<hr></blockquote>splain this to one to me again, Lucy. Any time you move a file from one drive volume to another, whether its a partition or physical volume it will result in a file copy--if you're using the Finder. AFAIK the Finder also represents all drives/drive partitions as seperate devices.
<strong>splain this to one to me again, Lucy. Any time you move a file from one drive volume to another, whether its a partition or physical volume it will result in a file copy--if you're using the Finder. AFAIK the Finder also represents all drives/drive partitions as seperate devices.</strong><hr></blockquote>
Sure...
Let's say I connect to a file server. When I connect, I give it a machine name and a directory that I want to mount. The Unix command that gets executed will be something like this:
mount /Volumes/foo myserver:/foo
Now, /foo may have several directories under it, such as /bar1 and /bar2. So, the structure looks like this: /foo/bar1 and /foo/bar2
What happens if I use the finder to move a file from /foo to /foo/bar1 ? Does it do a copy or does it do a move?
If you think it should do a move, I would argue that's incorrect (using the Apple logic of how the finder should work) Here's why:
/foo/bar1 could actually be mounted from a different drive on the myserver host. In other words, if we looked at the mount map for myserver, we may see something like
otherserver:/bar1 on /foo/bar1
What this means is that if the Mac OS issued a 'mv' command to move the files, it is not an atomic move. Instead, what actually happens is a copy and delete. As many have pointed out, a copy and delete can be very dangerous and could leave you filesystem in an unpredictable state.
Since the OS has no way of knowing whether or not the remote server is also mounting directories off of other drives, it should do the safe thing and always just copy when moving files from any folder to another (on network drives).
Of course, this would be rather tedious to the user, but it would be safer.
Comments
<strong>You could accidentally cut something else to the pasteboard, thereby erasing the file, because in the process of cutting the file (as opposed to copying) to the pasteboard, it's the only place the file now exists.
[clarity]
[ 01-20-2003: Message edited by: BuonRotto ]</strong><hr></blockquote>
No, in windows it does not work like this. The computer doesn't do anything other than keep track of the file's location until you paste and it does nothing until the entire content has been moved successfully.
The file doesn't dissapear when you do cut nor is it totally moved onto the clipboard.
If you don't decide to paste it, the file will still be at the same place.
Even if your computer crashes, nothing will happen.
So, sorry, but I still don't understand what you mean by it being dangerous.
<strong>The file doesn't dissapear when you do cut nor is it totally moved onto the clipboard.</strong><hr></blockquote>
Then it's not a true "cut" behavior and is inconsistent with "cut" in every other context. I'm assuming you treat files, text, images, everything in the same way. That's what I hate about windows. The same commands do different things in different apps and contexts. If it doesn't work like cut, then they shouldn't call it that. It would be more intelligent to create a "move" command where you can paste an item to the clipboard in the manner you described, leaving the original intact until you pasted it somewhere else in the filesystem, than to call it something it isn't.
See, there should be something easy like that that is still safe. I don't want to have to copy something, paste it somewhere else, and then find the original to delete it. It's like how stuffit expander leaves .sit files on my desktop... I just went into expander's prefs and told it to delete the compressed files after expanding them. There should be something like that in finder, akin to "always open folders in new windows."
this brings to mind a phrase I've heard about interfacce design that "simple things should be easy and complicated things should be possible." Apple can add robust copy/cut/paste file featuresm and it will make a complicated task easy but now the easy tasks are difficult. That doesn't make any sense.
Apple is great at making things easy yet powerful. Take Safaari vs. all other web browsers for example. Where other browsers may have complex appearance preferences Safari has a simple, logical, style sheet option. It may not be as easy to do complicated stuff as with dedicated appearance controls but it is certainly possible to have powerful control over the way your browser renders web pages. At the same time it is still easy to comprehend the browser's functionality.
I think this is a fundamental paradigm to Apple's design and i know it is why I can only tolerate using a Mac.
-Chris
<strong>You could accidentally cut something else to the pasteboard, thereby erasing the file, because in the process of cutting the file (as opposed to copying) to the pasteboard, it's the only place the file now exists.
[clarity]
[ 01-20-2003: Message edited by: BuonRotto ]</strong><hr></blockquote>
That seems trivial to handle, but I think we are on to something.
Here's how I would handle it, and then I'll describe why it may not work... I think both Copy and Paste would be trivial to implement. The only issue would be how to "non-destructively" cut something and the answer is "move it to the trash" and also place it on the clipboard. Then, if you accidently use the clipboard for something else, or if your computer crashes, you can still retrieve the file.
Now, why that doesn't work. When you connect to network drives, moving an item to the trash doesn't actually put it into your trash. Instead, it actually deletes the file. (The OS provides a nice warning about this, though). If the mechanism that I prescribed were to be used, you could potentially lose a lot of network files that way. My guess is that Apple has some network connectivity cleanup to do, and when that's finished, we may get cut/paste actions on files. (Just a guess, though)
I have found absolutely nothing consistent with OSX's networking.
For instance:
1.) I can share a USB printer on a Mac w/OSX with my PCs, but I cannot share the same printer with my other OSX machines.
2.) Depending on which of my Macs I use, I can either easily connect to my PCs, or I have to use smb://xxx.xxx.xxx.xx. Which I hate
I shouldn't have to do a voodoo dance. It shouldn't be that difficult , nothing should be that difficult. I have since given up hope that I will ever get my network to work correctly.
<strong>
I have found absolutely nothing consistent with OSX's networking.
For instance:
1.) I can share a USB printer on a Mac w/OSX with my PCs, but I cannot share the same printer with my other OSX machines.
2.) Depending on which of my Macs I use, I can either easily connect to my PCs, or I have to use smb://xxx.xxx.xxx.xx. Which I hate
I shouldn't have to do a voodoo dance. It shouldn't be that difficult , nothing should be that difficult. I have since given up hope that I will ever get my network to work correctly.</strong><hr></blockquote>
I completely agree. Networking on the Mac has a _LONG_ way to go, which seems kind of silly since it is something that has been handled for so well and for so long by other operating systems.
My complaints:
1) When I connect to a network drive and then switch to another network (something that occurs frequently with my laptop), the OS won't let me unmount the old system and remount it on the new network.
2) If I mount a network drive and then log out without unmounting the drive, it causes huge problems if somebody else logs into the box.
3) There is no easy way to have a drive be mounted when I log in. Yes, I've seen the "place the drive into your login items", but that doesn't work for SMB drives.
4) I like to password protect my webDAV servers. The only webDAV server that Mac OSX will remember the password for, is the iDisk (.mac) server. This makes it a huge annoyance to automatically mount my webDAV server (unless I try to trick the mac into thinking that my home servers are actually the iDisk)
5) Anytime I do a software upgrade, I better hope I don't have my network drives mounted, because the stupid "optimizing system" check actually searchs all of my drives. Searching my 100GB network drive takes forever.
Now, let's compare this with Windows... I click on "Map Network Drive", provide the details of where the drive is, and I'm given a choice that says "Mount this drive at startup?". Clicking that automatically mounts the drive for me at startup (duh). Also, when my network connection closes, it automatically unmounts the drive for me and it remounts it when I regain my network connection.
With the amount of hangups I have on my Mac System, I have basically given up trying to mount a network drive and instead I ssh into the server directly to do work.
In fairness, perhaps 10.2.3 is better. To be honest, I have given up hope a while ago because I hate having my computer freeze, do a forced reboot and then wait the 20 minutes while the fsck happens.
<strong>Here's how I would handle it, and then I'll describe why it may not work... I think both Copy and Paste would be trivial to implement.</strong><hr></blockquote>I think you guys are overlooking a very important point. By making this command so complicated with hiding/unhiding files and so on, you are breaking the basic meaning of the Copy/Cut/Paste tools. Cut by its very nature SHOULD be destructive. It has been that way since it started being used in the early 80s. Making the Finder behave differently makes this tool inconsistent with how it works in every single app. That is a Bad Thing (TM).
Rather than have to either make a special case for Cut in the Finder or allow the "correct" destructive behavior of Cut, if it is to have this full behavior, the Finder should implement some *new* menu items with different (but similar) names in the File menu. That would immediately make it visible to the user that this is not the standard Cut menu item that he has grown to know from all the other apps.
I read a good article about this some time ago... I'll see if Google can bring it up...
edit: here, read this:
<a href="http://mackido.com/Interface/CopyMore.html"; target="_blank">http://mackido.com/Interface/CopyMore.html</a>;
[ 01-22-2003: Message edited by: Brad ]</p>
<strong>some of these ideas are good, but they make some terrible UI concepts when you think deeper about them. I'll give my thoughts on the Finder Copy/Paste/Cut issue here... I think you guys are overlooking a very important point. By making this command so complicated with hiding/unhiding files and so on, you are breaking the basic meaning of the Copy/Cut/Paste tools. Cut by its very nature SHOULD be destructive. It has been that way since it started being used in the early 80s. Making the Finder behave differently makes this tool inconsistent with how it works in every single app. That is a Bad Thing (TM).
Rather than have to either make a special case for Cut in the Finder or allow the "correct" destructive behavior of Cut, if it is to have this full behavior, the Finder should implement some *new* menu items with different (but similar) names in the File menu. That would immediately make it visible to the user that this is not the standard Cut menu item that he has grown to know from all the other apps.
</strong>
<hr></blockquote>
I agree with your earlier statement. Cut/Copy/Paste should work just like everything else does. (Make sure that Undo also works on these operations)
I'm not sure how arguing that we need special operations for files make a better UI design. Let me make sure that I have it right though.
"Copy" lets you copy things. Oh, do you want to copy a "file"? Well, that's a different copy command. Do you want to move a file, well that's a different "Cut" command. Oh, and by the way, the normal "Copy" and "Cut" commands don't work on files and the "File Copy" and "File Cut" commands don't work on anything else. If we find a couple of other things that have the same issues, then we are going to have a huge menu of slightly different Copy/Cut/Paste commands.
<strong>
[quote]
I read a good article about this some time ago... I'll see if Google can bring it up...
edit: here, read this:
<a href="http://mackido.com/Interface/CopyMore.html"; target="_blank">http://mackido.com/Interface/CopyMore.html</a>;
[ 01-22-2003: Message edited by: Brad ]</strong><hr></blockquote>
That's an interesting article that makes some valid points. However, it is fairly weak in the Copy/Paste argument. Here's what I got out of it:
1) Macs can do Copy/Paste if you download some program that does it (so what? I want something supported natively as I can do anything if I install software to do it)
2) The average user who copies/pastes files must be really stupid as they tend to forget what they copied and then we get unknown stuff on the clipboard. Somehow though, they are smart enough to use copy/paste for every other activity, but not when they use it for files.
When the author mentions troubles about Cut/Paste, then he has some very valid points abouts failings of Windows. However, he never really explains why he thinks it's a bad UI, he just points out that Windows does it wrong.
Actually, many of the arguments in his article are so biased towards the Apple way of doing things, it's hard to tell if he's just trying to slam Windows or if he really believes that the Apple way is correct.
<strong>Actually, many of the arguments in his article are so biased towards the Apple way of doing things, it's hard to tell if he's just trying to slam Windows or if he really believes that the Apple way is correct.</strong><hr></blockquote>
Welcome to the world of David Every.
To me, I'd love to see a more robust clipboard management system/window for users. Plus, I think the whole cut/copy/paste files issue could be solved with a slight change to the terminology: move and copy, with different keystrokes and under the File menu, not the Edit menu. The basic idea is to use the kayboard/keystrokes to move and copy files, and it's a good feature to have. But as a file organizer and like any other app, the Finder should have cut/copy/paste reserved for text/image functions (renaming, changing icons, etc.) alone. I think keeping all these commands present but discrete would be a good move.
<strong>
<a href="http://mackido.com/Interface/CopyMore.html"; target="_blank">http://mackido.com/Interface/CopyMore.html</a>;
[ 01-22-2003: Message edited by: Brad ]</strong><hr></blockquote>
This article actually brings up another minor annoyance of the Mac operating system. If I drag a file across drives, it copies the file rather than moves it. The article then goes on about how Windows does it wrong, and then tries to justify how "if Windows does it, and Mac doesn't, it must obviously be a bad UI design." (Not a real quote, there)
Personally, while I completely agree that the Windows way has shortcomings, I think it's a bit silly that a Finder window that looks like every other window acts different just because it's a different drive. If I move a file from one window to another, I expect it to move, not copy. Now I'm forced to guess when is a file going to be copied and when is it going to be moved.
It gets even worse when I try to move files on a network drive. The network drive could actually be on many separate drives and that information is hidden from me (and from the OS). Now, if I start moving files, the Mac lets me think I'm doing a move, when really (behind the scenes) a copy and delete is actually happenning. We now get into the exact same problems that the author was saying was bad about Windows. But now, it's actually worse - at least Windows was smart enough to tell the user something was happenning.
Personally, I thought the drag and drop style of moving files was supposed to be a cute graphical interface to the 'mv' command. It doesn't make a lot of sense to me why sometimes it's a 'cp' command and other times it's a 'mv' command. The OS already has a nice "Duplicate" command. If I wanted to copy a file, I would use that and then move the copy. If Apple really wanted to be consistent, they would modifiy Darwin so that 'mv' actually does a 'cp' when you are moving files across drives.
Of course some of my mindset may be due to years and years of programming under Unix and thinking the nicest thing about a windowing system is giving me multiple xterms on one terminal. For the most part (even on the Mac) when I want to move, copy, or delete a file, I feel FAR more comfortable opening up the terminal and doing it that way.
<strong>
Now I'm forced to guess when is a file going to be copied and when is it going to be moved.
</strong><hr></blockquote>
Are we talking OS 9 or X?
I thought that big ugly green plus sign appeared whenever it would copy rather than move?
<strong>Copy again is the better design because of the greater chance of file corruption in the process of moving the file across the network. Copying means you have an intact original. You do have the option of moving the file anyway with the option key, and the threat of file corruption in networks is lower today, but still not negligible. Besides, is copying that unpopular when moving files across a network? Maybe it's because I know I'm making a backup in the process, but I usually prefer to copy to the network.</strong><hr></blockquote>
If that's true, then any drag-and-drop on a network drive should always be a copy, not a move. When you connect to network drives, you don't actually know whether or not those drives are also connecting to another network drive.
For example, I may connect to /home/foo and I want to move a file to /home/foo/bar. It's quite possible that /home/foo/bar is actually mounted somewhere else by the machine that is hosting /home/foo. You now have the same chance of file corruption that you are claiming for moving a file from your local drive to /home/foo.
If we arguing that Apple is making the file transfer safe for us, then the only logical thing for them to do is make sure that any file operations on network drives are copies and not moves.
1) Built-in font management system for activating/deactivating fonts like Suitcase or better yet like ATM Deluxe from OS 9...
...the cocoa-only quasi manager doesn't cut it, they need a REAL font manager.
<strong>splain this to one to me again, Lucy. Any time you move a file from one drive volume to another, whether its a partition or physical volume it will result in a file copy--if you're using the Finder. AFAIK the Finder also represents all drives/drive partitions as seperate devices.</strong><hr></blockquote>
Sure...
Let's say I connect to a file server. When I connect, I give it a machine name and a directory that I want to mount. The Unix command that gets executed will be something like this:
mount /Volumes/foo myserver:/foo
Now, /foo may have several directories under it, such as /bar1 and /bar2. So, the structure looks like this: /foo/bar1 and /foo/bar2
What happens if I use the finder to move a file from /foo to /foo/bar1 ? Does it do a copy or does it do a move?
If you think it should do a move, I would argue that's incorrect (using the Apple logic of how the finder should work) Here's why:
/foo/bar1 could actually be mounted from a different drive on the myserver host. In other words, if we looked at the mount map for myserver, we may see something like
otherserver:/bar1 on /foo/bar1
What this means is that if the Mac OS issued a 'mv' command to move the files, it is not an atomic move. Instead, what actually happens is a copy and delete. As many have pointed out, a copy and delete can be very dangerous and could leave you filesystem in an unpredictable state.
Since the OS has no way of knowing whether or not the remote server is also mounting directories off of other drives, it should do the safe thing and always just copy when moving files from any folder to another (on network drives).
Of course, this would be rather tedious to the user, but it would be safer.