More from: ファイル

解決!?(wordpress)

当ブログに画像をアップロードできない件が解決(?)した(ように見える)。
先の記事に書いたエラーメッセージでググって見つけたページ、

wordpress でメディアのアップロードができないときの対処

にいくつかの原因と対策が書かれていて、そこに書いてあったようにパーミッションを変更してもダメだった。
そこで、そのページからリンクしていた別のページ、

WordPress : Permissionがあっているのに画像をアップロード出来ない件 heteml

には、
「ディレクトリの位置が違ってるんじゃないか」
とあり、さらには
「このブログはかなり前のWordpress ver.2.xくらいから使っていることもあり、パスの位置がDBに保存されていたようだ。」
ともある。
当ブログも2008年に開設し、ずっとwordpressを使っているので当初のバージョンはかなり古く(たしか”2”時代)、アップデートを繰り返している。
そこで、上記サイトに書いてあるように設定ページの「メディア」の項目を見ると、同じように「アップロードするファイルの保存場所」が設定されていた。
一応、内容をコピーしておき、その後に内容を削除して”変更を保存”をクリックすると項目そのものが見えなくなった。
そうしてからファイルのアップロードを試してみると、今度はうまくいって画像を投稿に挿入することが出来るようになった。

そういえば当ブログを設置しているレンタルサーバーも最近になってサーバーを移行させると連絡が来ていて、数日前に移行完了の通知が来ていた。
その移行時にアップロード場所が変更になっていたのだろう。
いやぁ、ちょっと焦ったけど解決して良かった(汗)。
でも、サーバーのftpツールで見るとアップロードされたファイルが見え無いんだよなぁ・・・

←クリックしてくれると嬉しいです。

画像のアップロードが出来ない?(wordpress)

当ブログはwordpressを使っている。
今日になって画像をアップロードしようとすると

”Unable to create directory uploads/2023/03. Is its parent directory writable by the server?”

というエラーメッセージが表示されてアップロードできなくなってしまった。
これまでも時折アップロードできないことがあり、その際にはブラウザの再起動や新しいタブでメディアページを開く等すればアップロード出来た。
ところが今回はそれらを行なっても全く同じエラーが出てしまう。
メッセージの内容はパーミッションに関することなので、ディレクトリのパーミッションを見ると”755”で問題無いように見える。
これを”777”(危なっ!なので真似しないように)や反対に”705”に変更してみたが同じエラーになってしまう。
うーむ、パーミッションだけの問題では無いのかな?

←クリックしてくれると嬉しいです。

iCloudのフォルダへのファイルコピーがおさまった

昨日の記事「謎のファイルが増加・・・」に書いたように自宅のPCの下記のフォルダに写真データが大量にコピーされる現象が発生していた。
C:\Users\hoge\AppData\Local\Apple Inc\iCloudPhotoLibrary\Staging\Derivatives
ネットで解決策を探したところ、違うフォルダだけどiCloudの設定を変更すると解決した例を見つけた。
その情報によるとiOSデバイス(iPhone,iPad等)とWindows10PCの間での同期に異常があると何度もコピーが繰り返されるらしい。
なので、一度同期を解除し、再度同期設定をすることで解決したとのこと。
手順は簡単で、PCでiCloudの設定画面を表示し、同期する項目の内「写真」のチェックを外して「適用」ボタンを押し、PCを一度再起動した後に再度「写真」にチェックを入れれば良いとのこと。
実際にやってみると、「写真」のチェックを外した時点で上記フォルダにあったファイルが全て削除された。
そのまま再起動せずにチェックを入れ直してみるといくつかのファイルが復活したものの、その数は僅かで同じファイルが複数個コピーされることも無かった。
念のためにPCを再起動してみてもファイルのコピーはされなかったので解決したと考えて良さそうだな。

←クリックしてくれると嬉しいです。

謎のファイルが増加・・・

先だって自宅のPCのCドライブの容量が無くなったことを記事にした。
その時はハイバネーションの利用をオフにし、ハイバネーション用のファイル(C:\hiberfil.sys)が削除されたことで空き容量は増加した。
ところが、すぐ後になってまた30GBほど空きが減っていることが判った。
Cドライブにはデータは置かないようにしているのでなにかのソフトもしくはWindows10自身が勝手にファイルを増やしていることが考えられたので、どのフォルダに大量の(数十GBもの)ファイルがあるかを探してみたら下記のフォルダに大量に写真データがあった。
C:\Users\hoge\AppData\Local\Apple Inc\iCloudPhotoLibrary\Staging\Derivatives
このフォルダに個数にしておよそ12万個、容量にして30GB以上の写真のファイルがあった。
このフォルダの存在すら知らなかったので私が意識して写真のファイルを置いたわけではないのは明白。
しかもファイルの中身を見ると4年前に青森や岩手・秋田の各県で撮ってきた列車の写真や釧路駅で撮った気動車の写真、さらにiPad mini2や最近買ったiPhone7の壁紙に使っている画像ファイルでどれもiPad mini2かiPhone7にコピーしたファイル。
これらがそれぞれ8千個ほどコピーされてこのフォルダに置かれていた。
仕方が無いので各写真や画像のファイルをそれぞれ一つだけ残して削除してみたが、削除するそばからコピーされてしまってなかなか減らない。
フォルダ名からappleのiCloud関連のフォルダと思われるのでタスクマネージャからiCloud関連のタスクを止めるとファイルのコピーもされなくなった。
うん、やっぱりiCloudが悪さをしていたようだ(汗)。
しかしPCを再起動すると止めたタスクも動き始めてまたフォルダ内に無駄に写真ファイルのコピーをし始めてしまう・・・
ならばiCloudをアンインストールすれば良いのだろうけど、困ったことにiOS機器とのファイルの同期をとるためにiCloudはそのまま使いたい。
なんとかならないかとフォルダ名でググってみたら同じようなことで困っている人がいて、その人が解決した方法が出ていたがよく見ると対象のフォルダ名(C:\Users\Owner\AppData\Local\Apple Inc\CloudKit\iCloud Photos\MMCS)が違うorz。
取り敢えず参考にして試してみて、上手くいったらラッキーだな(汗)。

←クリックしてくれると嬉しいです。

”2日以上”って・・・

PCのHDD間で大量のファイルを移動させる必要が生じた。
10万個以上のファイルを一気に選択して移動先のフォルダに移動させようとしたらPCが固まったように動かなくなった(汗)。
タスクマネージャーで見るとCPU負荷は殆ど無いんだけど、システムドライブの負荷が100%に貼り付いている。
さらにはそのタスクマネージャーの表示も固まってしまいマウスポインタすらまともに動かなくなって強制的に再起動させることも考えたが、10分ほどでまた操作を受け付けるようになった。
ほどなくしてファイルの移動が始まったけど、移動の準備にも時間がかかり、実際に移動処理が始まってから表示された残り時間が”2日以上”。
いや、そこまで待つ気は無いからね(笑)。
#実際には2-3時間程度で終わる見込み(汗)。

←クリックしてくれると嬉しいです。

ファイルを消してしまっていた(汗)

先だって自宅のPCを触っていたところ、通知エリアになにやら表示された。
見るとあるファイルを削除したとの通知。
あれ?消した覚えは無いんだけどな?と思ってフォルダを見ると確かに無くなっている。
しかも消えたのがこのブログのアクセス数を2009/12から記録したファイル(汗)。
明示的に消すはずのないファイルなので間違って消したのだろうけど、気付いた時にはかなり焦った。
たまたま保存していたのがDropBOXの共有フォルダだったので、WEBインターフェースから入って”復元”ですんなり生き返った。
いや、DropBOXに入れておいて良かったよ(汗)

←クリックしてくれると嬉しいです。

SWAP

SWATじゃ無くてLinux(に限らずUNIX系OS全般)におけるSWAP(ファイルシステムorファイル)のこと。
職場のLinuxサーバがとにかく重いのでコンソールを見てみるとメモリ不足でプロセスが殺されている。
先週末までは特に問題なく動いていたが、なにかが変わったのか?
とにかくメモリが足りないのは確かなようなので、なにか対策が必要。
とは言ってもサーバを停止させられないので、SWAPエリアを拡張することにした。
HDDには余っているパーティションは無いので、SWAPパーティションを拡張することはできない。
そこでSWAPファイルを作成して追加することにした。
やりかたを忘れるといけないので、ここにメモとして残しておこう。

空きのあるパーティションに判りやすい名前で”0(ゼロ)”で埋めたファイルを”dd”コマンドで作成する。
#dd if=/dev/zero of=ファイル名 bs=1024 count=BLOCK数(BLOCKサイズを1024にし、ファイルサイズを1GiBにしたい場合は”1048576″(1024X1024)と指定する)
このファイルをSWAPファイルとして初期化する。
#mkswap “上で指定したファイル名”
ファイルをSWAP領域として有効にする。
#swapon “上で指定したファイル名”
その後/etc/fstabに追加したファイルの記述を追加する。

#上の手順はLinuxのそれだが、基本的な方法はSunOSでも同じだった記憶がある。

これでなんとかメモリ不足を回避できたが、なぜ不足(しかもかなりの規模で)するようになったかは不明。
どっちにしても実メモリも(今となっては)少ないので、機会を見て増設することにしよう。

←クリックしてくれると嬉しいです。