pctine wrote:
這個問題我反應給 synology...(恕刪)
P大息怒...
其實跟使用者要log並沒有錯
如果log剛好有記載到錯誤訊息, 很快就能發現問題的原因
廠商輕鬆, 使用者的問題也能比較快被解決
比較有問題的是樓主一開始詢問客服的回答, "這是系統限制無法改善"
但後來證實在有些機種上是可以正常運作的
顯然對方沒有去查證, 而是隨便掰個答案就想敷衍過去
betoptic wrote:
P大息怒...
其實跟使用者要log並沒有錯
..(恕刪)
小弟只是對於昨日將相關問題反應給客服後, 所得到產品部門的制式回覆感到生氣而已.
如果看完整個討論串就曉得,
*User 早已將問題反應給原廠, 但並沒有得到滿意的答案.
*在 1F 時, 網友所提的問題並沒有寫清楚機型等相關資訊, 但這只是貼在版上, 在和客服對應上相信所提供的資訊更多.
*2F:前面已提到希望樓主提供更完整的機型及使用版本資訊.
*2F:自己也在 DS415+ DSM 6.0 上測試, 並未發現此問題.
*15F: 樓主提供完整的測試資料及擷圖, 證明有問題.
*20F: 又再次以 DS415+ 實測, 證明該機型 ok, 但以 DS213j 測試能重製該問題.
*29F: HOPE000 網友以另一機型 RS814+ RP 測試也能重製問題.
*32F: 以 RS814+ 同等級機型 DS1513+ 測試為 ok.
昨日 email 客服及相關連結, 尋求協助, 結果如你所言, 產品部門回覆 ds415+ 的狀況才是正常, 在 ds213j & ds215j 理論上不應該出現此問題. 希望能提供 log 供研究.
但如果有三位 user 能夠這麼容易就重製問題, 請問為何產品部門不自己先試過? 而是第一時間就只想到跟 user 要 log? 光是這個討論串就提供了多少資訊給原廠了? 如果產品部門無法重製問題, 再來索取 log 檔也說的過去啊.
FB: Pctine
pctine wrote:
小弟只是對於昨日將...(恕刪)
看來S家客服處理方式及積極度很不一
前幾天回報 DSM 6.0 Open Switch 問題也是說明一下他們就能理解問題並重製
停用 Open vSwitch 透過 CIFS 傳檔至 DS415+ Share Folder流量偵測正常
啟用 Open vSwitch (802.3ad (平衡TCP)) 透過 CIFS 傳檔至 DS415+ Share Folder流量偵測為0
啟用 Open vSwitch (802.3ad (平衡SLB)) 透過 CIFS 傳檔至 DS415+ Share Folder流量偵測為實際的兩倍
但回報Cloud Station問題時發現是DSM與AD連線SYNC速度問題
客服只回我他不負責這塊要我自己重填技術回報卻不願直接轉單給相關人員
System Engineer
Gregarious wrote:
的確 這個我沒有注...(恕刪)
HI Gregarious~
解答了OwnCloud rename的問題後,
忘了請教您另一個問題~<<搬移>>
將A資料夾內的數百M照片搬到B資料夾時,
Owncloud 是如何運作的呢?
會一樣跟rename一樣快速嗎?
小弟的問題為:
請問在桌機上使用Cloud station Drive 與 NAS Cloud Station 進行同步時,
遇到以下兩種情形
1在桌機的同步資料夾內,將A資料夾(內有500G照片)更名為B資料夾.-->只要1秒鐘
-->NAS的動作卻是刪除A資料夾內的500G照片,再另建B資料夾新增500G照片-->浪費了好幾個小時
2在桌機的同步資料夾內,將A資料夾內的500G照片搬移到B資料夾.-->只要1秒鐘
-->NAS的動作一樣是刪除A資料夾內的500G照片,再另建B資料夾新增500G照片-->浪費了好幾個小時
請問有解決方案嗎?
還是NAS的同步規則就是如此呢?
工程師的回答簡約如下:
Rename有兩種情形:
1.如果電腦端有正確識別出rename的狀況，那伺服端的日誌應該只會出現"重新命名"一個event，
(他們用DS213J跟DS1511+有做出第1種正確的結果.)
2.如果電腦端上的檔案事件發生不預期的順序或其它情況，軟體的確可能會產生出 <刪除 + 新增的事件>。
(But,實際運作上，伺服器端在刪除檔案時，會先將檔案搬進暫存目錄，當被刪除的events被重新觸發上傳時，實際上檔案並不會重傳，因為當伺服器端NAS在新增檔案時hash到相同的檔案時,就會直接從暫存目錄搬出來使用，所以並不會有重新上傳寫入的狀況。)
所以就算只是搬移，N個檔案就需要n個events做處理,
處理時間會與檔案數量有關，但與檔案大小無關。
現在有問題的是為何重新命名含有N個檔案的目錄時，本應只有一個目錄的重新命名event，
為什麼會變成重新命名N個檔案的動作.
他們會繼續重製這個問題,一有消息會立刻通知我.
也請我提供我的log日誌供他們參考,為何我的檔案處理方式不是第1種情形?
結論,
我的解讀如下
1 我的rename確實有問題,他們會再努力找出問題所在.
2 搬運檔案時,n個檔案就需要n個events-->這點我很不能認同!(我先不管到底是<重新上傳>或<處理事件>,反正都是要花時間,)
那1000張照片就需要處理1000個events,如果1個event花1秒處理-->那1000張照片就要1000秒(16分鐘),
明明在電腦上從A資料夾拉到B資料夾只需要不用1秒鐘的處理時間,你跟我說要16分鐘讓nas慢慢跑@@
陳志遠 wrote:
昨晚22日synology...(恕刪)
今天在 DS213j 上面重新安裝了 Cloud Statin Server & PC 端的 Cloud Station Drive 程式, 發現在 PC 端 rename folder 已經不會再全數重新上傳檔案了. 運作已正常, 但還要再確認是不是原廠修正了這個 bug.
NAS: DS213j
Version: DSM 6.0-7321 Update 3
PC: Windows 7 64bit
Cloud Station Server Version: 4.0-4204
Cloud Station Drive Version: Windows 4.0-4204
有相關問題的網友是否能再次確認. (server & client 端的軟體版本請一併注意)
補充: 經確認原廠近期並未更新程式, 所以上述問題為何在重新安裝套件及測試時已正常, 此部份必須再想辦法重製問題了.
更新:
現確定這 bug 還是存在,大致上也能重製問題(例如之前認為 ok 的 ds415+, 也一樣能重製出問題), 已將 log 交給原廠分析.
FB: Pctine
pctine wrote:
更新:
現確定這 bug 還是存在,大致上也能重製問題(例如之前認為 ok 的 ds415+, 也一樣能重製出問題), 已將 log 交給原廠分析....
感謝pc大的反覆測試
小弟剛剛也給他反覆rename
有時正常更名,有時卻重傳,
似乎跟你改名的方式有關?
測試環境:
NAS: DS215j
Version: DSM 6.0-7321
PC: Windows 8.1 64bit
Cloud Station Server Version: 4.0-4204
Cloud Station Drive Version: Windows 4.0-4204
比如:
aaa更名aaa999-->正常
aaa999更名aaa-->也會正常
但是
aaa999更名為aaakkk-->就會變重傳!
有興趣的可以試一試
另外,
檔案從A資料夾搬到B資料夾-->確定會重傳!
我看除了原廠更新軟體,不然應該無解!
小弟宣布放棄synology cloud drive!!
有稍微試了Goodsync這套軟體
似乎不錯,聰明多了,也可以及時同步,也支援讀取網路硬碟!!!
rename就是rename;搬移就是搬移,很準確!
有興趣的網友可以試看看哟!
想不到我們最常用的重新命名,搬移檔案,學問這麼大!
不是每個廠商都能把程式寫好的,
我還以為從win95-->win10,從磁碟片-->雲端硬碟,
都過了約20年了,
重新命名,搬移檔案這應該是最最最基本的功夫,
原來...."我錯了!!!我錯了!!!我錯了!!!"
Drop box ,Google drive,Owncloud,GoodSync這些外國軟體商真的有一套!!!
有他們的生存之道!
陳志遠 wrote:
有稍微試了Goodsync這套軟體
似乎不錯,聰明多了,也可以及時同步,也支援讀取網路硬碟!!!
rename就是rename;搬移就是搬移,很準確!...(恕刪)
感謝分享.
GoodSync 的確蠻好用的, 如果你是以本機電腦為主, 而雲端的儲存空間為輔, 這個軟體很好用, 但它也是有些盲點, 在之前有提到, 本機電腦所做的 file change 不管是新增, 修改, 刪除或是搬移, 這都很容易就同步反應至 NAS, 但如果是 NAS 的異動, 要同步回 PC Local, GoodSync 有時候無法做到即時同步 (理論上 samba 有支援 file change notifaication), 所以可能在 NAS (server) 端異動了, 但要過一段時間之後才會反應至 PC 端.
不過就像你所提的, 它的 move file or folder 很明確.
FB: Pctine
內文搜尋
從 APP 打開
X