RE: [cobalt-users] Front Page and FTP access permissions

["Carrie Bartkowiak" <admin@xxxxxxxxxxxxxxxxxx>]

||>Paul Donovan  wrote:
||>>Why does Front Page interfere with permissions to folders when
||>>accessed by site administrator via FTP?  If I access the site with
||>>Front Page then permissions are lost for the site administrator.
||>>Have I set something wrong, or can I make some change to settings ?
||>>
||>>Paul

Paul,
Methinks it depends on what you *do* with FrontPage and those folders/files
you've FTP'd in once you connect.
I have a site on my RaQ4 where I do both FP and FTP. The things that I FTP
up have never changed ownership, and I have applied Cobalt's FP update and
the big OS update released in December.
I also have quite a few clients that use only FP to publish their sites; but
I have installed CGI/PHP scripts for them via FTP using their login. For
months now, those scripts have gone untouched by FP, and all is well.

However, I have one client who knows nothing about adminstering a web site.
I don't mean to downtalk one of my clients here, but I must set up the
environment for you - this person goes out and solicits business as a web
site developer. He then has one of two other people actually design and
publish the site for him with FP. After that, he has been attempting to make
small changes to the site here and there (maintenance) with FP on his own
machine. Regardless of the massive amounts of html he's messed up, he's also
driving me insane with the scripts he had me install. He knows no
html/cgi/perl/php, and absolutely nothing about actually publishing a web
site. To him, creating a website really does mean paying someone else to
make it for you, and then just using the pretty buttons in FrontPage to
change stuff.
Well, he keeps trying to 'update' those scripts I installed for him. Using
FP. I install open-source and free scripts, and directly say that you cannot
remove the copyright of the scripts if I'm going to install it for you. But
he (knowing no CGI, mind you) keeps trying to rip off the copyright of these
scripts and replace them with his name, through FrontPage no less.
Consequently, the scripts kept "mysteriously" changing ownership to nobody,
and of course then they wouldn't run (because scripts can't run as 'nobody'
on the machine). I kept changing them back. He kept breaking them. I knew
that FrontPage was the cause of it, but couldn't for the life of me figure
out *why* FrontPage was trying to take ownership of these folders/files.
Normally if FP finds something that it didn't publish (ie: something you've
uploaded by FTP), it leaves it alone. It will list it off in your Web Folder
window, but it won't "touch" the files.
I couldn't figure out what was actually happening until I finally got tired
of changing the ownership on these files 3 times a day for this guy and hid
everything from FrontPage by putting a dot (.) in front of the folder name.
I changed the script paths accordingly, and everything worked like a charm.
He immediately emailed me complaining that now he couldn't finish "updating"
the script pages and put his company's name and logo on them. Turns out
that's what kept breaking the ownership - he was accessing those folders and
files from his Web Folder window and trying to work on them with FP.
(Against my terms of service, I might add.)

Meanwhile, my FP sites with FTP'd scripts, and those of all of my other
clients (who aren't trying to alter the files with FP and remove the
copyrights) are still working just peachy keen. I've 'gently' reminded this
client that taking the copyright off of those scripts (whether by hand with
a text editor or using FP) is not allowed. I just received another email
this morning where he's freaking out because he wants the people that 'he'
(cough) made these sites for to think that HE made these scripts as well.
I'm still figuring out how to explain this to him in even plainer english
than I already have (and believe me, I use BASIC instructions and language
when communicating with this guy).

Another example:
I was installing a couple of scripts for a different client. He was - at the
same time - publishing a bunch of stuff to his site with FP. FP was leaving
the scripts and folders alone - UNTIL he used FP to go peek into the folders
and see how far along I was in installing stuff. Then they immediately
broke. I emailed him and told him to wait until I was finished installing
the scripts, then I would send him instructions on how to customize the
scripts using FTP (NOT FP). Problem solved. None of those scripts have ever
broken again, and he's got them looking exactly like his site. He simply did
it with FTP rather than FP.

So what I've learned from this is:
The age-old rule still applies. If you upload something with FTP, do *not*
touch it with FrontPage.
If you do, FrontPage will automatically take ownership of that folder/file.
If you just leave it sitting there in your FP Web window and don't actually
access it from within FP, things will be fine. It will retain the ownership
of the login you used to upload it. FP will still *see* it, but FP won't
*own* it (as nobody).
This is especially important with scripts that can't run as 'nobody'.
Of course, if you're moving a bunch of html files it's really no problem to
go ahead and access them from within FrontPage, they'll still work as
they're supposed to, even as 'nobody'.

I know this has been horribly long, but I really wanted to use examples to
illustrate what I meant, to make it clearer. FTP'd stuff and FP-created
stuff *can* live in harmony on the same website with no problems. You just
have to be very careful about what you access through the FP Web Folder
window. Once you actually tell FP to pull that file down, or open that
folder so you can look at it on your machine through the FrontPage program,
FP will take ownership of the file.
(And again, this is really only a problem with scripts that can't execute
when they're doing so as 'nobody'.)

Sure hope all of this blathering helped.  :)

Carrie Bartkowiak
Administrator, All @bout Choice
admin@xxxxxxxxxxxxxxxxxx
http://www.allaboutchoice.com