The Dumbest Bug Ever!

[shluk]

I just wanted to share with you this weird bug I've come across.
I had a folder who was name "blabla.avi" and inside that folder there was a video file named blabla.avi. I wanted to move that file out of that folder so i dragged it to the upper folder and then it said that there is already a file with the same name (the "blabla.avi" folder) and asked me what to do. since I didn't need that folder anymore I said "replace". but then it just vaporized both the folder and the file! never to be found again.

I just wanted to warn you from this bug and ask if this has ever happen to anyone before?

 

[GGJstudios]

Why would you have a folder name that includes an extension? Not the best practice! Also, did you check your Trash, to see if the file is there?

 

[maflynn]

I really wouldn't call this the dumbest bug ever given that most people don't use extensions and folders. Heck many mac people do not even worry about file extensions in the first place.

 

[johnhurley]

I just wanted to warn you from this bug and ask if this has ever happen to anyone before?

Sounds more like a typical unix complication than a bug. As someone else noted you typically should not have any kind of extension on a directory ( folder ) in unix.

The power and danger of a unix operating system is that you can do what you want to do ... even when it is not perhaps a good choice.

 

[MisterMe]

I just wanted to share with you this weird bug I've come across.
I had a folder who was name "blabla.avi" and inside that folder there was a video file named blabla.avi. I wanted to move that file out of that folder so i dragged it to the upper folder and then it said that there is already a file with the same name (the "blabla.avi" folder) and asked me what to do. since I didn't need that folder anymore I said "replace". but then it just vaporized both the folder and the file! never to be found again.

I just wanted to warn you from this bug and ask if this has ever happen to anyone before?

Not only is it not a bug, it is the expected behavior. You were trying to replace one object with another object having the same name. Since you cannot place two objects with the same name in the same folder, one had to be deleted. You figured-out a way to delete both. You deleted the folder which, in turn, contained the file that you wanted to keep.

You have a choice. You may use a little bit of logic in your computer operations. You may also hope that the OS developer make the computer you-proof. Apple has done that for some operations and is doing more of that. The downside is that these concessions to stupidity cause other problems--especially those of us with the sense God gave red brick.

 

[laudern]

Not only is it not a bug, it is the expected behavior. You were trying to replace one object with another object having the same name. Since you cannot place two objects with the same name in the same folder, one had to be deleted. You figured-out a way to delete both. You deleted the folder which, in turn, contained the file that you wanted to keep.

You have a choice. You may use a little bit of logic in your computer operations. You may also hope that the OS developer make the computer you-proof. Apple has done that for some operations and is doing more of that. The downside is that these concessions to stupidity cause other problems--especially those of us with the sense God gave red brick.

The OP just got taken back to school by this tongue lashing!

 

[Hyper-X]

is this thread for real or a joke?

 

[fat jez]

The other thing to note is that directories are really files, which contain a list of the files within them. So you tried to overwrite one file (the directory) with another from within that directory. I suppose you could argue that the OS shouldn't allow you to do this, but as others have said, giving a directory a file extension is pretty silly.

 

[ToastyX]

What is wrong with you people? Why are you defending broken software?

Not only is it not a bug, it is the expected behavior.

Are you kidding me? This is not expected behavior. It's not even logical behavior.

The user already expressed their intention to move the file by dragging it out of the folder, which is what brought the prompt in the first place. In this situation, it is never okay to delete both the source and the destination. That doesn't make any sense at all. Not only that, when you replace a folder in the Finder, there is no way to undo the operation.

This is bad design, plain and simple.

You have a choice. You may use a little bit of logic in your computer operations. You may also hope that the OS developer make the computer you-proof. Apple has done that for some operations and is doing more of that. The downside is that these concessions to stupidity cause other problems--especially those of us with the sense God gave red brick.

People keep saying Macs are easier to use and better designed, then you defend nonsense like this and blame the user.

Sounds more like a typical unix complication than a bug. As someone else noted you typically should not have any kind of extension on a directory ( folder ) in unix.

The power and danger of a unix operating system is that you can do what you want to do ... even when it is not perhaps a good choice.

Sounds like you know nothing about UNIX. UNIX doesn't care about file extensions, and Finder is not UNIX. In fact, UNIX would not let you replace a folder with a file like that.

Why would you have a folder name that includes an extension?

I really wouldn't call this the dumbest bug ever given that most people don't use extensions and folders.

Why is everyone focusing on the folder name having an extension when it has nothing to do with the problem? The same thing would have happened if neither had an extension.


This forum makes me so angry. Why do people here go out of their way to defend problems that shouldn't exist?

 

[GGJstudios]

What is wrong with you people? Why are you defending broken software?

It's not broken. It's working as designed, and it's designed properly. This is a case of user error. Folder names shouldn't have extensions and if you move two files with the same name and same extension into the same folder, one will overwrite the other.

This is not expected behavior. It's not even logical behavior.

Yes, it is. See above.

The user already expressed their intention to move the file by dragging it out of the folder,

Dragging it out of the folder is no problem. The problem arose because of where the user was dragging it to.

In this situation, it is never okay to delete both the source and the destination. That doesn't make any sense at all.

Normally, it wouldn't, but the file existed within the folder. When a folder is deleted, so are the contents of that folder. By dragging the file to the same location as its parent folder, which was named identically, the user elected to replace the parent folder, which deleted it and its contents. Thus, the file was deleted. The deletion occurs before the new file can be added to that location, so the folder and its contents were deleted. It's quite logical.

Why is everyone focusing on the folder name having an extension when it has nothing to do with the problem? The same thing would have happened if neither had an extension.

It had everything to do with the problem. If the folder and the file were not named identically, the problem wouldn't have happened.

This forum makes me so angry. Why do people here go out of their way to defend problems that shouldn't exist?

It's not a problem with the software. It's a problem with incorrect user action.

 

[rocknblogger]

Not only is it not a bug, it is the expected behavior. You were trying to replace one object with another object having the same name. Since you cannot place two objects with the same name in the same folder, one had to be deleted. You figured-out a way to delete both. You deleted the folder which, in turn, contained the file that you wanted to keep.

You have a choice. You may use a little bit of logic in your computer operations. You may also hope that the OS developer make the computer you-proof. Apple has done that for some operations and is doing more of that. The downside is that these concessions to stupidity cause other problems--especially those of us with the sense God gave red brick.

Hilarious!! But, the OS should have recognized the conflict and should have warned the user. I would have to assume it did and if so then it's clearly user error.

I'm just really curious why the OP added an extension to the folder. That's the head scratcher :/

 

[GGJstudios]

Hilarious!! But, the OS should have recognized the conflict and should have warned the user.

It did warn the user:

... then it said that there is already a file with the same name (the "blabla.avi" folder) and asked me what to do. since I didn't need that folder anymore I said "replace"

 

[marsmissions]

Behavior is expected. You removed the folder the file was in, the file system can't start moving the file until the conflict is removed.

This is not only expected but is also an intelligent design. On windows your **** would have crashed.

 

[ToastyX]

It did warn the user:

It asked the user if they wanted to replace the destination with the source, then deleted them both with no way to undo. That is obviously not the intended action. Why would a user ever want both the source and the destination to be deleted when dragging a file? That doesn't make any sense at all.

When a folder is deleted, so are the contents of that folder. By dragging the file to the same location as its parent folder, which was named identically, the user elected to replace the parent folder, which deleted it and its contents. Thus, the file was deleted. The deletion occurs before the new file can be added to that location, so the folder and its contents were deleted. It's quite logical.

I know what's happening, but that does not match what the UI conveys. The user already initiated the action of dragging the file out of the folder, but the UI ignored this action and removed the source as if it were still in the destination. That is bad UI design.

Folder names shouldn't have extensions

That doesn't matter and has nothing to do with the problem. There is nothing wrong with folders having extensions, otherwise it shouldn't be allowed.

It had everything to do with the problem. If the folder and the file were not named identically, the problem wouldn't have happened.

That still has nothing to do with extensions. They can be named identically without extensions.

It's not broken. It's working as designed, and it's designed properly. This is a case of user error.

You don't seem to understand that this is a usability problem caused by bad UI design.

----------

Behavior is expected. You removed the folder the file was in, the file system can't start moving the file until the conflict is removed.

This is not only expected but is also an intelligent design. On windows your **** would have crashed.

More nonsense. If you do this in Windows, it warns you: "There is already a folder with the same name as the file name you specified. Specify a different name." That is perfectly reasonable behavior.

 

[itickings]

From a technical point of view, what happened is perfectly understandable. As a user I personally wouldn't even dream of trying to move a file in that way. I don't trust Finder at all to handle any conflicts gracefully.

But seriously, the described behavior is a bug. It is hardly "the dumbest bug ever", but still a bug. As ToastyX points out, the UI can be blamed for doing something under the hood that doesn't correspond 1:1 with the initial action.

 

[yawns]

I agree with the post above. It's not, "The dumbest bug ever," or whatever, but it is a bug. The file manager isn't supposed to let what happened to the OP happen. I did this on my MBP:

$ mkdir a.avi
$ cd a.avi/
$ touch a.avi
$ cp a.avi ../
cp: cannot overwrite directory ../a.avi with non-directory a.avi
$ mv a.avi ../
mv: rename a.avi to ../a.avi: Is a directory

The underlying "unix core," just flat out says "nope," if you try to do this. Linux graphical file managers say the same thing. I don't know about Windows, but I'm almost certain Explorer wouldn't, "crash." If I had to guess, I would bet it would also just say, "You can't do this."

You shouldn't be allowed to do this because it doesn't make any sense. It's like dividing by zero! And because it makes no sense, it is a bug that could cause problems: How does the file system deal with what just happened? Was the space used for the OP's file/s released in the file mapping table? Or is it reserved, inaccessible, and lost? If he had 20GB of stuff in that directory, did he get 20GB back?

 

[johnhurley]

Sounds like you know nothing about UNIX. UNIX doesn't care about file extensions, and Finder is not UNIX. In fact, UNIX would not let you replace a folder with a file like that.

Been doing work in unix since ... well way back. New to macs but unix ... not so much.

How about you?

How many directories have you created with extensions on them exactly?

 

[iThinkergoiMac]

There is nothing wrong with folders having extensions, otherwise it shouldn't be allowed.

This is pretty much the funniest thing I've read all day.

 

[srf4real]

It's a bug, but not the dumbest ever. Why was naming a folder with extension.??

 

[GGJstudios]

Why would a user ever want both the source and the destination to be deleted when dragging a file?

Why would the user name a folder with an extension? That's what doesn't make sense. In this case, the user dragged the source to a destination that necessitated overwriting (deleting) the source before the move could be completed. It made no sense at all to name the folder with an extension. That is the source of the problem.

That doesn't matter and has nothing to do with the problem. There is nothing wrong with folders having extensions, otherwise it shouldn't be allowed.

Just because something is allowed doesn't mean it's a good thing to do. Deleting necessary system files is allowed, but that's not a sensible thing to do, either. As has always been the case, no OS can protect a computer from the greatest source of problems: the user.

That still has nothing to do with extensions. They can be named identically without extensions.

It has everything to do with extensions. If the same operation had been completed with a folder named "test" and a file named "test.txt", there would have been no problem. If both the folder and the file were named "test" with no extension, the same problem would occur.

You don't seem to understand that this is a usability problem caused by bad UI design.

No, it's a user problem caused by bad user choices.

If you do this in Windows, it warns you: "There is already a folder with the same name as the file name you specified. Specify a different name." That is perfectly reasonable behavior.

That is not materially different than "An older/newer item named "test" already exists in this location. Do you want to replace it with the newer one you are moving?" Both alert the user that there is a conflict that must be resolved. It's up to the user to take appropriate action. In this case, the user didn't. It's that simple.

Computers don't do what you intend; they do what you tell them to do. If you type a move command in Terminal when you intended a copy, the computer will do what you told it to do and move, not copy. The user is responsible to learn how to interact with the computer properly, not the reverse.

 

[ToastyX]

Why would the user name a folder with an extension? That's what doesn't make sense. In this case, the user dragged the source to a destination that necessitated overwriting (deleting) the source before the move could be completed. It made no sense at all to name the folder with an extension. That is the source of the problem.

Why do you think deleting both the source and the destination is acceptable behavior for a move operation? Why would you prefer data loss over the more logical option? That's what boggles my mind.

This isn't even a matter of opinion. There is only one way to handle this properly: if the user chooses to replace, then move the source to a temporary location, move the destination to the trash, then move the source to the destination. That way neither the source nor the destination is lost. I don't understand why that isn't done.

I also don't understand where people are getting the idea that folders shouldn't have extensions. There is absolutely nothing wrong with folders having extensions.

Just because something is allowed doesn't mean it's a good thing to do. Deleting necessary system files is allowed, but that's not a sensible thing to do, either. As has always been the case, no OS can protect a computer from the greatest source of problems: the user.

A normal user can't and shouldn't be able to delete system files. Only an admin should be able to do so, in which case, they're on their own.

Computers don't do what you intend; they do what you tell them to do.

The user told it to replace the destination with the source, and it deleted both. That is not doing what the user told it to do.

If you type a move command in Terminal when you intended a copy, the computer will do what you told it to do and move, not copy. The user is responsible to learn how to interact with the computer properly, not the reverse.

You're trying to make it seem like I want the computer to second-guess the user, which is exactly what I don't want.

The mv command would not delete both the source and the destination.

How many directories have you created with extensions on them exactly?

Using periods in directory names is not exactly rare:

1. Renaming a directory named "example" to "example.old" so I can create a new directory named "example" while keeping the contents of the old one
2. Putting the files for a site in a directory named after the domain name, like "example.com"
3. Directories with version numbers like "Example 2.0"

I don't trust Finder at all to handle any conflicts gracefully.

The fact that you can't trust the Finder to handle such a simple operation is exactly what's wrong with Apple software. I'm tired of running into stupid problems with basic functionality and seeing people defend them.

 

[GGJstudios]

Why do you think deleting both the source and the destination is acceptable behavior for a move operation? Why would you prefer data loss over the more logical option?

I wouldn't prefer it, but that's what the user chose by their actions.

This isn't even a matter of opinion. There is only one way to handle this properly: if the user chooses to replace, then move the source to a temporary location, move the destination to the trash, then move the source to the destination. That way neither the source nor the destination is lost. I don't understand why that isn't done.

Name one OS that does that. It's not a realistic expectation.

I also don't understand where people are getting the idea that folders shouldn't have extensions. There is absolutely nothing wrong with folders having extensions.

Obviously, there is, as this thread illustrates.

A normal user can't and shouldn't be able to delete system files. Only an admin should be able to do so, in which case, they're on their own.

A normal user certainly can delete system files, as long as they have an admin password. Any Mac user is a normal user, whether they run a standard or admin account.

The user told it to replace the destination with the source, and it deleted both. That is not doing what the user told it to do.

That may not be what the user intended, but that is what the user told it to do. This forum is filled with examples where a user got results they didn't intend by doing something without fully understanding the implications of what they were doing. Such is the case here.

The fact that you can't trust the Finder to handle such a simple operation is exactly what's wrong with Apple software. I'm tired of running into stupid problems with basic functionality and seeing people defend them.

You can trust Finder to do exactly what it was designed to do. The failure of any user to understand how Finder works does not indicate that anything is wrong with the software. I'm not saying any software is flawless, and Finder certainly has shortcomings, but this is a case where the user didn't think through the consequences of the action that they chose. I would have never tried to do what this user did.

 

[yawns]

I don't know why everyone is focusing on the fact that the directory had a dot with some letters after it in its name. It's perfectly valid to do that. Alternately, he could have had a directory called "vacation," and an image in that directory called, "vacation," with no extension, which is also valid.

The end result is that the user over-wrote a directory with a file from within itself, and that is not supposed to happen. No current file manager - not pre-Lion Finder, not Explorer, not Nautilus, not Konqueror, not any single terminal command - will allow you to do that. This isn't just to protect the user from doing something dumb, it's because it doesn't make sense.

The only place you can do what the OP did is Lion's Finder. Does anyone really think when they were working on Lion, the developers sat around and said, "Hey, this event that almost never happens but has been disallowed since file management began... yeah let's get rid of that and instead make it destroy all the data the user is working with." Or do you think it's more likely that this is a bug specifically in Lion's Finder?

 

[rocknblogger]

I don't know why everyone is focusing on the fact that the directory had a dot with some letters after it in its name. It's perfectly valid to do that. Alternately, he could have had a directory called "vacation," and an image in that directory called, "vacation," with no extension, which is also valid.

The end result is that the user over-wrote a directory with a file from within itself, and that is not supposed to happen. No current file manager - not pre-Lion Finder, not Explorer, not Nautilus, not Konqueror, not any single terminal command - will allow you to do that. This isn't just to protect the user from doing something dumb, it's because it doesn't make sense.

The only place you can do what the OP did is Lion's Finder. Does anyone really think when they were working on Lion, the developers sat around and said, "Hey, this event that almost never happens but has been disallowed since file management began... yeah let's get rid of that and instead make it destroy all the data the user is working with." Or do you think it's more likely that this is a bug specifically in Lion's Finder?

I don't disagree with some of what you say but, computers function and execute commands based on user input. In this case the user was warned that there was a conflict but rather than resolve the conflict the user told the computer to go ahead and execute the command.

When I see a conflict error I stop the operation and resolve whatever the problem is first. I think most experienced computer users will do the same thing. The user should have been more careful and should have aborted the operation.

With that said, I also disagree with you that there should be no problem adding an extension to a folder. I personally have never seen this. I know that doesn't mean it has never been done, but as an experienced user would you add extensions to folders?

I think we can agree that computers are dumb and without user input or interaction they don't function. Considering that as a rule of thumb folders don't have extensions, isn't it logical to assume that a computer would interpret a folder with an extension as a file? I certainly think so.

Also it's not so much that he gave the folder an extension, it's that he gave it an extension and name identical to a file. If he named it something like foo.video or foo.my.edits there would not have been a problem. But while we would like to think that computers are smart they simply don't recognize the difference between foo.mp3 and a folder named foo.mp3.

I really don't think this is a bug. His problem arose due to user error, both by not heeding the warning and by naming a folder according to file standards reserved for files.

 

[johnhurley]

Using periods in directory names is not exactly rare:

1. Renaming a directory named "example" to "example.old" so I can create a new directory named "example" while keeping the contents of the old one
2. Putting the files for a site in a directory named after the domain name, like "example.com"
3. Directories with version numbers like "Example 2.0"

Personally I think it is a bad idea ... a really bad idea.

Just because you can get away with things does not mean you should do them or recommend them to other people. If you are going to start creating directories with periods in them on "your systems" have fun. Not on any of my Oracle database servers thank you very much.

You started talking some smack about knowing stuff. To me most of what you are trying to back pedal with is smoke and mirrors.

Just my opinion.