Folgendes Szenario: 

 

Es befinden sich Dateien auf einem Share, dass bei der Cache-Nutzung auf "Prefer" gestellt ist. Die Dateien liegen physikalisch auch wirklich auf der SSD (Cache). Jetzt sollen die Dateien auf ein anderes Share verschoben werden (mit Krusader). Dieses andere Share ist auf Cache: No konfiguriert. Verschiebt man jetzt mit Krusader die Daten (von Share zu Share, in Krusader gemountet), so landen diese (innerhalb eines Augenblicks) .... auf dem Cache - obwohl das entsprechende Share auf Cache: NO steht. Kurz darauf meldet auch FixCommonProblems: Achtung, es liegen Dateien auf dem Cache obwohl das Share auf No steht. 

Das dürfte doch eigentlich nicht passieren oder? Ist das ein Bug oder wie lässt sich dieses Verhalten erklären? (Unraid 6.9.3)

It's not a bug, but rather how every OS include Unraid operates "beneath the scenes"

 

If a rename operation is successful, then the file is simply renamed.  If the rename is not successful, then a copy / delete operation takes place.

 

ie: You're trying to move a file within the same mountpoint (in this case /mnt/user), so the rename succeeds.  If you did it over SMB, then you'd be using two separate mount points (/mnt/user/shareA and /mnt/user/shareB) then the rename would fail (can't rename across mounts), so the copy / delete takes place.

 

What you're doing by using Krusader is effectively bypassing the include / exclude / use cache settings since you're only passing through /mnt/user mapped to a single path in the template (/media?)

Lässt sich nicht ändern. Dieser "Bug" kann nicht behoben werden. Es gibt noch einen gefährlicheren. Wenn du von /mnt/cache/sharename nach /mnt/user/sharename verschiebst, liest und schreibst du die selbe Datei = korrupte Datei. Daher niemals zwischen Disk und Share Dateien bewegen. Nur Disk zu Disk oder Share zu Share.

 

3 hours ago, mgutt said:

Lässt sich nicht ändern. Dieser "Bug" kann nicht behoben werden. Es gibt noch einen gefährlicheren. Wenn du von /mnt/cache/sharename nach /mnt/user/sharename verschiebst, liest und schreibst du die selbe Datei = korrupte Datei. Daher niemals zwischen Disk und Share Dateien bewegen. Nur Disk zu Disk oder Share zu Share.

 

Aber wo ist jetzt sein Fehler wenn er von Share zu Share schiebt bzw. wie sollte man das korrekt machen? Das Beispiel von dir ist dagegen ja verständlich Aufgrund der Architektur von Unraid.

Dieser Fehler von Share zu Share lässt sich leider nicht vermeiden. In so einem Fall muss man von Disk zu Disk arbeiten.

15 hours ago, mgutt said:

Dieser Fehler von Share zu Share lässt sich leider nicht vermeiden. In so einem Fall muss man von Disk zu Disk arbeiten.

Aber das ist dann ja schon ein echtes Feature Limit in UnRaid wenn der User nicht weiß welches Share über welche Cache Settings verfügt wie soll er das dann beeinflussen? 😱D.h. im Default sollte man alle Laufwerke mindestens auf Cache Yes laufen haben?

8 minutes ago, Smolo said:

D.h. im Default sollte man alle Laufwerke mindestens auf Cache Yes laufen haben?

Aus dem Grund empfehle ich jedem Unraid Neuling ausschließlich Yes und Prefer zu verwenden. An No und Only sollte man sich erst heranwagen, wenn man das System verstanden hat.

 

10 minutes ago, Smolo said:

wenn der User nicht weiß welches Share über welche Cache Settings verfügt

Naja, das wird er wohl wissen, weil er es ja eingestellt hat?!

25 minutes ago, mgutt said:

Aus dem Grund empfehle ich jedem Unraid Neuling ausschließlich Yes und Prefer zu verwenden. An No und Only sollte man sich erst heranwagen, wenn man das System verstanden hat.

 

Naja, das wird er wohl wissen, weil er es ja eingestellt hat?!

Das hat aber eigentlich nichts mit Neuling zu tun. Der einzige der das weiß ist der Admin aber lässt du deine Frau / Kids an die Unraid Config? 🤣