ご意見／ご要望／ご質問

[Kengo Sawatsu]

ご意見／ご要望／ご質問に関してはこちらのトピックへの返信でお知らせください。

[netm...@pce.co.jp]

LTOからのファイル呼び出しについて

お世話になります。山崎です。

LTOからファイルを呼び出す場合、「コピー元」をクリックしてオープンダイアログからLTOを指定しているのですが

やはりLTOのシークが発生してしまい、数分間 待たなくてはならなくなります。

シークを発生させないでファイル指定を行える方法はありますでしょうか。

[Kengo Sawatsu]

こんにちは、RapidCopy開発者の澤津です。

ご質問の件ですが、残念ながらオープンダイアログからアクセスする場合にはLTOシークを回避する手段はありません。

(OSX標準ダイアログが内部でファイルアクセスしてしまうため、RapidCopy側で制御できないのです)

なお、余談になりますがRapidCopyProをご利用の場合は、コピー元のパスを直接入力することができるので、

選択時のLTOシークは回避することができます。

ターミナルを上げてcdなどで目的のフォルダまで移動、目的のファイルパス名をpwdコマンドなどで取得して

コピー元パスに直接コピペする感じですね。

2016年2月19日金曜日 14時49分13秒 UTC+9 netm...@pce.co.jp:

[yamat...@gmail.com]

澤津様
ご回答ありがとうございます。
やはりそうですよね。
Proは、予算は取ってあるのですが、4月にならないと購入出来ないのでちょっと待ちますが
下記の手順で実現出来るという事ですね。

1）RapidListでLTOのファイル一覧を取得
2）呼び出したいファイルのパスをコピー
3）RapidCopyProの「コピー元」にペースト
4）「実行」
5）ウマ〜

[Kengo Sawatsu]

RapidCopy作者の澤津です。

はい、ご提示のやり方で出来ると思います。

私はターミナルで操作することを前提に考えていましたが、

こういうときにRapidListのフルパス出力が役に立ちますね。

(作者的には今回のようなケースでの活用を想定していませんでした)

2016年2月21日日曜日 23時32分35秒 UTC+9 yamat...@gmail.com:

[やまたけ]

深津様

いっそ、RapidCopyProの機能として

インデックスパーテションからのファイル一覧取得機能を付けたり・・・・。

（シーク回避として）

[rk]

突然の書き込み失礼します。

これまで複数の媒体すなわちUSBフラッシュメモリやUSB外付けHDD（ext4, Fat32, NTFS)のバックアップとしてrsyncを主に使用してバックアップをとってきたのですが、

どうもファイル名によってバッアップが取れないケースがあるようです。

本製品ではMicrosoft/ WindowsOSによって命名された長くて比較的特殊な文字やスペースを含む大容量（1ファイル2Gを超える）ファイルも上手に差分コピーが可能なのでしょうか。

2015年7月15日水曜日 18時44分27秒 UTC+9 Kengo Sawatsu:

ご意見／ご要望／ご質問に関してはこちらのトピックへの返信でお知らせください。

[sawatsu...@gmail.com]

ご質問ありがとうございます、RapidCopy作者の澤津です。

ご質問の件ですが、ご懸念の問題点ごとに分けてお答えします。
簡単に言えば「ファイルシステム次第なので、一概に大丈夫とは言えません」が結論になります。

＜Microsoft/ WindowsOSによって命名された長くて
WindowsのLong File Nameについては、255文字以内のいわゆる「ロングファイルネーム」範囲内であれば問題はないと思います。
255文字を超える特殊なファイルについては確認を取れていませんが、受け入れ先のファイルシステムがHFS+の場合にはエラーになる可能性は高いと思います。
(HFS+ではファイル名は最大で255文字までと決まっているため)

＜比較的特殊な文字やスペース
文字コードに関しては、バックアップ先のファイルシステムがどのように変換、保存するかに依存するため一概にどうとは言えないのが現状です。
近年のOS同士であれば基本的にはUnicodeでやり取りを行っているはずなので、Unicode範囲内であれば問題は起きないと思いますが、。
RapidCopyの問題というよりも、OSのファイルシステムがどのように文字を受け入れるかの問題ですね。

＜大容量ファイル(1ファイル2Gを超える)
RapidCopyでは基本的に問題は起きないと思います。

いずれの場合でも言える事なのですが、ファイル名の問題に関しては基本的にはファイルシステムの問題です。
ファイルシステム間で受け入れ可能でないファイル名であれば、リネームしない限りはどんなソフトを使ってもエラーになります。


2016年5月7日土曜日 2時43分54秒 UTC+9 rk:

[rka...@gmail.com]

ご丁寧な回答ありがとうございます。

本ソフトがデータを一時的にでも、なにか特殊なファイル形式（特殊なバイナリアーカイブみたいなもの）にするのか、

それともバックアップ先のファイルシステムに即した形で動くのかよくわかっていませんでしたので、

質問したほうが早いかとおもって書き込ませていただきましたところ、

かゆい所に手が届く情報提供をいただきまして大変感謝しております。

購入を検討したく存じます。

[arumajiro...@gmail.com]

はじめまして、先日Mac用RapidCopyのAppStore版を購入させていただきました。

こちらを使ってMacに外付けしていたHDDから大量のデータをNASへと移動させておりました所、途中でNASに突然アクセスできなくなってしまいました。

こういうコピー支援ツールを使うことで、上記のような問題が発生する可能性というのはあるのでしょうか？

（暑かったため、NAS自体の温度が上がり、このような現象につながったのではと考えていますが、上記したようなリスクが有るのであれば今後の使用を控えようと思い、質問させていただきました。）

お忙しいところ申し訳ありませんが、お返事をいただければ幸いです。

[sawatsu...@gmail.com]

ご質問ありがとうございます、RapidCopy作者の澤津です。

＜こちらを使ってMacに外付けしていたHDDから大量のデータをNASへと移動させておりました所、途中でNASに突然アクセスできなくなってしまいました。

＜こういうコピー支援ツールを使うことで、上記のような問題が発生する可能性というのはあるのでしょうか？

RapidCopyのせいで特別な問題が起きるという事は考えにくいです。

ありえるとすれば、FinderコピーとI/Oアクセスパターンが異なるため、NASに負荷がかかりすぎて通信がリセットされたとかではないでしょうか？

発生したエラー内容とRapidCopyに表示されたメッセージを書いて頂けると、NASとの通信の問題かどうかはわかると思いますが。。

通信負荷でNASとの接続が切れてしまうようであれば、速度コントロール機能を利用して、わざとゆっくり書き込んでみるといいかもしれません。

書き込めるだけ連続で書き込むのではなく、送信をわざとゆっくり行うようになるのでNAS側の処理負担が減ります。

参考にしてみてください。

2016年7月7日木曜日 17時36分12秒 UTC+9 arumajiro...@gmail.com:

[arumajiro...@gmail.com]

お返事ありがとうございます。

幸いNASの方も復旧しましたので、RapidCopyを使いつつ、様子を見てみたいと思います。

調べてみると、利用しているプロバイダーでも障害が発生していたようですので、そのせいかもしれません。

[dozo...@gmail.com]

Macの再インストールのため、Ver1.1.1のアップグレードの入手を教えてください。

[takashi...@tandbergdata.com]

ltfsquiktoolよりformat、mountを実行すると圧縮についてはDefaultの有効になっていると思いますが私の理解で間違いないでしょうか？

また、非圧縮でのformatはltfsquiktoolからは行なえないと言う理解で間違っていないでしょうか？

お手数をお掛けしますがご教授のほどよろしくお願いします。

[sawatsu...@gmail.com]

こんにちは、レスパスビジョン澤津です。

ご質問の件、回答します。

>ltfsquiktoolよりformat、mountを実行すると圧縮についてはDefaultの有効になっていると思いますが私の理解で間違いないでしょうか？

はい、間違いありません。

LTFS Quick Toolsではフォーマット時の圧縮については「必ず有効」にしています。

＜また、非圧縮でのformatはltfsquiktoolからは行なえないと言う理解で間違っていないでしょうか？

間違っていません。今の所は非圧縮フォーマットはできないです。

圧縮を無効にするメリットが今の所無いので、わかりやすさ優先で「有効」としています。

「無効」にしないと困るようなシチュエーションがあるようであれば、

逆にご説明頂けると開発の参考になるので教えてください。

#公開掲示板に書きづらいようでしたら、saw...@lespace.co.jpまでご連絡ください。

2016年12月5日月曜日 10時09分59秒 UTC+9 takashi...@tandbergdata.com:

[takashi...@tandbergdata.com]

レスパスビジョン　沢津様、

ご回答ありがとうございます。

タンベルグデータ　小田切でございます。

お使いのお客様に質問を受けまして、ご質問させていただきました次第です。

私は特に圧縮を無効にするメリットは感じられませんが、

通常非圧縮で使っているお客様もおりました。

別のMac用のツールで非圧縮でしかフォーマット出来ないものもありますが、

理由はよくわかりません。

ご教授ありがとうございました。

2016年12月5日月曜日 12時48分37秒 UTC+9 sawatsu...@gmail.com:

[new.engla...@gmail.com]

こんにちは。

質問があります。

バックアップするフォルダは決まっているので、都度D&Dするのではなく

何かメモリボタン？みたいなものを押せば前回と同じ内容で作業が再開される…

というのは出来ますか？

今までは Sync3LEを使用していたのですが、久々に使用したところ

ファイル数が増えた？　ファイルサイズが大きいため？かエラーを起こしてしまい…

RapidCopyが爆速？なのは素晴らしいのですが。

[Kengo Sawatsu]

こんにちは、作者の澤津です。

ご質問の件ですが、AppStore版RapidCopyへの質問として回答します。

＜バックアップするフォルダは決まっているので、都度D&Dするのではなく

残念ながらAppStore版RapidCopyでは実現できません。
これはAppStoreのサンドボックス制約によるもので、RapidCopyの仕様です。


弊社から直接販売しているPro版(RapidCopyPro)では既に実装されている機能となるので、
ご希望であれば弊社からRapidCopyProを含むコピースイーツ、RapidCopySuiteをお買い上げ頂ければと思います。


Pro版との違いについて、概要は以下を参照してください。
http://www.lespace.co.jp/file_bl/rapidcopy/rcpro.html

履歴機能から呼び出す機能などについての詳細な仕様はテクニカルマニュアルを参照してください。
http://www.lespace.co.jp/file_bl/rapidcopy/manual/index.html

申し込みのページはこちらです。
https://docs.google.com/forms/d/1GLPnFRMCvaMhNT5YQYTEAYWjCjjkuRdZaYZlqkFk1xw/edit#

以上、よろしくお願いします。

2017年8月26日土曜日 12時40分08秒 UTC+9 new.engla...@gmail.com:

[t.yam...@pce.co.jp]

お世話になります。

RapidPackについて質問させてください。

シンボリックリンクを作り、それぞれをバックアップするのですが

バックアップ後に、このシンボリックリンクファイルはゴミ箱に入れて削除して大丈夫なものでしょうか。

ちょっと小心者なもんで。

[Kengo Sawatsu]

こんにちは、澤津です。

＜シンボリックリンクを作り、それぞれをバックアップするのですが

＜バックアップ後に、このシンボリックリンクファイルはゴミ箱に入れて削除して大丈夫なものでしょうか。

＜ちょっと小心者なもんで。

OSの標準機能(エクスプローラ、Finder)で削除する限りは大丈夫ですよ。

また、FastCopy,RapidCopyの削除機能においては、ご心配の問題が起きないように設計されています。

(deleteモードにおいてはシンボリックリンク「先」をデリートできないような仕様になっています、事故ってしまうので)

ちなみにMacのrm -rf コマンドはシンボリックリンク「自体」を削除するだけのようですが、

https://developer.apple.com/legacy/library/documentation/Darwin/Reference/ManPages/man1/rm.1.html

The rm utility removes symbolic links, not the files referenced by the links.

Linuxのrm -rf　コマンドはシンボリックリンク「先」を削除しちゃうようです、。危ないデスネ。。。

http://mitsuakikawamorita.com/blog/?p=758

2018年2月7日水曜日 20時23分04秒 UTC+9 t.yam...@pce.co.jp:

[t.yam...@pce.co.jp]

深津様　ご回答ありがとうございます。安心して（？）削除致します。

[t.yam...@pce.co.jp]

深津様　うちの業務的に素材ではなく番組の完パケをアーカイブする事が多く、その際はエピソードが複数のLTOにまたがらない方が使い勝手が良いです。今の仕様だとエピソードが分割（例えばLTO-1にはEp5まで、LTO−2はEp6から）されるのですが、ファイルがある最後のフォルダは分割されないように制御できるものでしょうか？この場合、多少の隙間（容量）が空くのは構わないのですが。（将来的な希望）

[iwao.hashi...@gmail.com]

RapidCopyでの「同期（サイズ・日付）」はLTFSでは利用できないようになっていますが、これは、テープがシーケンシャルデバイスで追記しかできないため、差分コピーなどで事足りるから（ディスクにおける領域上書きなどはそもそもできないから）という理由になりますでしょうか。

弊社のテストで、コピー元HDDにファイルA、B、Cを作成し、その３ファイルをLTFSにチェックをいれてLTFSボリュームにコピーした後、

HDD側で

Aはそのまま

Bは内容を編集

Cは削除

をしました。

この状態で再度差分コピーを実行すると、Bのみがコピーされ、Cはテープに残ったままになります。

試しにLTFSのチェックを外して「同期」を実行してみると、

テープ側でもCが削除されましたが、A、Bともに、権限無しのエラーとなりました。

（LTFSでは削除は出来るが、「同期」はできないためと推察しています）

弊社のお客様で、HDD側に数万単位のファイルがあり、RapidCopyでLTFSへのコピーを評価しているお客様がいらっしゃるのですが、

HDD側で編集作業を行った際に、紛らわしい似たような名前の不要ファイルが複数発生するため、差分コピーを実施する際に、それらをテープ側からも削除したいというご要望がありました。

差分コピーで編集分と追記分をテープにコピーした後、「同期」で不要ファイルを削除しようとすると、不要ファイル以外の数万のファイル数だけ「権限無し」エラーが発生すると考えられるため、これはお勧めできません。

LTFSにおいて「同期」の概念はなじまないものだとは思いますが、

削除だけであれば、メニューにあって問題無いように思えますので、

もし可能であれば、LTFSにチェックをつけた状態であっても、「削除（不存在ファイル）」といったメニューを加えていただき、

「コピー元に存在しないファイル名のファイルをコピー先から削除する」機能を今後のバージョンアップで追加していただけないか、

ご検討いただければ幸いです。

[Kengo Sawatsu]

こんにちは、澤津です。

（よく間違えられるので慣れっこですが、フカツじゃないです（笑））

なるほど、人間にとっての「ちょうどよい」データ分割点を指定するイメージですね。

技術的には「Pack対象にしないフォルダ指定」の機能の延長で、できなくはなさそうです。

Packに関しては実装的にちょっと心残りな部分があるので、そちらの改修のタイミングで検討してみます。

2018年2月19日月曜日 18時25分36秒 UTC+9 t.yam...@pce.co.jp:

[Kengo Sawatsu]

こんにちは、作者の澤津です。

＜RapidCopyでの「同期（サイズ・日付）」はLTFSでは利用できないようになっていますが、これは、テープがシーケンシャルデバイスで追記しかできないため、

＜差分コピーなどで事足りるから（ディスクにおける領域上書きなどはそもそもできないから）という理由になりますでしょうか。

はい、そのような理解で正しいです。

＜HDD側で編集作業を行った際に、紛らわしい似たような名前の不要ファイルが複数発生するため、差分コピーを実施する際に、それらをテープ側からも削除したいというご要望がありました。

ご要望のようなシナリオは開発時点で私も想像しておりLTFSに対しての「同期」にニーズがあることは理解しているつもりです。

しかし、以下の観点から「差分」の機能についてはLTFSに対しては「あえて」仕様から外しています。

1. LTFSにおいては「ファイル削除」による書き込み可能領域の回復が出来ないため、

　同期時のファイル削除量によってはユーザから見た追加の書き込み可能領域と著しい差が発生するが、

　巨大な削除を頻繁に発生させると、ユーザにとっての残り使用可能領域の誤認を拡大させる可能性がある。

2. LTFSモードは「アーカイブ」のためのモードであり、当該の「わずらわしい」ファイルの選定はあくまで

　ユーザが事前に選別するべきであるとの考えであり、RapidCopy側で「削除」を決定付けるべきではない。

当該「同期」のコードをご希望の通りに修正することは技術的には恐らく可能ですが、

事故防止の観点、LTFSモードの「アーカイブ」に対する私の考え方から、

今のところご希望の機能を実装することはお断りさせて頂きたいと思います。

以上、よろしくお願い致します。

2018年2月22日木曜日 17時09分38秒 UTC+9 iwao.hashi...@gmail.com:

[t.yam...@pce.co.jp]

澤津様 大変失礼いたしました。（名刺交換までしているのに・・・）

RapidPackの話ですが

> なるほど、人間にとっての「ちょうどよい」データ分割点を指定するイメージですね。

> 技術的には「Pack対象にしないフォルダ指定」の機能の延長で、できなくはなさそうです。

> Packに関しては実装的にちょっと心残りな部分があるので、そちらの改修のタイミングで検討してみます。

番組を圧縮データ（ProResやCanopus）でアーカイブするとLTO1つに複数番組を取る事になりますが

呼び出す時はLTO全てというシチュエーションが殆ど無く、その中の番組1つ（あるいは複数）を呼び出す事がほとんどです。

その場合で考えますと番組データが複数LTOに分かれていると混乱しちゃうんですね。

また、たまにですが修正版が発生した場合に、（追記でも）なるべく同じLTOに入れておきたいので

100〜200GB空けた状態でアーカイブしています。

いづれにしましても、検討頂けるとのことで大変楽しみにしております。

山崎

[iwao.hashi...@gmail.com]

澤津様

早速のご確認、丁寧なご説明誠に有難うございました。

下記承知いたしました。

タンベルグデータ

橋場

2018年2月25日日曜日 11時38分45秒 UTC+9 Kengo Sawatsu:

[okamoto]

お世話になります。

RapidTreeProについて質問させていただきます。

RapidTreeProをコマンドラインから引数指定で実行する方法はありますでしょうか。

複数のLTOに対し順次ツリー情報を取得したいと考えております。

国立映画アーカイブ　岡本

[Kengo Sawatsu]

作者の澤津です。

RapidTreeProですが、残念ながらwin/mac共にコマンドライン実行する方法は提供していません。

以上、よろしくお願いします。

2019年1月5日土曜日 17時16分44秒 UTC+9 okamoto:

[crista...@gmail.com]

澤津様

お世話になっております。岡本です。

承知いたしました。ご回答ありがとうございました。

岡本

2019年1月7日月曜日 11時58分17秒 UTC+9 Kengo Sawatsu:

[knbp...@midori.gmobb.jp]

お世話になっております。

MacOS 10.14.3更新後からだと思われますが、

・UIの日本語文字部分だけ細字になっている

・フォルダパス表示部分において、濁点・半濁点の文字の位置がずれて表示される

が発生しています。全体的に、日本語文字だけ本来と違うフォントが適用されている感じです。

ちなみに、現在私の環境のヒラギノ角ゴシック系のインストール状況ですが、

ヒラギノ角ゴStdN W8と、ヒラギノ角ゴシック W0〜W9がインストールされております。

[insid...@gmail.com]

google検索で上から２つめに表示される個人ブログ。
https://www.note.lespace.co.jp/n/n50b26ef76f88
中身は個人が思ったことを叫んでいるだけ。exFATは悪いものだ！と。
根拠もソースもないんですよ。
アップルやバッファローを悪者にしています。
ハックしてexFATぽいものだから壊れる！と。
でも、特許のマイクロソフトから各社ライセンスを受けて提供しているんです。

ソース
https://japan.cnet.com/article/20405168/
１０年以上前の記事です。

各社風評被害を受けています。
こういう嘘デタラメブログを世に発信する企業に信用はありません。さようなら。

[y t]

お世話になっております。

突然の書き込みで申し訳ありません。

Rapic Copyを使用したLTOへの書き込みについてご相談させてください。

LTO7へ5TBほどのデータを記録しようとしているのですが、エラーが出て進みません。

ログによると、エラーの原因になるファイルは毎回違います。

エラーは下記のとおりです。

Meke Digest Async: Read File With Reduce [errorno5 I/Oエラーが発生しました。

デバイスまたはファイルシステムが正常か確認してください。

ハードかソフト、どちらを原因と考えるべきでしょうか。

また、対処方法などあれば伺いたいです。

よろしくお願い致します。

田中

2015年7月15日水曜日 18:44:27 UTC+9 Kengo Sawatsu:

ご意見／ご要望／ご質問に関してはこちらのトピックへの返信でお知らせください。

[Kengo Sawatsu]

開発者の澤津です。

詳細はログを見ないとなんともいえませんが、ランダムに発生するような場合は大概の場合は

ファイルシステムの問題であることが多いです。

LTOへの書き込みとのことですが、コピー元のファイルシステムはなんでしょうか？

よくあるパターンは

exFATの問題（ベリファイなどで謎のエラーが発生する）

HFS+（フォーマットし直すと直る）

といったところでしょうか。

詳細な調査をご希望の場合は、詳細ログを取得して

saw...@lespace.co.jp　まで送付していただければ、できる範囲で回答させていただきます。

https://app.lespace.co.jp/file_bl/rapidcopy/manual/index.html#log

2020年10月23日金曜日 11:55:18 UTC+9 y t:

[y t]

澤津さま

お世話になります。

ご返信ありがとうございました。

コピー元のファイルシステムは、Macジャーナリングです。

同じHDDのなかに複数フォルダーがあり、エラーを出すフォルダー以外のLTO書き込みは問題なくできました。

なので、まずは当該のフォルダーをもう一度HDDにコピーし直し、再度TOに書き込んでみます。

以上、よろしくお願い致します。

y t

2020年10月25日日曜日 13:45:17 UTC+9 Kengo Sawatsu: