The Dumbest Bug Ever!

[ToastyX]

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

No other OS would allow the user to replace a folder with a file, so the point is moot. If they did allow it, the way I described would be the proper way to handle it.

You can trust Finder to do exactly what it was designed to do.

No, I really can't. I can't even trust the Finder to copy files correctly. I've run into cases where the Finder doesn't copy everything that you told it to copy, then acts like the operation completed successfully, so you don't even realize it didn't copy everything until you discover files are missing.

There are numerous examples of this in both Snow Leopard and Lion:

Snow Leopard:
https://discussions.apple.com/thread/2230585
https://discussions.apple.com/thread/2442766

Lion:
https://discussions.apple.com/thread/3211447
https://discussions.apple.com/thread/3208901
https://discussions.apple.com/thread/3204529
http://mrmacmusic.wordpress.com/2011/07/26/lion-finder-copying-bug/

It's not only the Finder. Mac OS X is full of stupid problems like this, yet people on this forum go out of their way to claim how superior it is while defending problems and passing the blame. Now you are defending a data loss bug and trying to blame the user. Is this honestly how you think computers should work?

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.

The user was asked how to resolve the conflict and the user told it to replace, not delete everything.

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.

The only reason you feel this way is because you're used to badly designed software getting confused over simple things. The difference is I'm blaming bad design while you're blaming the user for not knowing the design is bad.

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?

You shouldn't assume anything. You should test to see how it actually works before claiming it works that way.

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.

Completely absurd. Where do you come up with this stuff?

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

Back pedal? If you have UNIX experience like you claim you do, then you should already know:

1. UNIX doesn't care about file or folder extensions.
2. Folders with extensions have nothing to do with the problem.
3. UNIX would not let you replace a folder with a file like the Finder does.

That covers the entirety of your post and none of it was relevant to the problem, so why did you bring up UNIX and folder extensions in the first place? You have contributed nothing to this thread other than trying to pass the blame to the user with misguided information. There is absolutely nothing wrong with creating directories with periods in them.

I'm tired of wasting my energy on this thread. Everything that needs to be said has already been said, so there's no point in continuing.

 

[GGJstudios]

There is absolutely nothing wrong with creating directories with periods in them.

No one said anything about creating directories with periods in them.

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"

None of the examples you posted represent naming a folder with a file extension, which was the mistake made by the OP. Having a period in a folder name is not the same as adding a file extension, which is used to identify a file type and is associated with an app that expects to be able to open such a file.

As for your other points, they've all been addressed already. You continue to talk trash about Mac OS X, but I haven't seen you offer any better-designed OS. The fact is, a large percentage of computer users (most likely the majority), whether using Mac OS X or Windows or Linux or others, are basically computer-illiterate, knowing just enough to do basic things. When something doesn't go as they expect, they are quick to blame the computer or the software, rather than admit they made a mistake. Mac OS X is better designed than the vast majority of users' thought processes.

The fact remains that the biggest problem with any computer is the fleshy part between the keyboard and the chair.

 

[yawns]

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.

But they can! I'll show you below...

Having a period in a folder name is not the same as adding a file extension, which is used to identify a file type and is associated with an app that expects to be able to open such a file.

"Adding an extension," means exactly, "putting a period and some letters on the end of a file name." That's all an extension is -- an "extension" of the file name. The name could end with .txt or .html or .narf, it's all the same. There's nothing magical or special about situations where the arbitrary combination of letters is something that you recognize.

File name suffixes are meaningless as far as the actual OS (not the file manager) is concerned. A text file called, "a.txt," "a," "a.avi," or "a.ksjdkjskdjks" is still a text file. Renaming bob.jpg to bob.avi doesn't make it a video. Doing so changes nothing about the file -- it only tricks the Finder into trying to open the file with the wrong application.

http://en.wikipedia.org/wiki/Filename_extension

In UNIX-Like OS's, the file type is determined by the file's headers, magic number, and the like. Every UNIX-Like OS is intelligent enough to reference these things and figure out the difference between a directory and a file. It's a very basic thing.

$mkdir a
$ file a
a: directory #it's a directory
$ mv a a.avi
$ file a.avi
a.avi: directory #still recognized as a directory
$ echo "a" > a.avi/
-bash: a.avi/: Is a directory #can't write to a.avi, because it's a directory
$ touch a
$ mv a a.avi
$ ls a.avi/
a #mv moved the file into the directory a.avi, rather than rename and overwrite, as it would have done had a.avi not been a directory (if it didn't exist or was a regular file)
$ cd a.avi/
$ mv a a.avi #now we moved and renamed
$ mv a.avi ../
mv: rename a.avi to ../a.avi: Is a directory #prevented from replacing a.avi directory with a file of the same name
$ cp a.avi ../
cp: cannot overwrite directory ../a.avi with non-directory a.avi #same as above

The above demonstrates that the OS will not allow you to overwrite a directory with a file. You couldn't do it, anywhere, in any OS, ever, until Lion. Only Lion's Finder allows you to do it, because Lion's Finder has a bug.

Again, for those of you who prefer to blame the user instead of Apple, I want to stress once more that you couldn't even do this in previous versions of OSX. Which means that only two scenarios are possible: Either the developers actually considered this very obscure usage, and then consciously decided to make a change that destroys the user's data rather than protects it; or they inadvertently broke something that wasn't caught in testing because it happens so rarely.

Also again(!), all of this discussion on the "extension," is completely irrelevant. A directory with no dots in its name containing an identically named file (with no extension, which is perfectly valid) would produce the same results. That is the issue at hand. A file overwrote its parent directory and consequently destroyed itself. The naming convention employed really doesn't matter.

 

[johnhurley]

Back pedal? If you have UNIX experience like you claim you do, then you should already know:

1. UNIX doesn't care about file or folder extensions.
2. Folders with extensions have nothing to do with the problem.
3. UNIX would not let you replace a folder with a file like the Finder does.

Whatever. If you want to create directories with periods in them on your system please feel free to do whatever floats your boat.

Not a good idea at all in my opinion. Directories with suffixes like ".avi" ... yikes!

Back off with the attitude about "like you claim you do" stuff.

 

[mrgraff]

Great explanation, yawns.

I still wouldn't call it a bug though, perhaps a UI design flaw. "Replace" worked exactly as we techies would expect it to: by first deleting the folder that contained the file. In a file-replacing-folder (or vice versa) context, the Finder should've been programmed to either not allow replacement with a more detailed error message, or only offer the "Keep both" option with more details.

 

[Farthen]

This thread is just hilarious. I love how so many people say that file extensions in folder names are a bad thing. I bet your Mac has folders with dots in them too! Let me see… /Applications/Finder.app/ ? Yes, Mac OS X Applications are actually folders with some special properties. And you are saying it is a bad idea.
Let me find some more. /System/Library/Extensions/ is full of Kernel Extension "files" ending with ".kext" which are actually folders. Want more? Lets look into the Library. What about ~/Library/Application Support/com.apple.QuickLook ?

There are lots more of those. Why don't you start deleting them all? They may put your system's stability at risk!

And the same people defend that the user has to think before losing files due to stupid bugs. Even an error message would be fine but *deleting* both the target and the destination without warning the user nor giving him an option to get the files back is NOT how it should work. Seriously.

 

[KnightWRX]

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.

That's not what the OP described nor is it what is happening. Test it out. Create a folder named test.txt and place within it a file named test.txt. Proceed to drag the file out of the folder to the parent.

It'll say that an item named "test.txt" already exists and ask you what you want to do (Keep both files, stop or replace). If you pick Replace, you expect the folder to disappear and the file test.txt to appear in its place right ?

Well that's not what is happening, both the folder and the file are gone after choosing "Replace".

In fact, it seems you're arguing about the "extension" (there's no such thing, "." is an accepted character for filenames under Unix, there is no special meaning to what comes before or after the ".". This isn't DOS) when that's not the problem. Create a folder named test and place a file in it named test also. Try again. Same buggy behavior, Finder proposes to "Replace", yet Replace results in losing both the folder and the file.

 

[MagicBoy]

That's not what the OP described nor is it what is happening. Test it out. Create a folder named test.txt and place within it a file named test.txt. Proceed to drag the file out of the folder to the parent.

It'll say that an item named "test.txt" already exists and ask you what you want to do (Keep both files, stop or replace). If you pick Replace, you expect the folder to disappear and the file test.txt to appear in its place right ?

Well that's not what is happening, both the folder and the file are gone after choosing "Replace".

It is working as intended. You choose replace, therefore the OS deletes the "old" test.txt. That's the folder that happens to contain the file test.txt you want to move.

The process is check for conflict -> resolve conflict -> move object

It can't move the object as the previous step deleted it.

As said above, don't name folders with the same endings as common Windows file extensions.

 

[mrgraff]

That's not what the OP described nor is it what is happening. Test it out. Create a folder named test.txt and place within it a file named test.txt. Proceed to drag the file out of the folder to the parent.

It'll say that an item named "test.txt" already exists and ask you what you want to do (Keep both files, stop or replace). If you pick Replace, you expect the folder to disappear and the file test.txt to appear in its place right ?

Well that's not what is happening, both the folder and the file are gone after choosing "Replace".

No, I think you're both right.

When you "replace" here's what happens:
1. note location of file/folder being moved or copied
2. file/folder being replaced is permanently deleted
3. file folder to copy/move is put it the new location

Unfortunately, in the OP's case, the file being copied happened to reside inside the folder being deleted. That's why some of us don't see it as a bug.

You're right from your perspective that a "replacement" isn't occurring, but it is (with unintended consequences) from the file system's perspective of what a "replace" action means.

What if there was something else inside the folder? This why the "keep both" option is presented - which the OP clearly didn't select. It's user error - unintentional, but still user error.

 

[KnightWRX]

No, I think you're both right.

When you "replace" here's what happens:
1. file/folder being moved or copied is placed on the clipboard
2. file/folder being replaced is permanently deleted
3. file folder on clipboard is put it the new location

Unfortunately, in the OP's case, the file being copied happened to reside inside the folder being deleted. That's why some of us don't see it as a bug.

So the OS proposes you to replace the folder with the file and then proceeds to do something else entirely, and you don't see it as a bug ?

Gotcha.

You're right from your perspective that a "replacement" isn't occurring, but it is (with unintended consequences) from the file system's perspective of what a "replace" action means.

AKA, a bug. There is no such thing as unintended consequences in computer parlance. Either what you expect happens or there is a bug in the code. This is an untrapped case where Finder needs to do an extra operation for the Replace to occur, that is move the file to a temporary location before issuing the unlink() on the folder.

What if there was something else inside the folder? This why the "keep both" option is presented - which the OP clearly didn't select. It's user error - unintentional, but still user error.

Selecting an option the software proposes is not user error, but I'll humor you, why don't we try what happens if you try to replace the non-empty folder with the file with the same name ?

I just did and it deletes everything. Nice bug.

Either Finder needs to be fixed to warn the user of the potential data loss from the replacement (replacing a folder with a file of the same name might make you lose the data in the folder) and make sure to actually have a copy of the file to replace the folder with or the Replace button needs to be greyed out under such circumstances (or completely removed).

Anything else is "unintended consequences" like you say, aka, a bug.

 

[GGJstudios]

In fact, it seems you're arguing about the "extension" (there's no such thing, "." is an accepted character for filenames under Unix, there is no special meaning to what comes before or after the ".". This isn't DOS) when that's not the problem.

I'm not saying that naming the folder with an extension caused the problem. It's simply a bad practice that can lead to problems such as the one here. Naming the folder exactly the same as the file that was being moved to the same location is the problem.

 

[KnightWRX]

I'm not saying that naming the folder with an extension caused the problem. It's simply a bad practice that can lead to problems such as the one here. Naming the folder exactly the same as the file that was being moved to the same location is the problem.

The problem is the Finder bug that offers "Replace" when it can't reliably complete the operation.

 

[mrgraff]

KnightWRX, you're right.

I was confusing "bug" with "program error." I still maintain that user error was involved due to providing the file system with an unreconcilable naming conflict, but I also agree that a situation like this needs to be preventable.

 

[KnightWRX]

Whatever. If you want to create directories with periods in them on your system please feel free to do whatever floats your boat.

Not a good idea at all in my opinion. Directories with suffixes like ".avi" ... yikes!

Back off with the attitude about "like you claim you do" stuff.

When did the period start being a delimiter for "suffixes" in Unix ? The only special case where the period means anything else than a simple accepted filename character in Unix is if it is the first character in the filename, which then results in the file not being displayed when using the ls command unless you specify the -a option, or if only a period is used, the file represents the current folder, or if 2 consecutive periods are used at the start with no other characters, the file represents the containing (aka parent) folder.

----------

KnightWRX, you're right.

I was confusing "bug" with "program error." I still maintain that user error was involved due to providing the file system with an unreconcilable naming conflict, but I also agree that a situation like this needs to be preventable.

The user did nothing that was erroneous here. A user error is something akin to what I recently did, forget to specify arguments to a command, resulting in a different (yet documented) behavior that what the user expected.

In my case, I issued the vgchange --deltag vgname command, which is wrong syntax. The actual syntax should be vgchange --deltag <tagname> [optional vgname]. The system thus tried to remove the tag "vgname" from all VGs on the system (the described behavior for the syntax I used by mistake) instead of removing the tag from the VG I wanted it removed from.

That is a user error (and with the way our stuff is built, quite the fatal mistake unfortunately...).

In this case, the user did no such errors. Nowhere is it specified in any documentation that a directory cannot contain a file that has the same name as it does.

I don't quite understand the resistance to saying this is a bug here when it obviously is. What's wrong guys ? OS X has bugs, like all software does. To admit so and fix the bugs instead of arguing they are "user error" is how the software gets better.

 

[EMKoper]

I see it all the time folder.name.with.periods

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?

Uhm... because when it is a folder object it is just text ... OS X Lion has a bunch of folders with "." in the names... such as the following OS X folders:

iLifeFaceRecognition.framework

Cocoa.framework

Got to System -> Library -> Frameworks ... and you find about 50 in a row with "." in the folder name!

I work in a tech environment and I see it all the time...

 

[mrgraff]

Nowhere is it specified in any documentation that a directory cannot contain a file that has the same name as it does.

Damn. You're good. This wasn't a competition, I know, but remind me never to try debating you in real life!

 

[iThinkergoiMac]

I can replicate this as well. It's definitely a bug, as the command line refuses to allow this and if I use Path Finder to try, it also does not allow it.

 

[Comeagain?]

It's not a "bug", it's a Feature!

 

[MisterMe]

... It's definitely a bug, as the command line refuses to allow this ...

Among the many red herrings proffered by the OP's supporters, this is one of the worst. The MacOS X GUI is not and never has been a replacement for the UNIX command line.

I might also say that whether or not the folder has an extension is quite besides the point. The OP gave his folder the same name as a file that it contained. That was bad, but did not cause his current problem. He tried to replace the folder with a file of the same name. The OS warned him and gave him alternatives. His problem was caused by the fact that he chose the worst of all possible alternatives.

The OP has no one to blame but himself. On the bright side, this episode can serve as practice for his Darwin Award competition.

 

[iThinkergoiMac]

The OS warned him and gave him alternatives. His problem was caused by the fact that he chose the worst of all possible alternatives.

The OS didn't warn so much as ask. "What do you want to do?" isn't a warning. The OP chose replace, which didn't replace but deleted. It also seems that this result only happens in Lion, not in SL or Leopard.

So, I ask you: when you tell the OS to replace, is it logical that it should delete instead? Especially when this does not conform to past behavior?

 

[KnightWRX]

Among the many red herrings proffered by the OP's supporters, this is one of the worst. The MacOS X GUI is not and never has been a replacement for the UNIX command line.

I might also say that whether or not the folder has an extension is quite besides the point. The OP gave his folder the same name as a file that it contained. That was bad, but did not cause his current problem. He tried to replace the folder with a file of the same name. The OS warned him and gave him alternatives. His problem was caused by the fact that he chose the worst of all possible alternatives.

The OP has no one to blame but himself. On the bright side, this episode can serve as practice for his Darwin Award competition.

Yes, because when the Finder (not the OS, why do people keep equatting Finder with the OS ?) asks you if you want to "Replace", and you choose to "Replace" and then find out everything is deleted, you have no one to blame but yourself.

Again guys, why the denial ? It's a bug. Bugs happen. Don't deny bugs, understand and fix them.

This one should definately be submitted to Apple.

 

[arubinst]

Although the problem has already been extremely well explained, with convincing and logical arguments and even experimental manipulations using Terminal, some posters are still recurring to incredibly thin "reasons" trying to make their point that the OP is the one to blame for this.

I went ahead and tried to do the same thing the OP did using Windows 7 and Ubuntu. My folder and file here are called test.txt.

Here's what I found...

Windows 7

Notice how Windows Explorer correctly realizes that there's a folder with the same name as the file being moved? The only options proposed are "Try Again" and Cancel. Clicking on "Try Again" will just continue to show the same window over and over until "Cancel" is selected or any other corrective steps (renaming the folder???) are taken.

Ubuntu

Again, the folder "type" is correctly identified. In Ubuntu, we're presented with an option similar to the one that was proposed to the OP by Finder, i.e., "Replace". So, I went ahead and clicked "Replace".

Surprise! The file manager was smart enough to detect the potentially dangerous manipulation and stopped me from doing something wrong. It accurately tells me that "The source file would be overwritten by the destination". Only two options are available, "Cancel" and "Skip". In the first case, the whole operation is stopped. Clicking Skip makes sense if more than one file was being moved out of the folder. This would just skip this file and continue moving the others that would not create a conflict.

Mac OS X is a powerful and very well built OS and Apple has always taken pride in the simplicity and intuitiveness of the UI. There's no excuse to what's happening here... The situation found by the OP is an oversight (a.k.a bug).

 

[fat jez]

I don't think I'd call it a bug, so much as a glaring design error. A bug implies code that is not executing correctly, which I don't think is the case here. The code executes correctly, but the design it is written against is wrong.

On another point of note, the underlying file system is not the problem, as it will not allow you to do this, it's how Apple have chosen to implement file replacement in Lion.

I would suggest the OP provides feed back to Apple on this.

 

[MisterMe]

Although the problem has already been extremely well explained, with convincing and logical arguments and even experimental manipulations using Terminal, some posters are still recurring to incredibly thin "reasons" trying to make their point that the OP is the one to blame for this.

....

What you have posted is all good and fine, but you miss a very important point. The user may want to replace a folder with a file of the same name. This, in fact, narrowly defines a most general feature of MacOS X. In MacOS X, files are objects. Folders are also objects. Generally stated, the OP replaced one object with another object of different type but with the same name. To implement the nanny state that you want would dramatically reduce the usability of the OS. For example editing file named let's day "letter.doc" with a different version of Word than the one used to create the file may change its type. MacOS X takes note of the change in type. It would be a massive pain not to be allowed to replace one object type with another. In fact, I currently have file synchronization and backup work-flows that would not work under those circumstances.

There is no perfect world or perfect system. It should be the user's choice to replace objects with others of different type. Apple gets it right by giving warning that this is about to happen. Intelligent people will get it right. For the stupid ones, we have the Darwin Awards.

 

[arubinst]

The user may want to replace a folder with a file of the same name. This, in fact, narrowly defines a most general feature of MacOS X. In MacOS X, files are objects. Folders are also objects. Generally stated, the OP replaced one object with another object of different type but with the same name. To implement the nanny state that you want would dramatically reduce the usability of the OS. For example editing file named let's day "letter.doc" with a different version of Word than the one used to create the file may change its type. MacOS X takes note of the change in type. It would be a massive pain not to be allowed to replace one object type with another. In fact, I currently have file synchronization and backup work-flows that would not work under those circumstances.

There is no perfect world or perfect system. It should be the user's choice to replace objects with others of different type. Apple gets it right by giving warning that this is about to happen. Intelligent people will get it right. For the stupid ones, we have the Darwin Awards.

I'm sorry pal, but Ubuntu will let you replace a folder with a file if the file does not reside inside that same folder. So the user's choice is respected. The only situation when you are not given the possibility to do this is the one described by the OP and shown by my previous post.

I don't think Apple is getting it right. The warning given by finder does not say that both files will be deleted.

Getting it right is doing what the user wants or not doing anything at all.

Intelligent people should know this...