Weiss jemand was genau eine "Zero ID" in einem Helios UB Volume genau
bedeutet (bei einem "rebuild -s" über das Volume)?

Gibt es einen Eintrag für eine Datei in der Desktop DB aber mit dieser
"Zero ID"?
Oder gibt es zu dieser Datei gar keinen Eintrag?

Und wie kann es zu einem solchen Zustand kommen? Ich konnte das nicht
nachstellen. Egal ob ich mit "dt cp" oder nur "cp" eine Datei von
"aussen" in ein Volume kopiere, oder innerhalb des Volumes, die Ausgabe
von "dt ls -i" ergibt immer eine Desktop-File-ID >0.

--
Gruss
Emil

Emil Eschenbach schrieb am 23.07.2008 in <news:g6879q$b4g$1@svr7.m-online.net>
> Weiss jemand was genau eine "Zero ID" in einem Helios UB Volume genau
> bedeutet (bei einem "rebuild -s" über das Volume)?

Das bedeutet, daß diese Datei innerhalb eines Helios-Volumes $irgendwie
Unix-seitig angelegt wurde, diese um IDs zu sparen, mit einer zero ID
versehen wurde und bisher noch kein afpsrv-Prozeß drauf zugegriffen hat.

Macht man (jedenfalls ich) gerne, wenn man temporäre Dateien innerhalb
Helios-Volumes erstellt, die man ggf. schneller wieder löschen wird, als
irgendwer drauf zugreift. Wenn das der Fall ist, wird keine ID verbraten
(und IDs müssen ja einheitlich sein, d.h. es gibt da eine gar nicht mal
so kleine Obergrenze). D.h. "zero ID" bedeutet immer, daß noch kein
Client-seitiger Zugriff auf den umschließenden Ordner, in dem sich die
Datei befindet, stattgefunden hat.

BTW: Alle Infos zum Thema sollten sich spielend leicht per

<http://www.google.com/search?q=%22zero+id%22+site:helios.de>

finden. :-)

> Gibt es einen Eintrag für eine Datei in der Desktop DB aber mit dieser
> "Zero ID"?
> Oder gibt es zu dieser Datei gar keinen Eintrag?

Das zur Übung einfach per "dt iddump" selbst rausfinden ;-)

> Und wie kann es zu einem solchen Zustand kommen?

DT-Utilities mit "-z" benutzen.

Gruss,

Thomas

In article <slrng8frhu.9qv.Thomas.Kaiser@phg-online.de>,
Thomas Kaiser <Thomas.Kaiser@phg-online.de> wrote:

> Emil Eschenbach schrieb am 23.07.2008 in <news:g6879q$b4g$1@svr7.m-online.net>
> > Weiss jemand was genau eine "Zero ID" in einem Helios UB Volume genau
> > bedeutet (bei einem "rebuild -s" über das Volume)?
>
> Das bedeutet, daß diese Datei innerhalb eines Helios-Volumes $irgendwie
> Unix-seitig angelegt wurde, diese um IDs zu sparen, mit einer zero ID
> versehen wurde und bisher noch kein afpsrv-Prozeß drauf zugegriffen hat.
>
> Macht man (jedenfalls ich) gerne, wenn man temporäre Dateien innerhalb
> Helios-Volumes erstellt, die man ggf. schneller wieder löschen wird, als
> irgendwer drauf zugreift. Wenn das der Fall ist, wird keine ID verbraten
> (und IDs müssen ja einheitlich sein, d.h. es gibt da eine gar nicht mal
> so kleine Obergrenze). D.h. "zero ID" bedeutet immer, daß noch kein
> Client-seitiger Zugriff auf den umschließenden Ordner, in dem sich die
> Datei befindet, stattgefunden hat.
>
> BTW: Alle Infos zum Thema sollten sich spielend leicht per
>
> <http://www.google.com/search?q=%22zero+id%22+site:helios.de>
>
> finden. :-)

Pfeigrad! Wer lesen kann... :-)

> > Gibt es einen Eintrag für eine Datei in der Desktop DB aber mit dieser
> > "Zero ID"?
> > Oder gibt es zu dieser Datei gar keinen Eintrag?
>
> Das zur Übung einfach per "dt iddump" selbst rausfinden ;-)
>
> > Und wie kann es zu einem solchen Zustand kommen?
>
> DT-Utilities mit "-z" benutzen.

Danke, das hatte ich überlesen.
Wenn ich also ohne "dt" eine Datei in das Volume kopiere bekomme ich
eine "zero ID" und in einem "dt iddump" taucht sie nicht auf.

Zum Hintergrund: ich hab' hier ein Volume das von "Censhare" verwaltet
wird, "AFP UNIX-Zugriffsrechte" eingestellt und alles in dem Volume
gehört quasi dem Benutzer unter dem der Censhare-Application-Server
läuft. Nur Censhare soll schreibend auf das Volume zugreifen.
Die AFP-Benutzer haben also nur lesenden Zugriff auf das Volume. Nach
einiger Zeit habe ich in dem Volume tausende Dateien mit "Zero ID" und
nach einigen Wochen eine kaputte Desktop DB.
Ich denke in dem Fall kann ich ausschliessen, dass die fehlenden
Desktop-Einträge Absicht sind.

Sollte es nicht für jede Mac-Datei genau eine Desktop-ID geben? Ich
bekomme nämlich mit einem
dt iddump [VOLUME] | grep 01776279.pdf

das da:

7845998 7845907 01776279.pdf
7845999 7845907 01776279.pdf
7846000 7845907 01776279.pdf

....

7846061 7845907 01776279.pdf
7846062 7845907 01776279.pdf
7846063 7845907 01776279.pdf
7846064 7845907 01776279.pdf

obwohl ein rebuild -s

[VOLUME][PFAD]/01776279.pdf: zero ID

ausgibt.

dt idinfo 7846064
gibt z.B.
volume: '[VOLUME]' id=7846064 pid=7845907 name: '01776279.pdf'

Also entweder ich kapier das noch nicht oder mit dem Volume läuft was
falsch.

--
Gruss
Emil

Emil Eschenbach schrieb in <news:e.s.e-98FB00.12275324072008@news.m-online.net>
> Wenn ich also ohne "dt" eine Datei in das Volume kopiere bekomme ich
> eine "zero ID" und in einem "dt iddump" taucht sie nicht auf.

Weiß ich nicht, weil Dateimanipulation ohne "dt" eh Todsünde bzw. nur
dumm ist. Kannst Du aber doch sehr einfach ausprobieren mit einem der
Standard-Unix-Kommandos und anschl. "rebuld -s" nebst "dt iddump".

> Zum Hintergrund: ich hab' hier ein Volume das von "Censhare" verwaltet
> wird, "AFP UNIX-Zugriffsrechte" eingestellt und alles in dem Volume
> gehört quasi dem Benutzer unter dem der Censhare-Application-Server
> läuft. Nur Censhare soll schreibend auf das Volume zugreifen.

Und wie schreibt Censhare da drauf? Via AFP oder sitzt das mit auf dem
Server und ferkelt da evtl. ohne DT-Utilities drin rum?

Meine Berührungspunkte mit sowohl Coware als auch Censhare bzgl.
sauberer Interaktion mit Helios waren bisher sehr durchwachsen. Es gibt
bei Coware Leute, denen das völlig klar ist, wie's richtig zu sein hat
und es gibt andere, denen das mehr oder weniger wurscht ist (die haben
zumindest noch vor einiger Zeit das, was Helios im .rsrc-Ordner sehen
will, irgendwie von Hand gebastelt aber dabei nicht bedacht, daß das nur
die halbe Miete ist, denn der desksrv will schon auch wissen, was
innerhalb der Volumes passiert)

> Die AFP-Benutzer haben also nur lesenden Zugriff auf das Volume. Nach
> einiger Zeit habe ich in dem Volume tausende Dateien mit "Zero ID" und
> nach einigen Wochen eine kaputte Desktop DB.

Das spricht dann relativ eindeutig gegen "dt -z" und für Umgehung der
Desktop-Datenbank. Aber Details wird Dir nur Coware oder ein Blick auf
die Prozesse sagen verraten können.

> Ich denke in dem Fall kann ich ausschliessen, dass die fehlenden
> Desktop-Einträge Absicht sind.

Wie gesagt: Wenn man mit DT-Utilities arbeitet und temporäre Dateien
anlegt, dann kann man durch explizite Zuweisung einer zero-ID ggf. IDs
sparen, denn wenn die Datei wieder entsorgt wird, bevor ein afpsrv-
Prozeß drauf zugegriffen hat, dann hat's für besagte Datei nie eine ID
gebraucht.

> Sollte es nicht für jede Mac-Datei genau eine Desktop-ID geben?

Doch, klar. Ausnahme eben bewußtes Zuweisen von zero IDs.

> Ich bekomme nämlich mit einem
> dt iddump [VOLUME] | grep 01776279.pdf
>
> das da:
>
> 7845998 7845907 01776279.pdf
> 7845999 7845907 01776279.pdf
> 7846000 7845907 01776279.pdf
>
> ...
>
> 7846061 7845907 01776279.pdf
> 7846062 7845907 01776279.pdf
> 7846063 7845907 01776279.pdf
> 7846064 7845907 01776279.pdf

Schick -- 'zig Einträge mit unterschiedlichen IDs für _eine_ Datei
"01776279.pdf", die immer im gleichen Ordner (identische Parent-ID)
liegt. Da stimmt in der Tat was nicht.

> obwohl ein rebuild -s
>
> [VOLUME][PFAD]/01776279.pdf: zero ID
>
> ausgibt.
>
> dt idinfo 7846064
> gibt z.B.
> volume: '[VOLUME]' id=7846064 pid=7845907 name: '01776279.pdf'

Schau mal in den Dateiteil im .rsrc-Unterordner, was dort für ID
drinsteht. Die Format-Beschreibung steht hier:

<http://www.helios.de/support/develop/apple_res.phtml>

In den .rsrc-Ordner hineinzublicken, nachdem Du Censhare gezwungen hast,
irgendwo was anzulegen, rentiert sich in jedem Fall, um herauszufinden,
ob die DT-Utilities oder nicht im Einsatz waren.

> Also entweder ich kapier das noch nicht oder mit dem Volume läuft was
> falsch.

IMO eher Letzteres.

Gruss,

Thomas

In article <slrng8he1l.b5v.Thomas.Kaiser@phg-online.de>,
Thomas Kaiser <Thomas.Kaiser@phg-online.de> wrote:

> Emil Eschenbach schrieb in
> <news:e.s.e-98FB00.12275324072008@news.m-online.net>
> > Zum Hintergrund: ich hab' hier ein Volume das von "Censhare" verwaltet
> > wird, "AFP UNIX-Zugriffsrechte" eingestellt und alles in dem Volume
> > gehört quasi dem Benutzer unter dem der Censhare-Application-Server
> > läuft. Nur Censhare soll schreibend auf das Volume zugreifen.
>
> Und wie schreibt Censhare da drauf? Via AFP oder sitzt das mit auf dem
> Server und ferkelt da evtl. ohne DT-Utilities drin rum?

Das weiss ich nicht, aber zumindest in unserer Installation wird die
Desktop-DB definitiv nicht gepflegt.
Wobei man in Verbindung mit Censhare ja ebensogut mit einer readonly
Samba-Freigabe zurechtkäme und OPI kann man ja, wenn aktuelle
Layout-Programme am Start sind, mittlerweile ohnehin vergessen.

> > Ich bekomme nämlich mit einem
> > dt iddump [VOLUME] | grep 01776279.pdf
> >
> > das da:
> >
> > 7845998 7845907 01776279.pdf
> > 7845999 7845907 01776279.pdf
> > 7846000 7845907 01776279.pdf
> >
> > ...
> >
> > 7846061 7845907 01776279.pdf
> > 7846062 7845907 01776279.pdf
> > 7846063 7845907 01776279.pdf
> > 7846064 7845907 01776279.pdf
>
> Schick -- 'zig Einträge mit unterschiedlichen IDs für _eine_ Datei
> "01776279.pdf", die immer im gleichen Ordner (identische Parent-ID)
> liegt. Da stimmt in der Tat was nicht.

Das lässt sich unter Helios UB mit dem alten Desktop-Server (letzter
Patch-Stand vor UB+) einfach reproduzieren:
Volume mit AFP-Unix-Zugriffsrechten, mit z.B. "dt cp -z" Datei im Volume
anlegen, und dann via AFP (als Benutzer dem die Datei nicht gehört) auf
die Datei zugreifen.

An der Stelle würde mich ja interessieren ob sich das mit einem
aktuellen UB+ mit dem neuen Deskserver auch so verhält.

> Schau mal in den Dateiteil im .rsrc-Unterordner, was dort für ID
> drinsteht. Die Format-Beschreibung steht hier:
>
> <http://www.helios.de/support/develop/apple_res.phtml>
>
> In den .rsrc-Ordner hineinzublicken, nachdem Du Censhare gezwungen hast,
> irgendwo was anzulegen, rentiert sich in jedem Fall, um herauszufinden,
> ob die DT-Utilities oder nicht im Einsatz waren.

Wie bekomme ich denn praktisch die File-ID aus dem Ressource-Fork raus?
Das 20. bis 23. Byte oder wie? Das ist z.B. der Anfang eines
Ressource-Forks einer Datei bei dem ein rebuild -s "zero ID" ergibt:
od -t x1 721697.tif | more
0000000 03 68 10 93 00 00 00 00 01 02 00 00 00 00 00 00
0000020 00 00 00 00 00 00 00 00 47 34 49 68 00 00 00 00
0000040 54 49 46 46 38 42 49 4d 00 00 00 00 00 00 00 00
0000060 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
*
0001000 00 00 01 00 00 00 06 08 00 00 05 08 00 00 00 46
0001020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
*
....

--
Gruss
Emil

Emil Eschenbach schrieb am 28.07.2008 in <news:e.s.e-3F67E0.17531128072008@news.m-online.net>
> Thomas Kaiser <Thomas.Kaiser@phg-online.de> wrote:
>
>> Emil Eschenbach schrieb:
>> > Zum Hintergrund: ich hab' hier ein Volume das von "Censhare"
>> > verwaltet wird, "AFP UNIX-Zugriffsrechte" eingestellt und alles in
>> > dem Volume gehört quasi dem Benutzer unter dem der Censhare-
>> > Application-Server läuft. Nur Censhare soll schreibend auf das
>> > Volume zugreifen.
>>
>> Und wie schreibt Censhare da drauf? Via AFP oder sitzt das mit auf
>> dem Server und ferkelt da evtl. ohne DT-Utilities drin rum?
>
> Das weiss ich nicht, aber zumindest in unserer Installation wird die
> Desktop-DB definitiv nicht gepflegt.

Also sitzt CenShare mit auf dem Helios-Server bzw. andersherum.

> Wobei man in Verbindung mit Censhare ja ebensogut mit einer readonly
> Samba-Freigabe zurechtkäme und OPI kann man ja, wenn aktuelle
> Layout-Programme am Start sind, mittlerweile ohnehin vergessen.

Naja, mit InDesign kann man schon noch OPI spielen, wenn man auf paar
Dinge achtet (und so unwichtig finde ich OPI auch heute gar nicht -- das
Argument "Wir haben GBit-Ethernet, boah ey!" finde ich nicht so ziehend,
wo die halbe Branche inzwischen verteilt über verschiedene Kontinente
werkelt und Transfers via Internet selten auf 10Base2-Niveau ablaufen)
und außerdem heißt "EtherShare OPI" ja nicht umsonst inzwischen
ImageServer, weil sich damit 'ne Menge im Bereich Bildkonvertierung
zügig und meist richtig abfrühstücken läßt.

CenShare kann gut mit ImageServer -- ob das allerdings alle bei Coware
wissen, weiß ich wiederum nicht.

>> > Ich bekomme nämlich mit einem
>> > dt iddump [VOLUME] | grep 01776279.pdf
>> >
>> > das da:
>> >
>> > 7845998 7845907 01776279.pdf
>> > 7845999 7845907 01776279.pdf
>> > 7846000 7845907 01776279.pdf
>> >
>> > ...
>> >
>> > 7846061 7845907 01776279.pdf
>> > 7846062 7845907 01776279.pdf
>> > 7846063 7845907 01776279.pdf
>> > 7846064 7845907 01776279.pdf
>>
>> Schick -- 'zig Einträge mit unterschiedlichen IDs für _eine_ Datei
>> "01776279.pdf", die immer im gleichen Ordner (identische Parent-ID)
>> liegt. Da stimmt in der Tat was nicht.
>
> Das lässt sich unter Helios UB mit dem alten Desktop-Server (letzter
> Patch-Stand vor UB+) einfach reproduzieren:
> Volume mit AFP-Unix-Zugriffsrechten, mit z.B. "dt cp -z" Datei im
> Volume anlegen, und dann via AFP (als Benutzer dem die Datei nicht
> gehört) auf die Datei zugreifen.

Ernsthaft? Das geht unter Benutzung der Desktop-Utilities?!

> An der Stelle würde mich ja interessieren ob sich das mit einem
> aktuellen UB+ mit dem neuen Deskserver auch so verhält.

Kann aktuell nicht testen, da schon genügend andere Baustellen am Start.

>> Schau mal in den Dateiteil im .rsrc-Unterordner, was dort für ID
>> drinsteht. Die Format-Beschreibung steht hier:
>>
>> <http://www.helios.de/support/develop/apple_res.phtml>
>>
>> In den .rsrc-Ordner hineinzublicken, nachdem Du Censhare gezwungen
>> hast, irgendwo was anzulegen, rentiert sich in jedem Fall, um
>> herauszufinden, ob die DT-Utilities oder nicht im Einsatz waren.
>
> Wie bekomme ich denn praktisch die File-ID aus dem Ressource-Fork
> raus? Das 20. bis 23. Byte oder wie?

Datei mit zero ID anlegen, per od/iddump gucken, mit AFP-Client drauf
zugreifen, abermals per od/iddump gucken ;-)

Gruss,

Thomas

> Wie bekomme ich denn praktisch die File-ID aus dem Ressource-Fork raus?

Hm. `HELIOSDIR/bin/dt ls -i <datei>` ?
Aber `od ...` macht natürlich auch Spaß.

Gruß
-SF

franklahm@googlemail.com schrieb in <news:d929f7ed-0b27-4e96-8d47-5fdd9b434a40@8g2000hse.googlegroups.com>
> [Emil Eschenbach wrote:]
>> Wie bekomme ich denn praktisch die File-ID aus dem Ressource-Fork
>> raus?
>
> Hm. `HELIOSDIR/bin/dt ls -i <datei>` ?

Aber das spuckt doch laut Helios-Doku nur den "Inode" aus! ;-)

Im Ernst: Da ich nicht wußte, ob sich das der Informationen im
..rsrc-Ordner bedient oder innerhalb der DesktopDB (oder aufgrund
irgendwelcher Algorithmen mal hier, mal dort), hab ich mal nix zu
geschrieben. Der Blick direkt in die .rsrc-Datei erschien mir sicherer.

Gruss,

Thomas

On 29 Jul., 15:11, Thomas Kaiser <Thomas.Kai...@phg-online.de> wrote:
> frankl...@googlemail.com schrieb in <news:d929f7ed-0b27-4e96-8d47-5fdd9b434a40@8g2000hse.googlegroups.com>
>
> > [Emil Eschenbach wrote:]
> >> Wie bekomme ich denn praktisch die File-ID aus dem Ressource-Fork
> >> raus?
>
> > Hm. `HELIOSDIR/bin/dt ls -i <datei>` ?
>
> Aber das spuckt doch laut Helios-Doku nur den "Inode" aus! ;-)

Yikes! Die Hitze: ich meint `dt ls -e i <datei>`.

> Im Ernst: Da ich nicht wußte, ob sich das der Informationen im
> .rsrc-Ordner bedient oder innerhalb der DesktopDB (oder aufgrund
> irgendwelcher Algorithmen mal hier, mal dort), hab ich mal nix zu
> geschrieben. Der Blick direkt in die .rsrc-Datei erschien mir sicherer.

Siehe Helios Base Handbuch:
dt ls -e i schaut in .rsrc/<datei>
dt iddump in die Datenbank

Gruß,
-SF

In article
<0e2656eb-d049-4c72-ae53-8d13bf5c6619@8g2000hse.googlegroups.com>,
franklahm@googlemail.com wrote:

> Siehe Helios Base Handbuch:
> dt ls -e i schaut in .rsrc/<datei>
> dt iddump in die Datenbank

Danke. Das kannte ich noch nicht. Damit sieht das so aus (Volume mit AFP
Unix-Zugriffsrechten):

# dt iddump /export/home/demovol
774 2 test.txt
776 2 .DS_Store
631 2 Network Trash Folder
# rebuild -s /export/home/demovol
# dt cp -z test.txt test2.txt
# rebuild -s /export/home/demovol
/export/home/demovol/test2.txt: zero ID
# dt iddump /export/home/demovol
774 2 test.txt
776 2 .DS_Store
631 2 Network Trash Folder

Jetzt ein AFP-Zugriff auf die Datei...

# rebuild -s /export/home/demovol
/export/home/demovol/test2.txt: zero ID
# dt iddump /export/home/demovol
774 2 test.txt
776 2 .DS_Store
777 2 test2.txt
778 2 test2.txt
779 2 test2.txt
780 2 test2.txt
781 2 test2.txt
782 2 test2.txt
783 2 test2.txt
784 2 test2.txt
785 2 test2.txt
786 2 test2.txt
787 2 test2.txt
788 2 test2.txt
789 2 test2.txt
790 2 test2.txt
791 2 test2.txt
792 2 test2.txt
793 2 test2.txt
794 2 test2.txt
795 2 test2.txt
796 2 test2.txt
797 2 test2.txt
798 2 test2.txt
799 2 test2.txt
800 2 test2.txt
801 2 test2.txt
802 2 test2.txt
803 2 test2.txt
804 2 test2.txt
805 2 test2.txt
806 2 test2.txt
807 2 test2.txt
808 2 test2.txt
809 2 test2.txt
810 2 test2.txt
811 2 test2.txt
812 2 test2.txt
813 2 test2.txt
814 2 test2.txt
815 2 test2.txt
816 2 test2.txt
817 2 test2.txt
818 2 test2.txt
819 2 test2.txt
820 2 test2.txt
821 2 test2.txt
822 2 test2.txt
823 2 test2.txt
824 2 test2.txt
825 2 test2.txt
826 2 test2.txt
827 2 test2.txt
631 2 Network Trash Folder
# dt ls -e i test2.txt
0 test2.txt

# ls -l test.txt
-rw-r--r-- 1 root root 5 Jul 25 18:06 test.txt
# ls -l .rsrc/test2.txt
-rw-r--r-- 1 root root 64 Jul 29 20:42 .rsrc/test2.txt

Hier hab' ich via AFP ein paar Mal auf die Datei zugegriffen und
anschliessend nach den File-IDs gesehen:

# dt iddump /export/home/demovol | grep test2.txt | wc -l
126
# dt iddump /export/home/demovol | grep test2.txt | wc -l
207
# dt iddump /export/home/demovol | grep test2.txt | wc -l
292

Was passiert eigentlich wenn einem Volume die File-IDs ausgehen? Ist
dann die Desktop-DB kaputt?
Wenn die File-ID ein 32Bit Integer ist sind das wohl nur ca. 4294967295.
Und mit der Methode oben hab' ich die wohl recht schnell beieinander...

--
Gruss
Emil