Xbit being reset at remote save

[Andrew Willett]

Greetings all. I've got an odd thing happening and I was hoping
somebody might have some insights on tracking down the cause.

Permissions on HTML documents on my webserver are kept at 744 (rwxr--
r--). However, I find that whenever I use BBEdit to make changes to
these documents remotely, the permissions are suddenly reset to 644
(rw-r--r--). I then have to use the 'get info' button on BBEdit's FTP
browser (or some other method, like the 'get info' function on
Transmit, my FTP client of choice) to put the file permissions back
when I need them.

This is a new problem: I've only noticed it within the last month or
two. I'm using BBEdit 8.7.2 and Mac OS X 10.5.4. Any thoughts?
Throwing out the BBEdit Prefs Data file doesn't seem to make a
difference -- anything else I might try? Is anybody else experiencing
this?

Many thanks.

[Doug McNutt]

At 22:47 -0700 8/13/08, Andrew Willett wrote:
>Permissions on HTML documents on my webserver are kept at 744 (rwxr--
>r--). However, I find that whenever I use BBEdit to make changes to
>these documents remotely, the permissions are suddenly reset to 644
>(rw-r--r--). I then have to use the 'get info' button on BBEdit's FTP
>browser (or some other method, like the 'get info' function on
>Transmit, my FTP client of choice) to put the file permissions back
>when I need them.
>
>This is a new problem: I've only noticed it within the last month or
>two. I'm using BBEdit 8.7.2 and Mac OS X 10.5.4. Any thoughts?
>Throwing out the BBEdit Prefs Data file doesn't seem to make a
>difference -- anything else I might try? Is anybody else experiencing
>this?

I thought I'd never say it but why in the world would you want execute permission on an HTML file? Is your host using Microsoft software?

In any case I'd bet that your web host has done something to get rind of the x rather than something BBEdit might do. If you have a shell account on your web host you should check your setting for "umask".. Try that command in a bbedit worksheet to see what it's all about. FTP on the host might be executing an "rc" file associated with your username.

--

--> From the U S of A, the only socialist country that refuses to admit it. <--

[face]

> I thought I'd never say it but why in the world would you want execute permission on an HTML file? Is your host using Microsoft software?

Handy little thing to make a web page a "bit" more dynamic

http://httpd.apache.org/docs/1.3/mod/mod_include.html

The XBitHack directives controls the parsing of ordinary html
documents. This directive only affects files associated with the MIME
type text/html. XBitHack can take on the following values:

off
No special treatment of executable files.
on
Any file that has the user-execute bit set will be treated as a
server-parsed html document.
full
As for on but also test the group-execute bit. If it is set, then
set the Last-modified date of the returned file to be the last
modified time of the file. If it is not set, then no last-modified
date is sent. Setting this bit allows clients and proxies to cache the
result of the request.

Note: you would not want to use this, for example, when you
#include a CGI that produces different output on each hit (or
potentially depends on the hit).

[Andrew Willett]

No, it's a Linux server. The execute permission lets me use server-
side includes without the .shtml extension, which is a trick I've been
using forever (google XBitHack for details). In researching this
issue, though, I've found that there's a more efficient way to deal
with it, via the .htaccess file. So this issue becomes moot.

BUT I did talk with my web hosts* while trying to figure things out,
and they explained what was going on in a way that suggests a possible
update to BBEdit. They said that they'd recently upgraded their FTP
servers to use "atomic file replacement" -- so that, when given the
command to replace a file, rather than blanking out a file's contents
and then updating it with the new incoming text, their servers now
create the new file under a temporary name, delete the old one, and
then rename the temp. Because the default permissions for a new file
is 644, that's what the replacement file ends up with -- no matter
what it had before. BBEdit, quite reasonably, doesn't anticipate any
change in permissions, and does nothing to make sure that the new file
maintains it.

Maybe in a future update, BBEdit could automatically follow up the
save process with a CHMOD command, just to be sure that the
permissions after the save are the same as they were before it? (My
hosts patched their server so that permissions are preserved in an
"atomic" update, but others may not be so conscientious.)


*The truly excellent TigerTech.net