Wednesday, November 09, 2005

Night of the Living xyiznwsk

Dreamweaver hotfix needed

A friend of mine, lets call him Fhwqhgads, is having a problem with his Dreamweaver 8 install adding strange folders to his Visual Source Safe database. As he works on his projects, periodically, DW8 adds a directory called "xyiznwsk". Sometimes the directory is empty and sometimes it isn't. When it's not, it contains either a control file for checkin/checkout or a copy of a template that was being checked in.

In past versions of DW, this folder was used to help synchronize system clocks with remote sites. As far as I know, DW would write this file to the remote site, use it for a short time, and then delete it without the user really being aware of it -- when everything is working correctly. If you have some other piece of software or network conditions that interrupt the process or prevent the files from being deleted, the folder can be left behind.

In the case of VSS, it's pretty obvious what is causing the folder (and files) to be stranded. If the VSS account doesn't have rights to destroy a file in the db, then they are only going to be able to delete the first occurrence before VSS requires that the previous directory/file be destroyed. Every time I attempt to connect to the remote site using the button in the files panel, I get a message telling me I don't have destroy rights to the project. That's when I think DW is attempting to delete the folder/file.

VSS doesn't have a command in it's api to allow the remote application to determine the date in use by the machine. When you set up a site with VSS as your remote option, the checkbox for maintaining synchronization information is disabled. You would think that that would prevent DW8 from attempting to retrieve the timestamp of the remote server, but it doesn't appear to be working.

I haven't been able to find a workaround for this issue at this point. If you know of a way to get this to stop happening, please post a fix or reference.

I know of one Government organization that has stopped deploying DW8 because of this single issue.


  1. I haven't searched yet for new technotes on that synching folder, but has your friend contacted support yet, or hit the newsgroups?

  2. We were unable to find anything about this issue in the tech notes that dealt with both DW8 and VSS. Nothing direct about it either in the forums that we could find or in general internet searches.

    I don't think he has contacted tech support yet, and neither have I.

    I have been able to reproduce the issue though and can trigger it at will by either doing a checkout or attempting to connect to the remote server with the button in the files panel.

    I guess an email to tech support is in order, but I was hoping that maybe a fix/workaround already existed.

  3. Hey, yes please file an incident with us in support here:

    I havent heard of this issue yet until now. There might be a work around. Once you create a support incident, we can work with you to resolve the issue or determine if its a bug and go from there.

  4. Thanks Alan,
    I submitted a request earlier today. There are too many nice things in DW8 to let people grab an easy issue and use it as a reason to resist change.

    Funny how sometimes small or trivial issues become mission critical simply becasue we wish them to be.

  5. 09 November, 2005 22:04 is the last time this issues was discussed did you guys get a solution.

    I have the same problem cant connect to my db so I cant create db based pages any help

  6. @David,
    Unfortunately, this issue has nothing to do with databases or connectivity. Your connection issue probably lies elsewhere.

    As for this problem, yes, there have been many things that have resolved the problem. The best one is to move away from VSS (okay, just kidding there). Seriously, the simplest way to correct the problem is to grant delete rights to the VSS account. Some people may balk at the idea of giving their whole team delete rights, but think about it. Isn't a major reason for using source control is that it can protect your team from the occasional errant deletion? You just recover the file if there is a problem.

    There is no actual harm to that crazy file being in your application, it's just annoying.

    So what is going on here is that this file is added to source control fine, but when it attempts to delete it, it can't because your vss account doesn't have delete rights. I haven't tested it with CS3, and I don't plan to since I no longer use VSS.