Sporadisch kein Zugriff auf einzelne Dateien

Status
Für weitere Antworten geschlossen.

primesyn

Benutzer
Mitglied seit
16. Feb 2011
Beiträge
17
Punkte für Reaktionen
0
Punkte
0
Hallo zusammen,

mich plagt seit einigen Tagen ein Problem, das ich mir nicht erklären kann und ich finde auch keine Hilfe dazu.

Ich habe auf meiner DS411+ einen Share mit dem Namen "archive" in dem ich meine gesammelten Familienerinnerungen wie z.B. Videos, Fotos usw. aufbewahre.

Dieser Share wird ca. 2 mal pro Jahr per Script auf meinem PC mit Robocopy auf eine externe HDD exportiert und die Platte wird dann sicher aufbewahrt.

Das Problem:
Beim lesen der Daten bekomme ich genau bei 3 Dateien von einigen Tausenden ein "Zugriff verweigert" am ENDE des Kopiervorganges.

Rich (BBCode):
	    Neuer     		  79.1 m	2010-07-03 12.38.36 Taufe_Sophia.avi
2011/02/15 21:06:29 FEHLER 5 (0x00000005) Folgende Datei wird kopiert A:\VIDEORAW\DV\2010-07-03 Taufe_Sophia\2010-07-03 12.38.36 Taufe_Sophia.avi
Zugriff verweigert
	    Neuer     		   7.5 g	2010-07-03 12.45.59 Taufe_Sophia.avi
2011/02/15 21:09:38 FEHLER 5 (0x00000005) Folgende Datei wird kopiert A:\VIDEORAW\DV\2010-07-03 Taufe_Sophia\2010-07-03 12.45.59 Taufe_Sophia.avi
Zugriff verweigert
	    Neuer     		 281.6 m	2010-07-03 16.35.28 Taufe_Sophia.avi
2011/02/15 21:09:45 FEHLER 5 (0x00000005) Folgende Datei wird kopiert A:\VIDEORAW\DV\2010-07-03 Taufe_Sophia\2010-07-03 16.35.28 Taufe_Sophia.avi
Zugriff verweigert

Das Kuriose daran ist, dass erst am Ende des Kopiervorgangs der Zugriff verweigert wird. Das sieht man z.B. sehr schön bei der fast 8GB großen Datei. Kopiere ich mit dem Windows Explorer zeigt sich das gleiche Problem.
Aber: Kopiere ich mit dem Total Commander dann gibt's keine Probleme.

Kann jemand dazu was sagen?

Hintergrundwissen:
Es handelt sich hier um mein Archiv. Damit im normalen Alltag mit den Daten nichts passiert, existiert ein Berechtigungskonzept.

Mein normaler Benutzer "usrchristian":
Das ist mein normaler Benutzer mit dem ich immer alle Shares verbunden habe. Auch während dem Kopiervorgang oben bin ich mit diesem User verbunden. Der Benutzer darf im Archiv grundsätzlich nur lesen. Ändern, schreiben, Löschen ist untersagt. Das ist per ACL gesetzt. Zusätzlich ist auch noch im DSM unter den Share Berechtigungen auf nur lesen gesetzt.
Hinweis: Die Berechtigung wird über eine Gruppe geregelt, zu der der "usrchristian" dazugehört. Die ACL wird auf oberster Ebene gesetzt und alle darunter erben automatisch.

Benutzer "usrarcw":
Dieser Benutzer wird verwendet um das Archiv zu befüllen. Er darf aber nicht löschen. Das ist per ACL gesetzt. Ohne eine Gruppe. Im DSM auf lesen u. schreiben gesetzt.
Mit dem User wurde das Archiv vor einigen Wochen in einem Rutsch betankt. Das war im Prinzip eine Migration von meinem PC zur DS.

Benutzer "admshare":
Dieser Benutzer hat im Prinzip Full Control und wird für die Administration verwendet.

Vermutungen und Lösungsversuche:
Seltsam ist, dass nur 3 Dateien betroffen sind. Die 3 Dateien liegen direkt hintereinander im Verzeichnis. Im gleichen Verzeichnis liegen weitere Dateien die im Prinzip das gleiche Namensschema haben (davor und danach). Das Archiv enthält z.B. auch noch andere große Dateien und längere Pfade. Die fast 8GB große Datei ist jedoch die größte. Ich würde ja verstehen, wenn ein Berechtigunsproblem vorliegt und der ganze Share ein identisches Verhalten zeigen würde.
AntiVir wurde testweise deaktiviert, keine Änderung (Dienste auf disabled und reboot).
Per ssh als root eingeloggt sieht in dem Verzeichnis auch alles normal aus.
Robocopy lief im Backup Mode (/B Schalter). Im Normalmodus lies sich dann plötzlich die knapp 80MB große Datei kopieren! Die große ging weiterhin nicht und robocopy bleibt am Dateiende stehen (Muss per Strg-C dann beendet werden).

Ich vermute mal, dass nach einem Kopiervorgang noch bestimmte Attribute oder erweiterte Attribute in der Quelle modifiziert werden und das hierfür die Rechte Fehlen. Aber warum nur bei den 3 Dateien?
Kann es sein, dass hier irgendwo ein Bug ist und sich z.B. Samba beim Betanken "verhaspelt" hat??? Anders kann ich mir das nicht erklären.

Heute, wenn ich Zeit habe, werde ich weiter testen und schauen, wie es sich mit den anderen Usern verhält und was passiert, wenn usrchristian mehr Rechte bekommt.

Viele Grüße
Christian

Win7 64Bit
DSM 3.0 Build 1372

Hier noch die Robocopy Optionen zur Info:
Rich (BBCode):
   Quelle : A:\
     Ziel : V:\dis\A_A_Arc\

    Dateien : *.*
	    
Ausf?hrbare Dateien : bootmgr
	    hiberfil.sys
	    pagefile.sys
	    
 Ausf. Verzeichnisse : System Volume Information
	    *[nobackup]
	    *Recycle.Bin
	    
  Optionen: /JOB *.* /V /TEE /S /E /COPY:DAT /PURGE /B /NP /XJ /R:0 /W:0
 

itari

Benutzer
Mitglied seit
15. Mai 2008
Beiträge
21.900
Punkte für Reaktionen
14
Punkte
0
Schau dir doch auch einmal die Meldungen auf der DS zu diesen Vorgängen in der /var/log/messages an.

Itari
 

primesyn

Benutzer
Mitglied seit
16. Feb 2011
Beiträge
17
Punkte für Reaktionen
0
Punkte
0
Hallo itari,

Bingo! Danke für den Tip. Ich teste mich gerade wund...
Und genau zu dem Zeitpunkt, wenn eine der drei Dateien nicht gelesen werden kann, taucht so eine Meldung in der /var/log/messages auf. Ansonsten keine weiteren Besonderheiten zu sehen.

Rich (BBCode):
Feb 16 21:58:47 smbd: modules/vfs_default.c:562 SYNOEASRead [VIDEORAW/DV/2010-07-03 Taufe_Sophia/2010-07-03 12.38.36 Taufe_Sophia.avi:TOC.WMV][TOC.WMV] error, SynoErr=[0x0100]
Feb 16 22:01:57 smbd: modules/vfs_default.c:562 SYNOEASRead [VIDEORAW/DV/2010-07-03 Taufe_Sophia/2010-07-03 12.45.59 Taufe_Sophia.avi:TOC.WMV][TOC.WMV] error, SynoErr=[0x0100]

Meine weiteren Tests:
Es spielt übrigens absolut keine Rolle, mit welchem der drei User ich lese. Das Verhalten ist immer gleich.
robocopy mit /B bekommt immer 3x Zugriffsverweigerung am File-Ende.
robocopy ohne /B hängt nur bei der knapp 8GB großen Datei am Ende ohne eine Meldung. Die beiden kleineren werden kopiert (Per Einzelversuch nachgestellt).
Windows-Explorer verhält sich wie robocopy ohne /B.
Total Commander kopiert einwandfrei. In den Optionen ist bei Copy die "Standardmethode" ausgewählt.

Ich bin jetzt an der Stelle nicht so fit mit Samba und den Internas der DS und habe die Foreneinträge dazu noch nicht gelesen. Was hat es hier mit EA und dem @eaDir auf sich? Werden hier die Extended Attributes abgebildet oder ist das eine Medienfunktion der DS die z.B. durch eine Dateioperation angeworfen wird?
Für dieses Verzeichnis existiert im Archiv übrigens so ein @eaDir!
Per ls -lR | grep @eaDir habe ich festgestellt, dass es ca. 20 weitere Verzeichnisse gibt, die ein @eaDir haben. Die sind also in einer Minderheit der Verzeichnisse in meinem Archiv vorhanden.

Was passiert da im Hintergrund in meinem Fall genau? Und warum kann der Total Commander kopieren? Und warum sind genau diese drei Dateien betroffen?

Viele Grüße
Christian

Nachtrag 23:50 Uhr:
Ok hab gerade etwas über die @eaDir's gelesen. Das verstehe ich jetzt. Bei mir enthalten sie also die erweiterten Attribute. Warum sie aber nur in manchen Verzeichnissen existieren, muss ich noch herausfinden. Fakt ist, dass ich mich an den Verzeichnissen nicht störe (nicht so wie andere User hier).
Ich bin nur der Meinung, hier einen Bug aufgedeckt zu haben, denn das Verhalten ist nicht normal.
 
Zuletzt bearbeitet:

primesyn

Benutzer
Mitglied seit
16. Feb 2011
Beiträge
17
Punkte für Reaktionen
0
Punkte
0
Zu meinem vorherigen Post #3 gibt's wieder neue Erkenntnisse.

archive2 Test
Ich habe ein archive2 identisch angelegt und die Berechtigungen eingestellt. Anschließend so wie damals das Archiv befüllt. Ich habe noch die originale Quelle. Zwecks der Einfachheit habe ich aber nur den betroffenen Verzeichniszweig hochgeladen und danach sofort meinen "nur Lesebenutzer" verwendet.
Mit dem Test wollte ich ausschließen, dass irgendetwas die Dateien im Archiv beeinflusst.
Ergebnis:
Identisches Fehlverhalten!
Erkenntnisse:
Die SynoEAStreams werden beim Hochladen erzeugt.
Dabei sind keine Logeinträge in der /var/log/messages zu sehen.

archive3 Test
Jetzt hab ich nochmal ein Archiv angelegt, jedoch ohne ACL (Haken beim Erstellen nicht gesetzt) und meinem usrchristian r/w berechtigt.
Ergebnis:
Identisches Fehlverhalten!
Erkenntnisse:
Hier scheint wirklich etwas nicht in Ordnung zu sein, denn das was ich hier mache ist absoluter Standard.

So sieht die Verzeichnisstruktur mit dem @eaDir von archive3 aus:
Rich (BBCode):
nas> ls -lR | more
.:
-rwxrwxrwx    1 usrchris users     78907904 Jul  3  2010 2010-07-03 12.29.25 Taufe_Sophia.avi
-rwxrwxrwx    1 usrchris users         8928 Aug  2  2010 2010-07-03 12.29.25 Taufe_Sophia.avi.index
-rwxrwxrwx    1 usrchris users     83239936 Jul  3  2010 2010-07-03 12.35.13 Taufe_Sophia.avi
-rwxrwxrwx    1 usrchris users         9408 Aug  2  2010 2010-07-03 12.35.13 Taufe_Sophia.avi.index
-rwxrwxrwx    1 usrchris users     82950656 Jul  3  2010 2010-07-03 12.38.36 Taufe_Sophia.avi
-rwxrwxrwx    1 usrchris users         9376 Aug  2  2010 2010-07-03 12.38.36 Taufe_Sophia.avi.index
-rwxrwxrwx    1 usrchris users    925557248 Jul  3  2010 2010-07-03 12.41.10 Taufe_Sophia.avi
-rwxrwxrwx    1 usrchris users       102736 Aug  2  2010 2010-07-03 12.41.10 Taufe_Sophia.avi.index
-rwxrwxrwx    1 usrchris users    8109356544 Jul  3  2010 2010-07-03 12.45.59 Taufe_Sophia.avi
-rwxrwxrwx    1 usrchris users       898768 Aug  2  2010 2010-07-03 12.45.59 Taufe_Sophia.avi.index
-rwxrwxrwx    1 usrchris users    210744832 Jul  3  2010 2010-07-03 13.25.51 Taufe_Sophia.avi
-rwxrwxrwx    1 usrchris users        23536 Aug  2  2010 2010-07-03 13.25.51 Taufe_Sophia.avi.index
-rwxrwxrwx    1 usrchris users    193994752 Jul  3  2010 2010-07-03 14.31.11 Taufe_Sophia.avi
-rwxrwxrwx    1 usrchris users        21680 Aug  2  2010 2010-07-03 14.31.11 Taufe_Sophia.avi.index
-rwxrwxrwx    1 usrchris users    295363072 Jul  3  2010 2010-07-03 16.35.28 Taufe_Sophia.avi
-rwxrwxrwx    1 usrchris users        32912 Aug  2  2010 2010-07-03 16.35.28 Taufe_Sophia.avi.index
-rwxrwxrwx    1 usrchris users     98113024 Jul  3  2010 2010-07-03 16.42.02 Taufe_Sophia.avi
-rwxrwxrwx    1 usrchris users        11056 Aug  2  2010 2010-07-03 16.42.02 Taufe_Sophia.avi.index
-rwxrwxrwx    1 usrchris users    124682752 Jul  3  2010 2010-07-03 16.59.46 Taufe_Sophia.avi
-rwxrwxrwx    1 usrchris users        14000 Aug  2  2010 2010-07-03 16.59.46 Taufe_Sophia.avi.index
-rwxrwxrwx    1 usrchris users    192261632 Jul  3  2010 2010-07-03 21.17.35 Taufe_Sophia.avi
-rwxrwxrwx    1 usrchris users        21488 Aug  2  2010 2010-07-03 21.17.35 Taufe_Sophia.avi.index
drwxrwxrwx    2 root     users         4096 Feb 17 10:56 @eaDir
drwxrwxrwx    2 usrchris users         4096 Feb 17 10:56 Cover
drwxrwxrwx    2 usrchris users         4096 Feb 17 10:56 Sophia0001_IXUS
drwxrwxrwx    3 usrchris users         4096 Feb 17 10:56 Videocut_PS12U

./@eaDir:
-rwxrwxrwx    1 usrchris users        16996 Feb 17 10:54 2010-07-03 12.29.25 Taufe_Sophia.avi@SynoEAStream
-rwxrwxrwx    1 usrchris users        19612 Feb 17 10:54 2010-07-03 12.35.13 Taufe_Sophia.avi@SynoEAStream
-rwxrwxrwx    1 usrchris users        18252 Feb 17 10:54 2010-07-03 12.38.36 Taufe_Sophia.avi@SynoEAStream
-rwxrwxrwx    1 usrchris users         7428 Feb 17 10:54 2010-07-03 12.41.10 Taufe_Sophia.avi@SynoEAStream
-rwxrwxrwx    1 usrchris users        40180 Feb 17 10:56 2010-07-03 12.45.59 Taufe_Sophia.avi@SynoEAStream
-rwxrwxrwx    1 usrchris users         6284 Feb 17 10:56 2010-07-03 13.25.51 Taufe_Sophia.avi@SynoEAStream
-rwxrwxrwx    1 usrchris users        18564 Feb 17 10:56 2010-07-03 14.31.11 Taufe_Sophia.avi@SynoEAStream
-rwxrwxrwx    1 usrchris users        11692 Feb 17 10:56 2010-07-03 16.35.28 Taufe_Sophia.avi@SynoEAStream
-rwxrwxrwx    1 usrchris users         5972 Feb 17 10:56 2010-07-03 16.42.02 Taufe_Sophia.avi@SynoEAStream
-rwxrwxrwx    1 usrchris users         6076 Feb 17 10:56 2010-07-03 16.59.46 Taufe_Sophia.avi@SynoEAStream
-rwxrwxrwx    1 usrchris users         6180 Feb 17 10:56 2010-07-03 21.17.35 Taufe_Sophia.avi@SynoEAStream

Ein anderes Verzeichnis, das .mpg Dateien enthält bekommt kein @eaDir.
Verbleiben die Fragen, warum die 3 Dateien?
Was passiert beim Lesezugriff der verschieden Kopiertools und warum zeigt sich ein unterschiedliches Verhalten?

Bringt es was, wenn ich die EAStreams zur Verfügung stelle?
Was kann ich noch machen?

VG Christian
 

primesyn

Benutzer
Mitglied seit
16. Feb 2011
Beiträge
17
Punkte für Reaktionen
0
Punkte
0
Ich habe das Problem vor über einer Woche an den englischsprachigen Support gemeldet. Bis jetzt kam bis auf die Eingangsbestätigung noch keine Antwort. Ist die lange Zeit normal?

Kann ein Admin bitte diesen Thread in das SMB Forum verschieben? Da ist er sicher besser aufgehoben.

Dem Support habe ich auch noch geschrieben, dass die DS hier wirklich ein Problem in ihrer Kernkompetenz hat. Es ist anscheinend nicht egal, was in einem Share abgespeichert werden kann. Normalerweise limitieren hier die Protokolle oder Filesysteme, nicht aber der Inhalt.

Derweilen habe alle Dateien in dem Ordner in ein ca. 10GB großes 7zip Archiv gepackt. Damit hat die DS kein Problem und mein Disaster Export Script läuft auch sauber durch...

Weiß denn niemand was zu meinen anderen Fragen?

Danke und viele Grüße
Christian
 

itari

Benutzer
Mitglied seit
15. Mai 2008
Beiträge
21.900
Punkte für Reaktionen
14
Punkte
0
Könnte es sein, dass die fraglichen Dateien "alternate data streams" unter NTFS hatten?

Letzte Woche war CeBIT ... es kann sein, dass bei Synology deswegen alles etwas stressiger abgelaufen ist (Messe-Leute vertreten, Schichtdienst usw.). Frag doch noch einmal per E-Mail nach, ob sie schon eine Idee haben, was da für ein Problem vorliegt.

Itari
 

Tribun

Benutzer
Mitglied seit
29. Aug 2010
Beiträge
183
Punkte für Reaktionen
0
Punkte
0
du verwendest /R:0 & /W:0
/R:n :: Anzahl von Wiederholungsversuchen bei fehlerhaften Kopiervorgängen. Der Standardwert ist 1 Million.
/W:n :: Wartezeit zwischen Wiederholungsversuchen. Der Standardwert ist 30 Sekunden.

erhöhe diese Werte oder entferne diese Parameter.
. . . versuchshalber . . .

Tribun

PS: Da der Robocopy ein äußerst aufwendiger Zeitgenosse ist (hinsichtlich Optionen und Parameter) Entschlacke die Syntax auf das Minimum!
Quelle : A:\
Ziel : V:\dis\A_A_Arc\

Dateien : *.*

Ausf?hrbare Dateien : bootmgr
hiberfil.sys
pagefile.sys

Ausf. Verzeichnisse : System Volume Information
*[nobackup]
*Recycle.Bin

Optionen: /JOB *.* /V /TEE /S /E /COPY: DAT /PURGE /B /NP /XJ /R:0 /W:0
. . . Denke, daß die Syntax nicht korrekt ist.

ROBOCOPY "%Quelle%" "%Ziel%"
Wähle diese "störrischen" Dateien aus und probiere das Lokal Platte 1 => Platte 2 ohne DS!
Syntax "Aufbohren". Wenns klappt, geht es auch mit der DS. Ich bevorzuge UNC: \\Servername\Public\Verzeichnis meiner Wahl\

Ok, mein Ansatz ist ein wenig komplizerter. Eine Batch (rd. 900 Zeilen!) liest Protokollfile, ermittelt die Differenz an Tagen +1 zwischen aktuellem und letzten Backupdatum. Liest eine Datei mit Ausschlußdatei(-typen) ein und liest eine weitere Datei ein. Übergeben werden so alle möglichen Parameter %Quelle%, %Ziel% und optionen mit Protokoll, Alter etc.
zB.:
:Source=E:
:Target=\\DS\Datensicherung
:Opt=/S !Exclude! !MaxAge! /R:10 /W:30 /TS /FP /BYTES /NP /LOG:"!Target!\[!Date!]_log.asc" /TEE
; die eigentlich zu sichernden Verzeichnisse:
"Daten\Microsoft Access"?"*.*"

!MaxAge! wird durch die Batch ermittelt, !Exclude! ist die Datei mit den Ausschlußdateien, !Target! und !Date! werden durch die Batch generiert.
Die Bach macht beim zeilenweisen Auslesen der Quelldatei das draus:
Robocopy.exe "!Source!\%%~a" "!Target!\%%~a" "%%~b" !opt!
Innerhalb der Forschleifen werden die einzelnen Dateien/Verzeichnisse dem Roboter übergeben ;-)
So kann ich beliebige Laufwerke/Verzeichnisse mit unterschiedlichen optionen in einer einzigen Quelldatei übergeben.
 
Zuletzt bearbeitet:

primesyn

Benutzer
Mitglied seit
16. Feb 2011
Beiträge
17
Punkte für Reaktionen
0
Punkte
0
Danke fürs moven...

Ja, da sind mit Sicherheit welche und die ursprüngliche Quelle ist auch NTFS. Die DS erzeugt ja auch in dem Directory das @eaDir mit den Streams Dateien. (Siehe Post #4, Codebox etwas runterscrollen).
Die Streams von der DS habe ich auch an den Support gesendet.

Ich habe aber an mehreren Stellen solche Streams. Nur diese 3 bzw. 1 Datei(en) machen aber Probleme.

Ich lese gerade einiges über ADS. Ich wusste zwar dass es das gibt, aber mir wird erst jetzt bewusst, was damit alles möglich ist. Krass, wieder was gelernt. Ich schaue mir heute Abend mit den Tools die Streams mal genauer an, was da so alles an den avi Files hängt.

Der DS sollte das jedoch egal sein... Ist es aber leider nicht. Dazu verhalten sich noch die verwendeten Kopiertools unterschiedlich.

VG Christian
 

primesyn

Benutzer
Mitglied seit
16. Feb 2011
Beiträge
17
Punkte für Reaktionen
0
Punkte
0
du verwendest /R:0 & /W:0
/R:n :: Anzahl von Wiederholungsversuchen bei fehlerhaften Kopiervorgängen. Der Standardwert ist 1 Million.
/W:n :: Wartezeit zwischen Wiederholungsversuchen. Der Standardwert ist 30 Sekunden.

erhöhe diese Werte oder entferne diese Parameter.
. . . versuchshalber . . .

Tribun

Ich werde es testen!
Aber ich glaube nicht, dass das was bringt.
Per Windows Explorer scheitert es nur an der 7,5 GB Datei und bei Robocopy entscheidet der /B (Backup Mode), ob 1 oder 3 Dateien betroffen sind.
Vermutlich liegt es an den ADS Streams, die jedes Kopiertool nach dem eigentlichen Kopieren der Haupt-Datei abarbeitet. Und da kracht es dann.
VG Christian
 

Tribun

Benutzer
Mitglied seit
29. Aug 2010
Beiträge
183
Punkte für Reaktionen
0
Punkte
0
ADS auf einer ext3-Platte???
dachte, das ist ein Geschenk von NTFS!

Tribun

Nachtrag: Dir
Seit w7 wurde der Dir-Befehl erweitert:
/R Zeigt alternative Datenströme der Datei an.
 
Zuletzt bearbeitet:

Tribun

Benutzer
Mitglied seit
29. Aug 2010
Beiträge
183
Punkte für Reaktionen
0
Punkte
0
Per Windows Explorer scheitert es nur an der 7,5 GB Datei und bei Robocopy entscheidet der /B (Backup Mode), ob 1 oder 3 Dateien betroffen sind.

Sind die Dateien 100% fehlerfrei auf die ext3/4-Platte der DS gelangt???
Erst mal diese Fehler ausschließen!

Tribun
 

itari

Benutzer
Mitglied seit
15. Mai 2008
Beiträge
21.900
Punkte für Reaktionen
14
Punkte
0
ADS auf einer ext3-Platte???
dachte, das ist ein Geschenk von NTFS!

Die Frage sollte lauten, was alles von dieser Samba-Version wie emuliert wird. Ab Samba 3.2 gibt es den ADS-Support.

Itari
 

primesyn

Benutzer
Mitglied seit
16. Feb 2011
Beiträge
17
Punkte für Reaktionen
0
Punkte
0
@Tribun:
Bei mir wird der Robocopy ebenfalls per Script bedient. Das Script wiederum wird durch Steuerdateien gesteuert. Das habe ich hier alles nicht gepostet, weil es nur irritiert. Robocopy hat wirklich einige Besonderheiten und Stolperfallen, aber ich habe mittlerweile x Jahre Erfahrung damit und es läuft auch alles. Mein Problem hat auch nicht direkt was mit Robocopy zu tun. Die unterschiedlichen Kopiertools zeigen unterschiedliche Fehlverhalten.

Ich teste heute Abend, welche ADS an den 3 avi Files hängen. Ich schaue mir das mit den Sysinternal Tool und auch mit dem neuen Dir Schalter an.
Dann teste ich z.B. auch noch ob /COPY: DAT zu /COPY: DT was bringt....

ADS auf einer ext3-Platte???
dachte, das ist ein Geschenk von NTFS!
Damit kann ich jetzt nichts anfangen. Habe ich so nie geschrieben.

Bei mir lagen die Files ursprünglich mal auf NTFS. Seit ich die DS habe, wurden die Files (Mein Archiv) auf die DS migriert (DSM 3.0). Ich habe bereits gelernt, dass die DS internen ext Filesysteme diese ADS nicht wie bei NTFS direkt im Filesystem abbilden können. Deswegen gibt es diese @eaDir's in denen diese Informationen gespeichert werden.
Warum auch immer, hat die DS bei gewissen Leseoperationen genau bei diesen 3 Dateien Probleme und es erscheint die Meldung in der /var/log/messages.
 

primesyn

Benutzer
Mitglied seit
16. Feb 2011
Beiträge
17
Punkte für Reaktionen
0
Punkte
0
Sind die Dateien 100% fehlerfrei auf die ext3/4-Platte der DS gelangt???
Erst mal diese Fehler ausschließen!

Tribun

Ja, das sind sie. Im Beitrag #4 habe ich geschrieben, wie ich den Fehler jederzeit reproduzieren kann. Beim Hochladen von NTFS aus gibt es keinerlei Fehler.
Aber ich teste heute Abend und werde die Files auch mal ohne ADS hochladen usw...

Aber ich bleib dabei: Selbst wenn da der größte Schrott als ADS an einer Datei heftet, müsste das absolut transparent für den Samba der DS sein.
 

Tribun

Benutzer
Mitglied seit
29. Aug 2010
Beiträge
183
Punkte für Reaktionen
0
Punkte
0
. . Ab Samba 3.2 gibt es den ADS-Support. Itari
Das ist ein Argument ;-)
Ich war bisher der Meinung, das ADS von ext3 oder ext4 nicht unterstützt wird.
Kopiere ich eine Datei mit ADS von NTFS auf FAT32 (MMC oder Stick) ist der ADS weg!

Man lernt nie aus . . .:cool:

Tribun
 

Tribun

Benutzer
Mitglied seit
29. Aug 2010
Beiträge
183
Punkte für Reaktionen
0
Punkte
0
. . Deswegen gibt es diese @eaDir's in denen diese Informationen gespeichert werden. . .

Die einzige und letzte Erklärung die ich hierzu habe:
Unterschiede im Zeichenvorrat des verwendeten Zeichensatzes.
NTFS:ADS (ANSI) zur DS ext3/ext4 (unicode??)
Evtl. geht bei der Emulation was schief?


Nachtrag
Dir Befehl: dir /S /R *.* |find /I ":$Data" Auf keinen Fall /B => sonst klappt das nicht!
ohne find wird es unübersichtlich

Tribun
 

primesyn

Benutzer
Mitglied seit
16. Feb 2011
Beiträge
17
Punkte für Reaktionen
0
Punkte
0
So, jetzt habe ich Zeit gehabt und wieder neue Erkenntnisse!

Es liegt definitiv an den existierenden ADS!

Ich habe jetzt mal mit dir und streams.exe (Sysinternals) gearbeitet

Rich (BBCode):
D:\Archiv_unused_[nobackup]\VIDEORAW\DV\2010-07-03 Taufe_Sophia>dir *.avi /r
 Datenträger in Laufwerk D: ist Daten
 Volumeseriennummer: E887-291A

 Verzeichnis von D:\Archiv_unused_[nobackup]\VIDEORAW\DV\2010-07-03 Taufe_Sophia

03.07.2010  11:29        78.907.904 2010-07-03 12.29.25 Taufe_Sophia.avi
                             16.856 2010-07-03 12.29.25 Taufe_Sophia.avi:TOC.WMV:$DATA
03.07.2010  11:35        83.239.936 2010-07-03 12.35.13 Taufe_Sophia.avi
                             19.472 2010-07-03 12.35.13 Taufe_Sophia.avi:TOC.WMV:$DATA
03.07.2010  11:38        82.950.656 2010-07-03 12.38.36 Taufe_Sophia.avi
                             18.112 2010-07-03 12.38.36 Taufe_Sophia.avi:TOC.WMV:$DATA
03.07.2010  11:41       925.557.248 2010-07-03 12.41.10 Taufe_Sophia.avi
                              7.288 2010-07-03 12.41.10 Taufe_Sophia.avi:TOC.WMV:$DATA
03.07.2010  11:45     8.109.356.544 2010-07-03 12.45.59 Taufe_Sophia.avi
                             40.040 2010-07-03 12.45.59 Taufe_Sophia.avi:TOC.WMV:$DATA
03.07.2010  12:25       210.744.832 2010-07-03 13.25.51 Taufe_Sophia.avi
                              6.144 2010-07-03 13.25.51 Taufe_Sophia.avi:TOC.WMV:$DATA
03.07.2010  13:31       193.994.752 2010-07-03 14.31.11 Taufe_Sophia.avi
                             18.424 2010-07-03 14.31.11 Taufe_Sophia.avi:TOC.WMV:$DATA
03.07.2010  15:35       295.363.072 2010-07-03 16.35.28 Taufe_Sophia.avi
                             11.552 2010-07-03 16.35.28 Taufe_Sophia.avi:TOC.WMV:$DATA
03.07.2010  15:42        98.113.024 2010-07-03 16.42.02 Taufe_Sophia.avi
                              5.832 2010-07-03 16.42.02 Taufe_Sophia.avi:TOC.WMV:$DATA
03.07.2010  15:59       124.682.752 2010-07-03 16.59.46 Taufe_Sophia.avi
                              5.936 2010-07-03 16.59.46 Taufe_Sophia.avi:TOC.WMV:$DATA
03.07.2010  20:17       192.261.632 2010-07-03 21.17.35 Taufe_Sophia.avi
                              6.040 2010-07-03 21.17.35 Taufe_Sophia.avi:TOC.WMV:$DATA
              11 Datei(en), 10.395.172.352 Bytes
               0 Verzeichnis(se), 1.096.474.734.592 Bytes frei

D:\Archiv_unused_[nobackup]\VIDEORAW\DV\2010-07-03 Taufe_Sophia>streams *.avi

Streams v1.56 - Enumerate alternate NTFS data streams
Copyright (C) 1999-2007 Mark Russinovich
Sysinternals - www.sysinternals.com

D:\Archiv_unused_[nobackup]\VIDEORAW\DV\2010-07-03 Taufe_Sophia\2010-07-03 12.29.25 Taufe_Sophia.avi:
         :TOC.WMV:$DATA 16856
D:\Archiv_unused_[nobackup]\VIDEORAW\DV\2010-07-03 Taufe_Sophia\2010-07-03 12.35.13 Taufe_Sophia.avi:
         :TOC.WMV:$DATA 19472
D:\Archiv_unused_[nobackup]\VIDEORAW\DV\2010-07-03 Taufe_Sophia\2010-07-03 12.38.36 Taufe_Sophia.avi:
         :TOC.WMV:$DATA 18112
D:\Archiv_unused_[nobackup]\VIDEORAW\DV\2010-07-03 Taufe_Sophia\2010-07-03 12.41.10 Taufe_Sophia.avi:
         :TOC.WMV:$DATA 7288
D:\Archiv_unused_[nobackup]\VIDEORAW\DV\2010-07-03 Taufe_Sophia\2010-07-03 12.45.59 Taufe_Sophia.avi:
         :TOC.WMV:$DATA 40040
D:\Archiv_unused_[nobackup]\VIDEORAW\DV\2010-07-03 Taufe_Sophia\2010-07-03 13.25.51 Taufe_Sophia.avi:
         :TOC.WMV:$DATA 6144
D:\Archiv_unused_[nobackup]\VIDEORAW\DV\2010-07-03 Taufe_Sophia\2010-07-03 14.31.11 Taufe_Sophia.avi:
         :TOC.WMV:$DATA 18424
D:\Archiv_unused_[nobackup]\VIDEORAW\DV\2010-07-03 Taufe_Sophia\2010-07-03 16.35.28 Taufe_Sophia.avi:
         :TOC.WMV:$DATA 11552
D:\Archiv_unused_[nobackup]\VIDEORAW\DV\2010-07-03 Taufe_Sophia\2010-07-03 16.42.02 Taufe_Sophia.avi:
         :TOC.WMV:$DATA 5832
D:\Archiv_unused_[nobackup]\VIDEORAW\DV\2010-07-03 Taufe_Sophia\2010-07-03 16.59.46 Taufe_Sophia.avi:
         :TOC.WMV:$DATA 5936
D:\Archiv_unused_[nobackup]\VIDEORAW\DV\2010-07-03 Taufe_Sophia\2010-07-03 21.17.35 Taufe_Sophia.avi:
         :TOC.WMV:$DATA 6040

D:\Archiv_unused_[nobackup]\VIDEORAW\DV\2010-07-03 Taufe_Sophia>

Das ist ein Auszug aus der originalen Quelle lokal auf meinem PC mit NTFS Dateisystem. Es existieren ADS mit dem Namen :TOC.WMV.
Das wird vermutlich mal von Windows Media angelegt worden sein und einen TOC (Table Of Content) enthalten.

Jetzt habe ich gleich mal mit "streams.exe -d *.avi" direkt auf der DS in dem Testarchiv die ADS gelöscht. Samba machte dabei keine Probleme und siehe da, jetzt lassen sich auch die 3 Problemdateien ohne Probleme lesen! Lokal habe ich jetzt gar nicht versucht die Dateien von ADS zu befreien und hochzuladen, weil dass dann sicher auch funktioniert.

Bleibt die Frage, warum die DS mit den 3 ADS Probleme hat und nicht mit den Anderen?

@Tribun
Das mit den /R u. /W hat wie vermutet nichts gebracht. Robocopy probiert es halt dann so oft wie ich es einstellt und scheitert jedes Mal.
Auch mein COPY: DT also ohne Attribute hilft nicht.
Ach ja, meine DS hate die Erstinbetriebnahme mit DSM 3.0. Volume1 ist ein Syno Hybrid Volume und nutzt ext4. Samba emuliert, wie Itari schon geschrieben hat, die ADS und speichert sie in den @eaDir's weil ext Filesysteme sowas nicht nativ können.
Ob das Zeichensatzprobleme sind? Keine Ahnung...

Irgendwelche Vorschläge?

Theoretisch entferne ich einfach die sowieso unerwünschten ADS. Aber mich interessiert trotzdem, warum es hier ein Problem gibt.
 

primesyn

Benutzer
Mitglied seit
16. Feb 2011
Beiträge
17
Punkte für Reaktionen
0
Punkte
0
Problem gelöst!

Nach ein paar Mails hin und her mit dem Support, wie sie den Fehler nachstellen können, kam eine Zwischenlösung.
Seit der offiziellen DSM 3.0-1372 gab es ein paar Patches für Samba, die mittlerweile auch im offiziellen DSM 3.1-1594 enthalten sind.
Ich wurde gebeten entweder den Patch oder gleich DSM 3.1 einzuspielen. Bin dann gleich auf 3.1 gegangen.
Fehler lässt sich jetzt nicht mehr nachstellen und auch die originale Problem-Quelle lässt sich mit allen Methoden lesen.

Danke an Alle für die Ratschläge und besonders an itari für die Hinweise in Richtung Problemquelle ADS! Damit konnte ich dem Support genau erklären, wo es hakt.

Viele Grüße
Christian
 
Status
Für weitere Antworten geschlossen.
 

Kaffeautomat

Wenn du das Forum hilfreich findest oder uns unterstützen möchtest, dann gib uns doch einfach einen Kaffee aus.

Als Dankeschön schalten wir deinen Account werbefrei.

:coffee:

Hier gehts zum Kaffeeautomat