DSM 7.2 Änderungsdatum ändert sich ohne Änderung

[patrickn]

Hi, ich mal wieder.
Und mal wieder ein Problem, was mir absolut nicht gefällt.

DS223 mit DSM 7.2.1-69057 Update 5, vor gut 3 Wochen hab ich meine DS116 nun vollständig ersetzt. Nun wieder ein Problem, was für mich unerklärlich ist, und (für mich) eigentlich auch absolut inakzeptabel ist.

Offenbar ändert irgendwas bei DSM die Änderungszeiten von Ordnern, ohne dass eine Änderung stattfand. Sowohl FileStation, als auch SMB/Windows. Zuerst gerade aufgefallen bei einem Ordner, bei dem es definitiv keine Änderung gab - Änderungsdatum auf einmal 02.07.24 - 08:05. Die letzte Änderung fand am 25.06.2023 statt. Dann natürlich weiter gesucht, mit nicht sehr erfreulichem Ergebnis: Das war nicht der einzige Ordner.

Z.B. DS116:


DS223 - wie gesagt, ohne Änderung:


Es sind definitv keine Ordner bzw. Dateien dazugekommen oder gelöscht worden, das ist bis aufs Byte wie bei der DS116 - ausser 07-2024, daher existiert der auf der DS116 auch nicht. Nächster Ordner:

DS116:

DS223:


Öffne ich z.B: den 2. Ordner "DCIM", also ein Kameraordner:
DS116

DS223, und jetzt wird es noch absurder, aus dem "2.7." wird auf einmal "30.6."?!

....und jetzt, wo ich es sehe, ist das ja auch auf der DS116 inkonsistent

Wie gesagt, egal ob SMB/Windows, Filestation, es passt bei beiden nicht mehr. Und das ist bei mir ehrlichgesagt die Kategorie von "passt mir gar nicht ich schmeiß das Ding ausm Fenster!" Einfach Änderungszeiten ändern ist für mich ein abolutes No-Go!

Irgendwelche Ideen, was DSM da treibt, oder jemand ähnliches bei sich?

 

[ctrlaltdelete]

Vermutung:
Du greifst mit Windows auf die Ordner zu und die enthalten Bilder, da wird Win den Index/Thumbs DB erneuern.

 

[patrickn]

Thumbs.db hab ich gänzlich für Netzwerkordner deaktiviert

Ich vermute eher mal wieder diese unsäglichen @ eaDir Ordner. Kann ich aber erst am späten Nachmittag/Abend mal in der Konsole schauen, wenn das so sein sollte Frage ich mich allerdings warum der Einfluss auf das Änderungsdatum hat.

 

[Benares]

Also ich grad mal bei mir geschaut. Also die meisten meiner alten Verzeichnisse in /photo behalten ihr altes Datum. Und wenn nicht, ist es tatsächlich das @eaDir-Verzeichnis darin, das sein Datum ändert was auch zur Änderung des übergeordneten Ordner führt. Ich kann aber nicht erkennen, wieso sich das Datum des @eaDir-Verzeichnisses ändert, denn die Inhalte darin sind weiterhin alt.

 

[Kaktus1911]

Kann es sein dass du da den letzten Zugriff siehst? - lass dir in den anderen Spalten mehr anzeigen vielleicht lässt sich das Problem so nachvollziehen.

 

[patrickn]

@Kaktus1911 Hab ehrlich gesagt noch nie so recht verstanden, was "letzter Zugriff" triggert Mal wirds aktualisiert, mal nicht. Das scheint es aber nicht zu sein, wird bei Ordnern gar nicht angezeigt, und in den Spalten finde ich es auch nicht zum anzeigen.

Scheinen wohl tatsächlich mal wieder der dussligen @eaDir Ordner zu sein

d---------+ 1 patrick users 13856 2024-06-30 21:47:30.470741983 +0200 01-2024
d---------+ 1 patrick users 14064 2024-06-30 21:47:05.925649502 +0200 02-2024
d---------+ 1 patrick users 25960 2024-06-30 21:44:00.063949208 +0200 03-2024
d---------+ 1 patrick users 15976 2024-06-30 21:45:02.955186171 +0200 04-2024
d---------+ 1 patrick users 19096 2024-06-30 21:45:33.479301180 +0200 05-2024
d---------+ 1 patrick users 20760 2024-06-30 21:39:47.533997720 +0200 06-2024
d---------+ 1 patrick users 22216 2024-07-18 08:26:57.028646430 +0200 07-2024

Ordner "01-2024":

drwxrwxrwx+ 1 root    root    13520 2024-06-30 22:09:54.024796173 +0200 @eaDir

d---------+ 1 patrick users   13480 2024-06-30 21:47:30.779743148 +0200 Wohnung

Ordner "01-2024/Wohnung"

drwxrwxrwx+ 1 root    root     13312 2024-06-30 21:47:48.608810324 +0200 @eaDir

Abgesehen davon, dass ich das absolut unlogisch finde, dass versteckte Systemordner einfach die Anzeige verfälschen, müsste der Logik nach doch eigentlich am Ordner 22:09 dranstehen, das ist doch aktueller als die "21:47" im ersten Ordner 01-2024. Und anders als bei @Benares sind die Dateien in 01-2024/Wohnung/@eaDir wo er mir 30.6.24 anzeigt, sogar aktueller, nämlich vom 2.7. Das passt doch so oder so nicht?

Edit: So, habe heute morgen den Ordner, bei dem es mir erstmalig aufgefallen ist, wiederhergestellt. Ergebnis bis gerade eben:

Gerade die Indizierung in Universal Search eingerichtet, und tada...

 

[patrickn]

Und einfach den @eaDir Ordner kicken funktioniert auch nicht, dann wird das aktuelle Datum gesetzt...
In HyperBackup ist die Änderung übrigens auch drin, und zwar ohne, dass das im Änderungslog ersichtlich ist, dass da "was" geändert wurde

Menno, zum



Edit:

Verrückt. Stelle ich den Ordner wieder her, wird zeitgleich ein @eaDir erstellt:

drwxrwxrwx+ 1 root       root     1096 2024-07-19 19:19:55.506548708 +0200 @eaDir

Darin auch JPG's mit dem aktuellen Zeitstempel, trotzdem stimmt die Änderungszeit noch


Weiß gerade nicht, was mich mehr aufregt, dass es mir aufgefallen ist, dass es mir erst jetzt auffällt, oder das das bei Synology bisher keinem aufgefallen ist - jedenfalls hat die DS116 dieses Spiel auch getrieben, gut sichtbar in HyperBackup:

9.5.2023, 4 Uhr morgens


10.5.2023, 4:00 Morgens

 

[patrickn]

Also... es ist eindeutig Universal Search und der @eaDir Ordner.
Kann man absolut nachstellen.

Ordner wiederherstellen, Indizierung anschalten, @eaDir ändert das "Änderungsdatum"
Indizierung schon an, Ordner wiederherstellen, @eaDir wird mit aktueller Zeit schon angelegt, "Änderungsdatum" bleibt erst mal auf dem alten, richtigen Wert... bis DSM irgendwann meint daran rumfummeln zu müssen

Die reine Dateiindizierung hat wohl keine Auswirkung, Musik, Videos und Dokumente mit dem Ordner, mit dem ich es teste, auch nicht. (Obwohl auch z.B. PDF Dateien enthalten sind) ... aber sobald man die Inhaltsindizierung "Fotos" aktiviert, kommen die @eaDir Ordner auf jeden Fall.





Joar, dann weiß ich ja, wofür ein vermutlich größerer Teil dieses Wochenende draufgehen wird

 

[patrickn]

Man kann einfach die Ordner wiederherstellen mit HyperBackup, und neuere Dateien bleiben erhalten und die ganzen (also wirklich uuuuuuuuunzähligen) @eaDir Ordner sind gleichzeitig auch weg?

Coole Sache, geht doch nicht das ganze Wochenende drauf

 

[Benares]

Aber entstehen die nicht irgendwann wieder, wenn die Indizierung zuschlägt?

Ich lass übrigens von Zeit manuell auch einige Wartungs-Jobs laufen, die den Rotz in den @eaDir-Verzeichnisse etwas aufräumen.

Auszug aus meinem Readme:

# Wartung /photo
find /volume1/photo -name '*SynoEAStream' -delete
find /volume1/photo -name 'Thumbs.db' -delete
# Gesamtgröße aller @eaDir-Verzeichnisse ermitteln
find /volume1/photo -name '@eaDir' -print0 | du -sch --files0-from=-

Das führt natürlich auch zu einer Änderung des Verzeichnisdatums.

 

[patrickn]

Ja, doch, wohl oder übel leider schon.
Werde die Indizierung nun auf nur Dateinamen beschränken, dann gibts die eaDir Ordner nicht. Hoffentlich denk ich nur dran...
Inhaltsindizierung für Fotos scheint mir jetzt aber nicht sinnvoll, finde aktuell jedenfalls keinen Mehrwert. Was wird da indiziert, Kameramodell, und sowas halt, also die normalen Matainfos?

Noch besser wärs, wenn die Änderungszeit des eaDir einfach keinen Einfluss auf die Änderungszeit eines Ordners hat. Geht ja. Ist die Indizierung an, und es wird wiederhergestellt, wird ja auch ein aktueller eaDir Ordner mit aktueller Zeit angelegt - da bleibt das Datum aber erhalten. Nur wenn man die Indizierung nachträglich erst aktiviert, wird die Änderungszeit manipuliert.

Vermutlich werd ich aber auch noch bei Synology mal anklopfen. Aber irgendwie klappt das über DSM gerade auf beiden DS' nicht. Support-Center ist wieso auch immer auf englisch, und irgendwie lassen sich keine Anhänge hochladen

 

[synfor]

Man kann einfach die Ordner wiederherstellen mit HyperBackup, und neuere Dateien bleiben erhalten und die ganzen (also wirklich uuuuuuuuunzähligen) @eaDir Ordner sind gleichzeitig auch weg?

Wieso sollten die Ordner bei der Vorgehensweise verschwinden?

 

[patrickn]

Musst du Synology fragen, jedenfalls tun sie es.

root@DiskStation:/volume1/backup/@PATRICK-PC# find ./ -type d -name @eaDir
./@eaDir

Vorm Wiederherstellen hab ich eine ganze Liste mit @eaDir's bekommen.

 

[Benares]

Glaub ja nicht, dass es dies @eaDir-Verzeichnisse nur in den Medien-Verzeichnissen findet. Die gibt es oft an den unmöglichsten Stellen

Schau dir mal mal z.B.

find /volume1 -name @eaDir | more

an.

 

[patrickn]

Hab ich auch schon gemacht das komplette volume zu durchsuchen, echt die Pest. Die Liste hört echt gar nicht auf. So gut wie in jedem Ordner mit Bildern, und Unterordner, und Unterordner vom Unterordner,......
Schlimmer als diese thumbs.db Dateien bei Windows

Irgendwie legt das System nun auch wieder bei manchen Ordnern @eaDir Ordner an mit irgendwelchem PDF Zeug und aktuellem Datum und Zeit, Obwohl die Suchindizierung gerade komplett aus ist.. Naja, die Änderungszeit bleibt gleich, also was solls.

Hauptsache mein Archiv, in dem Jahre nichts geändert wurde, ist wieder vom Datum so wie es war. Das findet mein innerer Monk nämlich ziemlich uncool, dass mir da angezeigt wird, dass irgendwas geändert wurde, aber nix geändert wurde.

naja, im Prinzip sind die Ordner ja eh schon manipuliert... war ja bei der DS116 auch schon. Aber mein innerer Monk besteht zumindest auf die falschen Änderungszeiten die schon auf der DS116 waren, und nicht noch mal anderen.

 

[patrickn]

So, alles wieder, wie es auf der DS116 war. Bis auf ein paar hartnäckige @eaDir-Ordner, aber die Zeiten stimmen trotzdem, obwohl der Ordner selbst das Datum von heute hat, die Daten darin komischerweise Jahre alt... Und nunja.. abgesehen von 120GB weniger Speicher, dank Snapshots.

Den Befehl oben hab ich auch noch mal laufen lassen, diese @eaDir sind echt überall, selbst in jedem Snapshot

 

[Anony.Mous]

Hallo ,

kann das Anlegen der @eaDir-Ordner eigentlich verhindert werden?

 

[patrickn]

Ich fürchte nicht.

Aber am Wochenende hat mir das Mistding wieder sämtliche Ordnerzeiten manipuliert, dieses Mal ohne Universal Search. Ein "browsen" in den Ordnern mit DS File hat gereicht.
Mal schauen was der Support sagt.





Also entweder gab es dieses unsägliche Verhalten unter DSM6.2 nicht, oder es ist mir nie aufgefallen


Auch in HyperBackup ist diese Änderung nachvollziehbar:

7.9.24 - 7:30:



8.9.24 - 7:30:

 

[patrickn]

Wohl keine KI, aber zumindest automatisch übersetzt:

Lieber Patrick,

hier ist David y. von der Synology-Zentrale in Taiwan. Bitte gestatten Sie mir, Ihren Fall zu übernehmen und Ihnen weiterhin zur Seite zu stehen.
....
Best regards, Technical Support Engineer.

Kurzfassung: Ich soll doch auf DS File, oder andere Indizierungs-Möglichkeiten / Multimedia-Pakete wie Video Station ( ) und Audio Station verzichten und nur SMB/CIFS nutzen.

Ja äh ne, ich soll mir sone teure Kiste kaufen mit super Funktionen wie Video Station (lol.) und soll dann auf alles verzichten, ausser SMB/cifs

 

[patrickn]

Ich find die Antwort irgendwie traurig und erbärmlich...

Hier mal noch die Erläuterung zu den verschiedenen @eaDir-Ordnern:

There are 3 types of @eaDir:

Volume-level @eaDir​

It is located at /volumeX/@eaDir. Storage-related information (like user quota /volumeX/@eaDir/SHARE/SYNO@.quota, or key file of an encrypted share /volumeX/@eaDir/SHARE/SYNO@.encrypt) is stored here. Please do not remove these directories, or it will cause unexpected system errors.

Share-folder-level @eaDir​

It is located at /volumeX/SHARE/@eaDir. Service-related information (like file indexing DB in /volumeX/SHARE/@eaDir/SYNO@.fileindexdb) is stored here. Some services might not work correctly after you remove these directories.

File-level @eaDir​

If a file aaa is located at /volumeX/SHARE/PATH/aaa, the file-level @eaDir of aaa is located at /volumeX/SHARE/PATH/@eaDir/.


File-related information is stored here under the following circumstances:

• When MacOS device accesses a file (extended attributes are saved in @SynoEAStream1; resource fork2 saved in @SynoResource)
• When multimedia-related packages are enabled (thumbnails/metadata from Photo Station/Audio Station/Video Station/etc. are saved in @eaDir)