Submit Hint Search The Forums LinksStatsPollsHeadlinesRSS
14,000 hints and counting!

Be aware of possible data loss when saving from iWeb Apps
To my complete and utter horror I discovered a serious bug in iWeb that results in potential data loss of any files or folders ... here is the brief story.

I created an application and had all the source files in a folder on the desktop named, for this example, My Great Application. I had put months of work in to this baby; endless hours! Once the application was complete, I decided I needed a web site to display it. Not being a web designer, I decided iWeb would be a quick way to make a site. I called the new site, yes, you guessed it, My Great Application (the site name is set in the Site tab of the Inspector panel).

Once my web site was complete, I used the "Publish To A Folder" option and saved it to the desktop. Imagine my disbelief when iWeb decided the folder containing all my source code must contain an old version of the site I was publishing and deleted it -- all gone, replaced by iWeb's HTML and images. I was not warned the folder already existed, and the save dialogue box did not indicate that iWeb would create a folder with that name. This is a major bug, and you should be aware of it if you're using iWeb.

Luckily I had a backup on an external drive and also on a pen drive -- others may not be so lucky.

[robg adds: I tested this, and it's definitely an issue -- the contents of any existing folder of the same name will simply vanish without warning.]
    •    
  • Currently 2.00 / 5
  You rated: 3 / 5 (4 votes cast)
 
[8,326 views]  

Be aware of possible data loss when saving from iWeb | 11 comments | Create New Account
Click here to return to the 'Be aware of possible data loss when saving from iWeb' hint
The following comments are owned by whoever posted them. This site is not responsible for what they say.
Be aware of possible data loss when saving from iWeb
Authored by: mozart111 on Dec 19, '06 09:14:06AM

Same thing happend to me. I have a folder of various iWeb domains all in their own folders. I created a new site in iWeb and before I shut dwon for he night I published it into the same folder as the Domain file is located. I figured this was logical. Keep all files of a specific site in the same folder. Published. Shut down and sent to bed. Next day went to do some work on the Domain file. Went to the folder and it couldn't be found. Just the publshed site. I went nuts looking. Figuring I must have screwed up. I looked everywhere. Nothing. Couldn't find the Domain file anywhere.

On researching at the Apple forums, that's the first question I was asked in a reply. Did I save in the samee folder as the domain file. Yes I answered. The pulished site overwrites the Domain file. WTF. How can iWeb overwrite the currently open domain file? It does!

Make sure you either rename it or as I do, publish to a whole new folder, with a new name, in a different location of the Domain file.

I can't believe Apple has not fixed this yet. This is literally something that Microsoft would do. And Apple designed it this way.



[ Reply to This | # ]
Be aware of possible data loss when saving from iWeb
Authored by: phrayzee on Dec 19, '06 09:28:58AM

I don't think this is a bug per se. The default behavior of OS X is that if two folders have the same name but different contents, when you "copy" the contents of folder A over the contents of folder B, the contents of folder B are deleted and replaced with the contents of folder A. While this is an issue, it doesn't sound like a bug to me.



[ Reply to This | # ]
Be aware of possible data loss when saving from iWeb
Authored by: Dave Andrews on Dec 19, '06 11:27:44AM

Of course it is a bug. A copy operation took place without your express knowledge. The destination folder had never been used before by iWeb, it contained information not intended for iWeb. I did not ask iWeb to copy its output to this folder, iWeb chose to do this - without warning.
If you don't think its a bug then create a web site and call it any of the following
'Users', 'Applications', 'System', or 'Library' and save it to the top level of your hard drive. When it trashes your system without warning, remind yourself its default OS X behavior!

WARNING - DO NOT TRY THE ABOVE EXAMPLE



[ Reply to This | # ]
Be aware of possible data loss when saving from iWeb
Authored by: frgough on Dec 19, '06 12:02:44PM

I doubt that would work; you don't have write privileges for anything in System, so that will fail. Replacing Applications or Library will also probably fail since some of the files in those folders also will not be writable by you so you will not be able to replace them.

That said, the lack of confirmation of overwrite is a nasty bug.



[ Reply to This | # ]
Be aware of possible data loss when saving from iWeb
Authored by: fbitterlich on Dec 20, '06 02:38:38PM

Hmmm? Of course OS X does _not_ work this way. If it would replace the _contents_ of a folder every time you copy the _contents_ of another folder into it, with no name conflicts, how would you ever merge the contents of two folders?

OS X itself (read: the Finder) does never replace anything as long as the names are different. The problem described in this hint is unique to the iWeb application and is caused by iWeb thinking it "owns" the published folder. Serious bug if you ask me, and definitely against Apple's own guidelines.



[ Reply to This | # ]
Be aware of possible data loss when saving from iWeb
Authored by: frgough on Dec 19, '06 11:59:44AM

The bug is that the program does not ask you to confirm the overwrite; it just does it without any user interaction.



[ Reply to This | # ]
Be aware of possible data loss when saving from iWeb
Authored by: ksbrett on Dec 19, '06 02:56:09PM

It's not a bug, it's undesirable behavior. Unless, of course, the designers meant for the program to prompt the user before overwriting and failed to implement that feature properly. That would make it a bug.



[ Reply to This | # ]
Be aware of possible data loss when saving from iWeb
Authored by: pub3abn on Dec 19, '06 04:31:54PM

Very undesirable behavior (if not an explicit feature) = bug



[ Reply to This | # ]
Be aware of possible data loss when saving from iWeb
Authored by: tinker on Dec 20, '06 05:53:58AM

(sigh) It really depends on your prior beliefs about what an operating system should do. Mac folk, who have been sheltered since the computer's inception from doing things to themselves that might be harmful, like overwriting folders, will see this as a bug. Unix folk, who are more accustomed to being given all the rope they need to hang themselves, will see it as a lack of a safeguard.

Regardless of the term, I think we can all agree that, because most other programs warn before allowing this behavior, it's a flaw in iWeb that deserves to be publicized and needs to be fixed.



[ Reply to This | # ]
Be aware of possible data loss when saving from iWeb
Authored by: Dave Andrews on Dec 20, '06 07:54:49AM

Sorry, but I disagree. The application creates a folder, this replaces an existing folder without warning. iWeb does not indicate that it will replace the folder, it does not warn you what it will call the folder and hence you can't even guess it will do this.
Saying this is a lack of a safeguard is absurd. You can't possible know iWeb will create a folder with the name of your site, so how can you protect against an existing folder being overwritten.
I have used Unix for years, I don't see your comparison. Sure I can replace files or folders and not be prompted to confirm. If I saved a file I generated in vi and vi decided to also generate a folder of an unknown-to-me name, which replaced an existing folder would you say "oh well, serves me right for using Unix"
<SIGH>



[ Reply to This | # ]
Be aware of possible data loss when saving from iWeb
Authored by: frgough on Dec 20, '06 08:16:56AM

Give the UNIX snobbery a rest. It's stupid, asinine, incompetent design to allow any action that may destroy data without requiring user confirmation, and anyone who says "you should have known better," is an arrogant asinine jerk.



[ Reply to This | # ]