hasegawa-k
メンバー
2 years前の投稿 #
ktay styleをwordpress MU 2.8.1で利用させていただいております。
携帯で初めてアクセスした時生成される、画像サムネールの.ktaiがついたファイル（元画像が01.jpgの場合01.ktai.jpg）は昨日の私の環境の場合、下記ディレクトリに生成されます（元ファイルと同じ）
wp-content/blogs.dir/2/files/2009/09
このディレクトリ自体のオーナーがapacheとなっておりFTPでは削除が出来ません。
効率的にファイルを削除する方法はありますでしょうか？
※数十個削除したいファイルがあります
サーバーはxserver
FTPはmacでCyberduck、windowsではFFFTPでアクセスしています。
ファイルのパーミションは646
ディレクトリのパーミションはすべて755になっています
FTPでは変更・削除・移動もできません
サイトのスタート時は1記事に1から枚の写真を使う程度の内容だったため、shrinkage.phpを書き換えてサムネールのサイズを大きくしていたのですが、写真撮影会の内容を記載することとなり、サイズの設定を戻す前にアクセスしたところサムネールが生成されてしまい、携帯ではメモリーオーバーとなってしまっているようです。
一度生成されたサムネールは設定を戻した後も書きかわらないようで、削除してもう一度生成を、と考えています。
プラグインのフォーラムに質問することか迷いましたが、一番状況が伝わりやすいかと考えました。
PHP・UNIXコマンド等を操る知識はほとんどありませんm(_ _)m
よろしくお願いいたします。
う～ん、通常はファイルを一度ダウンロードしてきて再度アップロードすれば所有者が変わると思いますが、試してみてください。再アップロードして所有者が変更されれば削除も可能かと思います。
hasegawa-k
メンバー
2 years前の投稿 #
shokun0803さん早速ご助言ありがとうございます
ファイルを1つ選んで試してみました。
・FTPでダウンロード…出来ました（01.ktai.jpg）
・FTPでアップロード…変更日が書きかわっているので
アップロードできたと言うことでしょうか？
ちなみにこのディレクトリに他の画像ファイルをFTPでアップロードしようとしても
「Permission denied.」と表示されアップできません。
・アップロード後のファイルの情報を見ると、オーナー・グループ共にapacheのまま
パーミションは646です。
試しにパーミションを変更してみようと試みましたが
「CHMOD 644 01.ktai.jpg: Operation not permitted.」となります。
・ディレクトリ丸ごと、ダウン→アップで入れ替えは、入っているファイル数も沢山あり
怖くて今のところ試していませんが、試してみるべきでしょうか？
hasegawa-k
メンバー
2 years前の投稿 #
すいません！すいません！
xserverで借りている2つの別ドメインで運用しているwordpress MUで確認しましたら
j75さんのおっしゃるようにblogs.dirディレクトリ以下、ファイルも
全てオーナーは管理者でFTPから削除・変更等出来ました。
おかしいなぁと思い見直してみましたら、問題のサーバーは
「使えるネット」でした。誤った情報で質問してしまいホントにスイマセン。
このサーバー特有の症状の可能性もあり、早速サーバー側に問い合わせ、
あらためてここに報告します。
j75さんshokun0803さん返信ありがとうございます。
Ktai Style 側では、apache オーナーになる問題の回避のため、(セキュリティー的にいまいちなものの)、画像のパーミッションを other に対する書き込み権限を設定しています。
それが通ってないとすれば、chmod の問題か、親ディレクトリーに sticky bit が立っているとか、そんな感じかもしれません。
次期バージョンでは、プラグイン撤去時にサムネールを消す仕組みを入れようかと思っています。
hasegawa-k
メンバー
2 years前の投稿 #
作者様から直々に返信いただいて恐縮です。
素晴らしいプログラムとともに、さまざまなトピックでも本当に細やかに対応されているご姿勢は素晴らしい！と大袈裟でなく尊敬の念を抱いています。
PHP4だったいくつかのレンタルサーバーをKtai Styleを利用させていただくために乗り換えました(^^)
前述しましたようにレンタルサーバー会社に質問を送っております。
今回頂いた返信の内容も追加情報として送らせていただき、返答・解決次第ここに報告させていただきます。
ありがとうございます。
hasegawa-k
メンバー
2 years前の投稿 #
サーバー会社から返答をいただきました。
弊社ではワードプレスのプラグインなどのお問い合わせはサポート対象外となっておりますので、詳細なサポートが出来ませんことをご了承ください。
共有サーバでは権限の制限から、削除できないファイルが存在する場合がございます。
今回ですと、所有者がapacheになっておりますので、FTPユーザですと権限がありません。
お手数ではございますが、お客様より削除対象のファイルをお聞きし、弊社にて削除させていただく形となります。
恐れ入りますが、削除対象のファイルはどちらになりますでしょうか。
また、もしお客様の権限にて削除を行われたい場合は、
すべての権限をもてますVPSなどをご検討いただければと思います。
お手数ではございますが、対象のファイルの方、ご連絡ください。
「なぜここではオーナーがappacheになってしまうか？」といった根本的な部分は、サポート対象外ということで残念ながら触れていただけませんでした。
せめて、ここでアドバイスいただき、具体的に上げた可能性「chmod の問題」・「sticky bit」については返答いただけると良かったのですが…
「使えるネット共有サーバーの仕様」とするしかないのかも知れません。特殊な仕様ということなのでしょうか？
EC-CUBEを手軽に試せそう…ということで契約したサーバーで、ここに設定した「あまり難しいことをしないだろう」と予定していたWEBを急に活性化することになって、設定等の個性的な操作にやや戸惑い気味です。
蛇足ですが、私的にはよくネットで見かけるほど悪い印象は感じていませんが…
ファイルは指定すれば先方で削除をして頂けるということで指示をさせていただこうと思います。
画像ファイルのオーナーが apache になるのは、変えようがありません。これは他のサーバーでも同様です。
しかし、Ktai Style は、オーナー以外でも削除できるようにパーミッションを変更しています。そのパーミッション変更に失敗しているのだと思われます。
なぜ失敗するのかの調査は、単純に chmod だけ行う PHP プログラムを作ってサーバーで実行させてみるのが簡単でしょう。そういうことが可能ならば、試してみてください。
上位ディレクトリーが、オーナー (これもおそらく apache) 以外に実行権限がなければ、配下のフォルダーで chmod できないかもしれません。
親ディレクトリーに sticky bit が立っているのは、通常は考えられないので、おそらく大丈夫でしょう (sticky bit が立っているかどうかは ls するとか、FTP ソフトでディレクトリーの権限を見てみてください)。
hasegawa-k
メンバー
2 years前の投稿 #
lilyfan様たびたびありがとうございます。
パーミションの問題ですか…
FTPで確認しただけですが、sticky bitによる「t」はついてないようです。
646と表記されていますが、同じ646のXSERVERでは削除等出来るようです。
なぜ失敗するのかの調査は、単純に chmod だけ行う PHP プログラムを作って…
う〜んスイマセン、私の能力のはるか上のお話しになってそうです。
申し訳ないです。
そもそも知識のないなか、デフォルトから向こう見ずに画像サイズを操作し…アドバイスいただいても自分で手を出せない部分が多い…という状況には多々反省しています。
wordpressを使いこなすため、やはりもう少しPHP等、学ばなきゃ！と実感しました。
その上で今回いただいたアドバイスも試してみます。
※削除は早速実行していただきました。
j75
