Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > de.alt.folklore.computer > #39021 > unrolled thread

VMS X86

Back to article view | Back to de.alt.folklore.computer

Contents

  VMS X86 Wilhelm Greiner <wilhelm.greiner@web.de> - 2023-04-14 09:09 +0200
    Re: VMS X86 "cuby....@googlemail.com" <cuby.engel@googlemail.com> - 2023-04-14 03:18 -0700
    Re: VMS X86 Manfred Haertel <Manfred.Haertel@rz-online.de> - 2023-04-14 16:36 +0200
      Re: VMS X86 Dennis Grevenstein <dennis.grevenstein@gmail.com> - 2023-04-14 20:54 +0000
        Re: VMS X86 Kay Martinen <usenet@martinen.de> - 2023-04-14 23:46 +0200
          Re: VMS X86 Dennis Grevenstein <dennis.grevenstein@gmail.com> - 2023-04-14 23:40 +0000
            Re: VMS X86 poc@pocnet.net - 2023-04-15 01:43 +0000
              Re: VMS X86 Dennis Grevenstein <dennis.grevenstein@gmail.com> - 2023-04-15 13:35 +0000
                Re: VMS X86 poc@pocnet.net - 2023-04-15 16:06 +0000
                  Re: VMS X86 Dennis Grevenstein <dennis.grevenstein@gmail.com> - 2023-04-16 17:33 +0000
            Re: VMS X86 Alexander Schreiber <als@usenet.thangorodrim.de> - 2023-04-15 13:22 +0200
              Re: VMS X86 Dennis Grevenstein <dennis.grevenstein@gmail.com> - 2023-04-15 13:29 +0000
                Re: VMS X86 poc@pocnet.net - 2023-04-15 16:13 +0000
          Re: VMS X86 poc@pocnet.net - 2023-04-15 01:36 +0000
            Re: VMS X86 Clemens Schüller <cs.usenet@mailbox.org> - 2023-04-15 08:32 +0200
              Re: VMS X86 Eric Bruecklmeier <u@5i7.de> - 2023-04-15 11:29 +0200
            Re: VMS X86 Alexander Schreiber <als@usenet.thangorodrim.de> - 2023-04-15 13:34 +0200
              Re: VMS X86 poc@pocnet.net - 2023-04-15 16:11 +0000
              Re: VMS X86 Hanno Foest <hurga-news2@tigress.com> - 2023-04-16 00:57 +0200
                Re: VMS X86 Alexander Schreiber <als@usenet.thangorodrim.de> - 2023-04-16 16:00 +0200
            Re: VMS X86 Dennis Grevenstein <dennis.grevenstein@gmail.com> - 2023-04-15 13:50 +0000
              Re: VMS X86 Gerald E¡scher <Spamer@fahr-zur-Hoelle.org> - 2023-04-15 16:42 +0000
                Re: VMS X86 Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2023-04-15 18:51 +0200
                  Re: VMS X86 Stefan Möding <Apr2023.5.kill-9@spamgourmet.com> - 2023-04-15 20:03 +0200
                    Re: VMS X86 Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2023-04-15 20:12 +0200
                      Re: VMS X86 "Michael Kraemer @ home" <M.Kraemer@gsi.de> - 2023-04-15 20:18 +0200
                        Re: VMS X86 Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2023-04-15 20:22 +0200
                          Re: VMS X86 Enrik Berkhan <Enrik.Berkhan@inka.de> - 2023-04-15 20:12 +0000
                          Re: VMS X86 Alexander Schreiber <als@usenet.thangorodrim.de> - 2023-04-16 17:48 +0200
                      Re: VMS X86 Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2023-04-15 20:35 +0200
                      Re: VMS X86 Kay Martinen <usenet@martinen.de> - 2023-04-16 16:00 +0200
                        Re: VMS X86 Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2023-04-16 16:29 +0200
                          Re: VMS X86 Kay Martinen <usenet@martinen.de> - 2023-04-16 18:36 +0200
                            Re: VMS X86 Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2023-04-16 19:13 +0200
                              Re: VMS X86 Kay Martinen <usenet@martinen.de> - 2023-04-16 21:08 +0200
                                Re: VMS X86 Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2023-04-16 21:24 +0200
                                  Re: VMS X86 Kay Martinen <usenet@martinen.de> - 2023-04-16 21:54 +0200
                                    Re: VMS X86 Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2023-04-16 22:03 +0200
                                      Re: VMS X86 Kay Martinen <usenet@martinen.de> - 2023-04-16 22:57 +0200
                                        Re: VMS X86 Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2023-04-17 11:45 +0200
                        Re: VMS X86 Stefan Möding <Apr2023.5.kill-9@spamgourmet.com> - 2023-04-16 18:45 +0200
          Re: VMS X86 Alexander Schreiber <als@usenet.thangorodrim.de> - 2023-04-15 12:53 +0200
            Re: VMS X86 Kay Martinen <usenet@martinen.de> - 2023-04-15 17:52 +0200
              Re: VMS X86 Diedrich Ehlerding <diedrich.ehlerding@t-online.de> - 2023-04-15 20:39 +0200
                Re: VMS X86 Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2023-04-15 21:09 +0200
                Re: VMS X86 Alexander Schreiber <als@usenet.thangorodrim.de> - 2023-04-16 15:58 +0200
              Re: VMS X86 Alexander Schreiber <als@usenet.thangorodrim.de> - 2023-04-16 15:56 +0200
          Re: VMS X86 "Michael Kraemer @ home" <M.Kraemer@gsi.de> - 2023-04-15 18:46 +0200
            Re: VMS X86 Dennis Grevenstein <dennis.grevenstein@gmail.com> - 2023-04-15 17:41 +0000
              Re: VMS X86 Alexander Schreiber <als@usenet.thangorodrim.de> - 2023-04-16 17:52 +0200
                Re: VMS X86 Kay Martinen <usenet@martinen.de> - 2023-04-16 18:57 +0200
                  Re: VMS X86 Dennis Grevenstein <dennis.grevenstein@gmail.com> - 2023-04-16 17:21 +0000
                    Physik? (was VMS X86) Kay Martinen <usenet@martinen.de> - 2023-04-16 21:20 +0200
                      Re: Physik? (was VMS X86) Hermann Riemann <nospam.ng@hermann-riemann.de> - 2023-04-17 08:12 +0200

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#39057

poc@pocnet.net wrote:
> 
> Das iszt definitiv der Fall. Der Itanium als Heilsbringer hat sich ja schon
> recht bald als Totgeburt rausgestellt.
 
20 Jahre Lebenszeit und durchaus brauchbare Hardware wuerde ich nicht
unbedingt als Totgeburt bezeichnen. Ob es eine kluge Plattformwahl
war, ist ja nochmal eine ganz andere Frage. Uberleg Dir nur mal zum
Vergleich, dass die erste VAX 1979 rauskam und 15 Jahre spaeter war
VAX als Plattform so veraltet, dass nur noch die Verzweifelten neue
VAXen gekauft haben. Daran gemessen war Itanium gar nicht so schlecht.
Man haette halt vor 10 Jahren eine Nachfolgeplattform fuer VMS announcen
und entwickeln sollen.

gruss,
Dennis

-- 
"I've seen things you people wouldn't believe. Attack ships on fire off the
shoulder of Orion. I watched C-beams glitter in the dark near the Tannhaeuser
gate. All those moments will be lost in time, like tears in rain."

[toc] | [prev] | [next] | [standalone]

#39064

Dennis Grevenstein schrieb am 15/4/2023 15:50:

> Man haette halt vor 10 Jahren eine Nachfolgeplattform fuer VMS announcen
> und entwickeln sollen.

Blöderweise hat sich Micro$oft anfang der 90er den Chef-Entwickler samt
Mannschaft gekrallt, die dann VMS zur eNTe gemacht haben.
Vor 10 Jahren war DEC längst im Besitz von HP. Ich meine nicht, dass die
noch großes Interesse an VMS hatten.

-- 
Gerald

[toc] | [prev] | [next] | [standalone]

#39066

On 4/15/23 18:42, Gerald E¡scher wrote:
> Dennis Grevenstein schrieb am 15/4/2023 15:50:
> 
>> Man haette halt vor 10 Jahren eine Nachfolgeplattform fuer VMS announcen
>> und entwickeln sollen.
> 
> Blöderweise hat sich Micro$oft anfang der 90er den Chef-Entwickler samt
> Mannschaft gekrallt, die dann VMS zur eNTe gemacht haben.

Und der hat ein paar sehr merkwürdige Dinger implementiert. Wie z.B. das 
man unter Windows eine in Benutzung befindliche Datei nicht löschen oder 
überschreiben kann. Was im täglichen Betrieb Ärger macht und 
Systemupdates unnötig kompliziert.

  Gerrit

[toc] | [prev] | [next] | [standalone]

#39069

Gerrit Heitsch <gerrit@laosinh.s.bawue.de> writes:

> Und der hat ein paar sehr merkwürdige Dinger implementiert. Wie z.B. das man
> unter Windows eine in Benutzung befindliche Datei nicht löschen oder
> überschreiben kann. Was im täglichen Betrieb Ärger macht und Systemupdates
> unnötig kompliziert.

ja, weil man beim Filesystem unbedingt rückwärtskompatibel bleiben
musste...  VMS hat da ja eine schöne Versionierung der Files, womit
problemlos eine Kopie angelegt werden konnte und die alte Version
weiterhin existiert.

Unter Unix kann man eine (geöffnete) Datei löschen und der Plattenplatz
wird nicht freigegeben.  Das versteht auch nicht jeder.

-- 
Stefan

[toc] | [prev] | [next] | [standalone]

#39070

On 4/15/23 20:03, Stefan Möding wrote:
> Gerrit Heitsch <gerrit@laosinh.s.bawue.de> writes:
> 
>> Und der hat ein paar sehr merkwürdige Dinger implementiert. Wie z.B. das man
>> unter Windows eine in Benutzung befindliche Datei nicht löschen oder
>> überschreiben kann. Was im täglichen Betrieb Ärger macht und Systemupdates
>> unnötig kompliziert.
> 
> ja, weil man beim Filesystem unbedingt rückwärtskompatibel bleiben
> musste...  VMS hat da ja eine schöne Versionierung der Files, womit
> problemlos eine Kopie angelegt werden konnte und die alte Version
> weiterhin existiert.
> 
> Unter Unix kann man eine (geöffnete) Datei löschen und der Plattenplatz
> wird nicht freigegeben.  Das versteht auch nicht jeder.

Für mich eigentlich klar... Wer sie offen hat, der kann sie noch 
lesen/schreiben. Für alle anderen ist sie weg.

Oder überschreiben. Wer die alte Datei offen hat bekommt den alten 
Inhalt. Sie verschwindet erst dann, wenn der letzte Benutzer sie 
freigegeben hat. Wer sie nicht offen hatte bekommt den neuen Inhalt.


  Gerrit

[toc] | [prev] | [next] | [standalone]

#39071

Gerrit Heitsch wrote:
> On 4/15/23 20:03, Stefan Möding wrote:
>>
>> Unter Unix kann man eine (geöffnete) Datei löschen und der Plattenplatz
>> wird nicht freigegeben.  Das versteht auch nicht jeder.
> 
> 
> Für mich eigentlich klar... Wer sie offen hat, der kann sie noch 
> lesen/schreiben. Für alle anderen ist sie weg.
> 
> Oder überschreiben. Wer die alte Datei offen hat bekommt den alten 
> Inhalt. Sie verschwindet erst dann, wenn der letzte Benutzer sie 
> freigegeben hat. Wer sie nicht offen hatte bekommt den neuen Inhalt.
> 

Der Einwand geht wohl eher dahin, dass man etwas loescht
und trotzdem nicht mehr Platz hat.
Versteh ich auch nicht immer auf Anhieb.

[toc] | [prev] | [next] | [standalone]

#39072

On 4/15/23 20:18, Michael Kraemer @ home wrote:
> Gerrit Heitsch wrote:
>> On 4/15/23 20:03, Stefan Möding wrote:
>>>
>>> Unter Unix kann man eine (geöffnete) Datei löschen und der Plattenplatz
>>> wird nicht freigegeben.  Das versteht auch nicht jeder.
>>
>>
>> Für mich eigentlich klar... Wer sie offen hat, der kann sie noch 
>> lesen/schreiben. Für alle anderen ist sie weg.
>>
>> Oder überschreiben. Wer die alte Datei offen hat bekommt den alten 
>> Inhalt. Sie verschwindet erst dann, wenn der letzte Benutzer sie 
>> freigegeben hat. Wer sie nicht offen hatte bekommt den neuen Inhalt.
>>
> 
> Der Einwand geht wohl eher dahin, dass man etwas loescht
> und trotzdem nicht mehr Platz hat.
> Versteh ich auch nicht immer auf Anhieb.

Ist doch simpel. Den Platz hat noch jemand in Benutzung. Finde raus wer 
das ist, und schon ist das Problem gelöst.

Das geht aber noch besser. Stell dir vor ein Prozess öffnet ein Logfile 
und löscht es sofort. Dann kann er dir die Platte mit dem Output füllen 
ohne das du die fragliche Datei finden kannst.

  Gerrit

[toc] | [prev] | [next] | [standalone]

#39077

Gerrit Heitsch <gerrit@laosinh.s.bawue.de> wrote:
> Ist doch simpel. Den Platz hat noch jemand in Benutzung. Finde raus wer 
> das ist, und schon ist das Problem gelöst.

Noch simpler: unter Unix löscht man keine Dateien, sondern deren Namen.

Wenn alle Namen weg sind, kann man die Datei nicht mehr öffnen, aber
durchaus noch offen haben.

Wenn alle Namen weg sind und kein Prozess die Datei mehr offen hat, ist
sie weg.

(Es gibt so modernes Zeugs wie /proc/<pid>/fd/ unter Linux etc., das
wiederum für jede offene Datei einen Namen erzeugt, geht aber trotzdem
...)

Gruß,
Enrik

[toc] | [prev] | [next] | [standalone]

#39093

Gerrit Heitsch <gerrit@laosinh.s.bawue.de> wrote:
> On 4/15/23 20:18, Michael Kraemer @ home wrote:
>> Gerrit Heitsch wrote:
>>> On 4/15/23 20:03, Stefan Möding wrote:
>>>>
>>>> Unter Unix kann man eine (geöffnete) Datei löschen und der Plattenplatz
>>>> wird nicht freigegeben.  Das versteht auch nicht jeder.
>>>
>>>
>>> Für mich eigentlich klar... Wer sie offen hat, der kann sie noch 
>>> lesen/schreiben. Für alle anderen ist sie weg.
>>>
>>> Oder überschreiben. Wer die alte Datei offen hat bekommt den alten 
>>> Inhalt. Sie verschwindet erst dann, wenn der letzte Benutzer sie 
>>> freigegeben hat. Wer sie nicht offen hatte bekommt den neuen Inhalt.
>>>
>> 
>> Der Einwand geht wohl eher dahin, dass man etwas loescht
>> und trotzdem nicht mehr Platz hat.
>> Versteh ich auch nicht immer auf Anhieb.
>
> Ist doch simpel. Den Platz hat noch jemand in Benutzung. Finde raus wer 
> das ist, und schon ist das Problem gelöst.
>
> Das geht aber noch besser. Stell dir vor ein Prozess öffnet ein Logfile 
> und löscht es sofort. Dann kann er dir die Platte mit dem Output füllen 
> ohne das du die fragliche Datei finden kannst.

Dafür gibt es 'lsof|grep -i deleted' und /proc/${pid}/fd/ unter Linux.

Und "finde den mysteriösen Platzfüller" mit "gelöschte aber noch offene
Datei in die fröhlich weiter geschrieben wird" als Grund habe ich schon
als Interviewfrage für Sysadmins gesehen.

Man liest sich,
            Alex.
-- 
"Opportunity is missed by most people because it is dressed in overalls and
 looks like work."                                      -- Thomas A. Edison

[toc] | [prev] | [next] | [standalone]

#39074

On 4/15/23 20:27, Stefan Ram wrote:
> Gerrit Heitsch <gerrit@laosinh.s.bawue.de> writes:
>> Für mich eigentlich klar... Wer sie offen hat, der kann sie noch
>> lesen/schreiben. Für alle anderen ist sie weg.
> 
>    Unter UNIX entfernt "rm" WIMRE nur Einträge in Verzeichnissen, aber
>    keine Dateien. Eine Datei wird entfernt, wenn es keine Verweise
>    mehr auf sie gibt. Solche Verweise können Verzeichniseinträge
>    sein, aber auch Prozesse, welche sie in Benutzung haben.
> 
>    Für Windows gibt es Zusatzprogramme, die es erlauben, Dateien
>    zu entsperren, so daß man sie dann löschen kann, selbst wenn
>    Prozesse sie noch in Verwendung haben.

Mag sein, gehören aber nicht zum Lieferumfang und sind deshalb mit 
Vorsicht zu geniessen. Die Prozesse, denen man die Datei unter dem 
Hintern wegzieht könnten das übelnehmen.

  Gerrit

[toc] | [prev] | [next] | [standalone]

#39086

Am 15.04.23 um 20:12 schrieb Gerrit Heitsch:
> On 4/15/23 20:03, Stefan Möding wrote:
>> Gerrit Heitsch <gerrit@laosinh.s.bawue.de> writes:
>>
>>> Und der hat ein paar sehr merkwürdige Dinger implementiert. Wie z.B. das man
>>> unter Windows eine in Benutzung befindliche Datei nicht löschen oder
>>> überschreiben kann. Was im täglichen Betrieb Ärger macht und Systemupdates
>>> unnötig kompliziert.

Weil das OS die binärdateien aus denen es selbst besteht offen hält 
nachdem diese ins RAM kopiert wurden (zwecks ausführung)?

Mir ist als hätte ich bei W2k bei der Systemdateireparatur etwas 
ähnliches gelesen.

>> ja, weil man beim Filesystem unbedingt rückwärtskompatibel bleiben
>> musste...  VMS hat da ja eine schöne Versionierung der Files, womit
>> problemlos eine Kopie angelegt werden konnte und die alte Version
>> weiterhin existiert.

Und wie machte man das merging oder synchronisierung zwischen altem und 
neuem inhalt?

>> Unter Unix kann man eine (geöffnete) Datei löschen und der Plattenplatz
>> wird nicht freigegeben.  Das versteht auch nicht jeder.

DEV Papierkorb?

> Für mich eigentlich klar... Wer sie offen hat, der kann sie noch
> lesen/schreiben. Für alle anderen ist sie weg.

Und wenn der sie offen haltende sie dann beschrieben hat und 
anschließend schließt, der hat dann mit zitronen gehandelt weil die neue 
information dann gleich im bitmülleimer landet? Oder wird die alte datei 
nach dem beschreiben und schließen dann wieder (magisch) auftauchen?

> Oder überschreiben. Wer die alte Datei offen hat bekommt den alten
> Inhalt. Sie verschwindet erst dann, wenn der letzte Benutzer sie
> freigegeben hat. Wer sie nicht offen hatte bekommt den neuen Inhalt.

User A öffnet datei1 und liest inhaltA
User B löscht datei1
User C öffnet datei1 und schreibt InhaltB
User A schreibt InhaltC in datei1 und schließt sie.
Welchen Inhalt sieht jetzt User C?
Und was sieht User B wenn er kontrolliert ob datei1 wirklich gelöscht wurde?

Ist so was nicht essentielles Datei-/Bereichs-locking und sollte solche 
fälle verhindern? In JEDEM OS das mehr als Single-User/Single-Task kann.

Als ich meine Mailbox auf LAN umrüstete ist mir das anfangs ein paar mal 
auf die füße gefallen da ich 'share' nicht geladen hatte. So konnte ich 
eine Batchdatei auf dem Server im Editor offen haben, sie von einem DOS 
client aus ebenfalls modifizieren, aber je nach dem welchen ich zuerst 
mit speichern beendete unterschied sich der inhalt - wenn er überhaupt 
noch lesbar war. Da Änderungen auch mal im laufenden Betrieb gemacht 
wurden hat das gleich mehr als nur einen mailertask abgeschossen weil 
sie alle über einen batch (nur mit LINE=x unterschieden) starteten.
Ja, man hätte für jeden ein kill- oder restart-semaphore hin werfen 
können wenn man fertig ist aber da mußte man auch dran denken.


Ｂｙｅ／
    ／Ｋａｙ

-- 
"Kann ein Wurstbrot die Welt retten?" :-)

[toc] | [prev] | [next] | [standalone]

#39087

On 4/16/23 16:00, Kay Martinen wrote:
> Am 15.04.23 um 20:12 schrieb Gerrit Heitsch:
>> On 4/15/23 20:03, Stefan Möding wrote:
>>> Gerrit Heitsch <gerrit@laosinh.s.bawue.de> writes:
>>>
>>>> Und der hat ein paar sehr merkwürdige Dinger implementiert. Wie z.B. 
>>>> das man
>>>> unter Windows eine in Benutzung befindliche Datei nicht löschen oder
>>>> überschreiben kann. Was im täglichen Betrieb Ärger macht und 
>>>> Systemupdates
>>>> unnötig kompliziert.
> 
> Weil das OS die binärdateien aus denen es selbst besteht offen hält 
> nachdem diese ins RAM kopiert wurden (zwecks ausführung)?
> 
> Mir ist als hätte ich bei W2k bei der Systemdateireparatur etwas 
> ähnliches gelesen.
> 
>>> ja, weil man beim Filesystem unbedingt rückwärtskompatibel bleiben
>>> musste...  VMS hat da ja eine schöne Versionierung der Files, womit
>>> problemlos eine Kopie angelegt werden konnte und die alte Version
>>> weiterhin existiert.
> 
> Und wie machte man das merging oder synchronisierung zwischen altem und 
> neuem inhalt?
> 
>>> Unter Unix kann man eine (geöffnete) Datei löschen und der Plattenplatz
>>> wird nicht freigegeben.  Das versteht auch nicht jeder.
> 
> DEV Papierkorb?
> 
>> Für mich eigentlich klar... Wer sie offen hat, der kann sie noch
>> lesen/schreiben. Für alle anderen ist sie weg.
> 
> Und wenn der sie offen haltende sie dann beschrieben hat und 
> anschließend schließt, der hat dann mit zitronen gehandelt weil die neue 
> information dann gleich im bitmülleimer landet? Oder wird die alte datei 
> nach dem beschreiben und schließen dann wieder (magisch) auftauchen?

Nein, die ist und bleibt weg.


>> Oder überschreiben. Wer die alte Datei offen hat bekommt den alten
>> Inhalt. Sie verschwindet erst dann, wenn der letzte Benutzer sie
>> freigegeben hat. Wer sie nicht offen hatte bekommt den neuen Inhalt.
> 
> User A öffnet datei1 und liest inhaltA
> User B löscht datei1
> User C öffnet datei1 und schreibt InhaltB
> User A schreibt InhaltC in datei1 und schließt sie.
> Welchen Inhalt sieht jetzt User C?

InhaltB. Vorausgesetzt die Dateien sind jeweils offen gehalten worden. 
InhaltC ist weg.

> Und was sieht User B wenn er kontrolliert ob datei1 wirklich gelöscht 
> wurde?

Die neue Datei die von User C angelegt wurde.

Man darf nie mehrere User auf derselben Datei herumfurwerken lassen. Das 
gibt _immer_ Ärger, egal wie man es dreht. Entweder hast du Locking und 
dann vergisst User A die Datei zu schliessen während er was anderes 
macht womit User B und C nicht arbeiten können bis man User A 
kontaktiert hat ('Oh der ist heute nicht mehr im Haus...'  Macht richtig 
Spaß auf Sharepoint). Oder du hast kein Locking und dann können sich die 
User gegenseitig die Datei zerschiessen.


> Ist so was nicht essentielles Datei-/Bereichs-locking und sollte solche 
> fälle verhindern? In JEDEM OS das mehr als Single-User/Single-Task kann.

In Mutliuser-OS gibt es dafür Dateizugriffsrechte. Damit wird wirksam 
verhindert, daß man anderen Usern die Dateien zerstört. Lesen kann man 
meist, aber nicht schreiben.

  Gerrit

[toc] | [prev] | [next] | [standalone]

#39094

Am 16.04.23 um 16:29 schrieb Gerrit Heitsch:
> On 4/16/23 16:00, Kay Martinen wrote:
>> Am 15.04.23 um 20:12 schrieb Gerrit Heitsch:
>>> On 4/15/23 20:03, Stefan Möding wrote:
>>>> Gerrit Heitsch <gerrit@laosinh.s.bawue.de> writes:
>>>>
>>>>> Und der hat ein paar sehr merkwürdige Dinger implementiert. Wie z.B.
>>>>> das man
>>>>> unter Windows eine in Benutzung befindliche Datei nicht löschen oder
>>>>> überschreiben kann. 

>>>> ja, weil man beim Filesystem unbedingt rückwärtskompatibel bleiben
>>>> musste...  VMS hat da ja eine schöne Versionierung der Files, womit
>>>> problemlos eine Kopie angelegt werden konnte und die alte Version
>>>> weiterhin existiert.
>>
>> Und wie machte man das merging oder synchronisierung zwischen altem und
>> neuem inhalt?

Überhaupt nicht? Oder versionierung bei vms, bei allem anderen 
|unix|linux|eNTe| nix?

>> Und wenn der sie offen haltende sie dann beschrieben hat und
>> anschließend schließt, der hat dann mit zitronen gehandelt weil die neue
>> information dann gleich im bitmülleimer landet? Oder wird die alte datei
>> nach dem beschreiben und schließen dann wieder (magisch) auftauchen?
> 
> Nein, die ist und bleibt weg.

Das ist eingebaute Datenvernichtung. Da kann man auch gleich 
/dev/schredder zum schreiben öffnen finde ich. :-/

Wenn VMS da auf Versionierung setzt wird mir langsam klar warum das 
jemand neu haben wollte... :-)

Wobei ja speziell die eine 3-Buchstaben Organisation als 
Datenstaubsauger bekannt ist. Suck,Analyze&Compress okay, aber Delete 
wohl kaum.

>>> Oder überschreiben. Wer die alte Datei offen hat bekommt den alten
>>> Inhalt. Sie verschwindet erst dann, wenn der letzte Benutzer sie
>>> freigegeben hat. Wer sie nicht offen hatte bekommt den neuen Inhalt.
>>
>> User A öffnet datei1 und liest inhaltA
>> User B löscht datei1
>> User C öffnet datei1 und schreibt InhaltB
>> User A schreibt InhaltC in datei1 und schließt sie.
>> Welchen Inhalt sieht jetzt User C?
> 
> InhaltB. Vorausgesetzt die Dateien sind jeweils offen gehalten worden.
> InhaltC ist weg.

Ich kenne es so das RW Zugriff Vorrang hat vor RO wobei aber sicher 
jeder Editor die datei gleich RW öffnet auch wenn er sie nur einliest. 
Er "könnte" sie ja beschreiben und müßte sie sonst ggf. erneut öffnen 
wenn er es wirklich tun wollte.

Tools wie tail oder less sollten dies Problem nicht haben/verursachen 
weil sie nur auslesen. Wobei dies bei logfiles nach dem rotate auch ein 
Problem sein kann. :)

>> Und was sieht User B wenn er kontrolliert ob datei1 wirklich gelöscht
>> wurde?
> 
> Die neue Datei die von User C angelegt wurde.
> 
> Man darf nie mehrere User auf derselben Datei herumfurwerken lassen. Das
> gibt _immer_ Ärger, egal wie man es dreht. Entweder hast du Locking und
> dann vergisst User A die Datei zu schliessen während er was anderes
> macht womit User B und C nicht arbeiten können bis man User A
> kontaktiert hat ('Oh der ist heute nicht mehr im Haus...'  Macht richtig
> Spaß auf Sharepoint). Oder du hast kein Locking und dann können sich die
> User gegenseitig die Datei zerschiessen.

Wenn 'löschen einer Datei' auch ein Schreibvorgang ist dann sollte nach 
meinem Verständnis User B schon eine Ablehnende Antwort; mit verweis auf 
User A; bekommen und User C ebenfalls nicht erlaubt sein diese RW zu 
öffnen. Andernfalls müßte bei den Versuchen von User B und C der User A; 
dessen Programm; benachrichtigt werden das ihm der lesende Zugriff 
entzogen wurde. User idle, programm läuft, datei wech = Zombie oder 
kill&wech damit?

>> Ist so was nicht essentielles Datei-/Bereichs-locking und sollte solche
>> fälle verhindern? In JEDEM OS das mehr als Single-User/Single-Task kann.
> 
> In Mutliuser-OS gibt es dafür Dateizugriffsrechte. Damit wird wirksam
> verhindert, daß man anderen Usern die Dateien zerstört. Lesen kann man
> meist, aber nicht schreiben.

du meinst z.b. bei Linux -rw-rw-rw? Wobei der Eigner, Mitglieder der 
gleichen Gruppe (users z.b.) und 'alle anderen' sie ja ebenfalls RW 
öffnen könnten. Aber warum müsste dann ein 'chmod 0600' nötig sein um es 
auf -rw------ zu begrenzen? Locking sollte teil des OS sein und einen 
Zweiten aufruf der gleichen datei mit Ziel RW verhindern oder den 2. 
eben nur RO zulassen. Dann kann einer schreiben und alle anderen nur 
zusehen (RO). Problem gelöst oder?

Zugriffsrechte sind schön und gut, haben m.E. aber mit locking nix zu 
tun. Im grunde käme das locking erst NACH dem Zugriffsrecht zum Tragen.

Ｂｙｅ／
    ／Ｋａｙ

-- 
"Kann ein Wurstbrot die Welt retten?" :-)

[toc] | [prev] | [next] | [standalone]

#39097

On 4/16/23 18:36, Kay Martinen wrote:
> Am 16.04.23 um 16:29 schrieb Gerrit Heitsch:
>> On 4/16/23 16:00, Kay Martinen wrote:
>>> Am 15.04.23 um 20:12 schrieb Gerrit Heitsch:
>>>> On 4/15/23 20:03, Stefan Möding wrote:
>>>>> Gerrit Heitsch <gerrit@laosinh.s.bawue.de> writes:
>>>>>
>>>>>> Und der hat ein paar sehr merkwürdige Dinger implementiert. Wie z.B.
>>>>>> das man
>>>>>> unter Windows eine in Benutzung befindliche Datei nicht löschen oder
>>>>>> überschreiben kann. 
> 
>>>>> ja, weil man beim Filesystem unbedingt rückwärtskompatibel bleiben
>>>>> musste...  VMS hat da ja eine schöne Versionierung der Files, womit
>>>>> problemlos eine Kopie angelegt werden konnte und die alte Version
>>>>> weiterhin existiert.
>>>
>>> Und wie machte man das merging oder synchronisierung zwischen altem und
>>> neuem inhalt?
> 
> Überhaupt nicht? Oder versionierung bei vms, bei allem anderen 
> |unix|linux|eNTe| nix?
> 
>>> Und wenn der sie offen haltende sie dann beschrieben hat und
>>> anschließend schließt, der hat dann mit zitronen gehandelt weil die neue
>>> information dann gleich im bitmülleimer landet? Oder wird die alte datei
>>> nach dem beschreiben und schließen dann wieder (magisch) auftauchen?
>>
>> Nein, die ist und bleibt weg.
> 
> Das ist eingebaute Datenvernichtung. Da kann man auch gleich 
> /dev/schredder zum schreiben öffnen finde ich. :-/

Ist eben so. Der Ansatz bietet Freiheit und zur Freiheit gehört auch 
immer, daß man sich damit selbt schaden kann wenn man nicht aufpasst.


>>> Und was sieht User B wenn er kontrolliert ob datei1 wirklich gelöscht
>>> wurde?
>>
>> Die neue Datei die von User C angelegt wurde.
>>
>> Man darf nie mehrere User auf derselben Datei herumfurwerken lassen. Das
>> gibt _immer_ Ärger, egal wie man es dreht. Entweder hast du Locking und
>> dann vergisst User A die Datei zu schliessen während er was anderes
>> macht womit User B und C nicht arbeiten können bis man User A
>> kontaktiert hat ('Oh der ist heute nicht mehr im Haus...'  Macht richtig
>> Spaß auf Sharepoint). Oder du hast kein Locking und dann können sich die
>> User gegenseitig die Datei zerschiessen.
> 
> Wenn 'löschen einer Datei' auch ein Schreibvorgang ist dann sollte nach 
> meinem Verständnis User B schon eine Ablehnende Antwort; mit verweis auf 
> User A; bekommen und User C ebenfalls nicht erlaubt sein diese RW zu 
> öffnen.

Ja, und schon hast du Ärger weil dir ein User eine Datei komplett 
blocken kann. Das ist ja das Problem mit dem Locking.

  Gerrit

[toc] | [prev] | [next] | [standalone]

#39102

Am 16.04.23 um 19:13 schrieb Gerrit Heitsch:
> On 4/16/23 18:36, Kay Martinen wrote:
>> Am 16.04.23 um 16:29 schrieb Gerrit Heitsch:
>>> On 4/16/23 16:00, Kay Martinen wrote:

>>>> Und wenn der sie offen haltende sie dann beschrieben hat und
>>>> anschließend schließt, der hat dann mit zitronen gehandelt weil die neue
>>>> information dann gleich im bitmülleimer landet? 

>>> Nein, die ist und bleibt weg.
>>
>> Das ist eingebaute Datenvernichtung. Da kann man auch gleich
>> /dev/schredder zum schreiben öffnen finde ich. :-/
> 
> Ist eben so. Der Ansatz bietet Freiheit und zur Freiheit gehört auch
> immer, daß man sich damit selbt schaden kann wenn man nicht aufpasst.

Schade das 'tron' dann nicht einfach 'rm mcp' oder im 2. Teil 'rm clu' 
machen konnte oder? Scheiß Dramaturgie aber der Film wäre in 5 min. 
erledigt. Wenn nicht die Zugriffs-sperren gewesen wären. :)

Freiheit Radikal gedacht bedeutet auch sich selbst in's Knie schießen zu 
dürfen. Okay.

>>> Man darf nie mehrere User auf derselben Datei herumfurwerken lassen. Das
>>> gibt _immer_ Ärger, egal wie man es dreht. Entweder hast du Locking und
>>> dann vergisst User A die Datei zu schliessen während er was anderes
>>> macht womit User B und C nicht arbeiten können bis man User A
>>> kontaktiert hat ('Oh der ist heute nicht mehr im Haus...'  Macht richtig
>>> Spaß auf Sharepoint). Oder du hast kein Locking und dann können sich die
>>> User gegenseitig die Datei zerschiessen.
>>
>> Wenn 'löschen einer Datei' auch ein Schreibvorgang ist dann sollte nach
>> meinem Verständnis User B schon eine Ablehnende Antwort; mit verweis auf
>> User A; bekommen und User C ebenfalls nicht erlaubt sein diese RW zu
>> öffnen.
> 
> Ja, und schon hast du Ärger weil dir ein User eine Datei komplett
> blocken kann. Das ist ja das Problem mit dem Locking.

Das ist ein Layer 8 Problem. Und sollte auch dort gelöst werden. Wenn 
dazu ein "Ey, gib die Schei&§$&§ Datei endlich frei" gehört dann muß es 
eben so sein.

Ich glaube aber das Sharepoint kein gutes Beispiel sein dürfte - Schon 
weil es ein MS-Elaborat ist.

Ｂｙｅ／
    ／Ｋａｙ

-- 
"Kann ein Wurstbrot die Welt retten?" :-)

[toc] | [prev] | [next] | [standalone]

#39103

On 4/16/23 21:08, Kay Martinen wrote:
> Am 16.04.23 um 19:13 schrieb Gerrit Heitsch:
>> On 4/16/23 18:36, Kay Martinen wrote:
>>> Am 16.04.23 um 16:29 schrieb Gerrit Heitsch:
>>>> On 4/16/23 16:00, Kay Martinen wrote:
> 
>>>>> Und wenn der sie offen haltende sie dann beschrieben hat und
>>>>> anschließend schließt, der hat dann mit zitronen gehandelt weil die 
>>>>> neue
>>>>> information dann gleich im bitmülleimer landet? 
> 
>>>> Nein, die ist und bleibt weg.
>>>
>>> Das ist eingebaute Datenvernichtung. Da kann man auch gleich
>>> /dev/schredder zum schreiben öffnen finde ich. :-/
>>
>> Ist eben so. Der Ansatz bietet Freiheit und zur Freiheit gehört auch
>> immer, daß man sich damit selbt schaden kann wenn man nicht aufpasst.
> 
> Schade das 'tron' dann nicht einfach 'rm mcp' oder im 2. Teil 'rm clu' 
> machen konnte oder? Scheiß Dramaturgie aber der Film wäre in 5 min. 
> erledigt. Wenn nicht die Zugriffs-sperren gewesen wären. :)

Ist dasselbe mit anderen Filmen. Da gibt es einen der heisst 'Auf der 
Flucht' und nicht 'Geschnappt nach 5 min'.



>> Ja, und schon hast du Ärger weil dir ein User eine Datei komplett
>> blocken kann. Das ist ja das Problem mit dem Locking.
> 
> Das ist ein Layer 8 Problem. Und sollte auch dort gelöst werden. Wenn 
> dazu ein "Ey, gib die Schei&§$&§ Datei endlich frei" gehört dann muß es 
> eben so sein.

Und dann ist der fragliche User im Meeting oder gar nicht mehr im Haus.


> Ich glaube aber das Sharepoint kein gutes Beispiel sein dürfte - Schon 
> weil es ein MS-Elaborat ist.

Sharepoint will mir auch nicht gefallen.

  Gerrit

[toc] | [prev] | [next] | [standalone]

#39105

Am 16.04.23 um 21:24 schrieb Gerrit Heitsch:
> On 4/16/23 21:08, Kay Martinen wrote:
>> Am 16.04.23 um 19:13 schrieb Gerrit Heitsch:

>>> Ist eben so. Der Ansatz bietet Freiheit und zur Freiheit gehört auch
>>> immer, daß man sich damit selbt schaden kann wenn man nicht aufpasst.
>>
>> Schade das 'tron' dann nicht einfach 'rm mcp' oder im 2. Teil 'rm clu'
>> machen konnte oder? Scheiß Dramaturgie aber der Film wäre in 5 min.
>> erledigt. Wenn nicht die Zugriffs-sperren gewesen wären. :)
> 
> Ist dasselbe mit anderen Filmen. Da gibt es einen der heisst 'Auf der
> Flucht' und nicht 'Geschnappt nach 5 min'.

Dagegen haben sie bei "Demolition Man" die Musik der TV-Ads als 
Kurzmusik eingedampft. Der Film ist aber doch länger. ;)

Das "Drama" muß ja erst mal seinen Lauf gehen.

>>> Ja, und schon hast du Ärger weil dir ein User eine Datei komplett
>>> blocken kann. Das ist ja das Problem mit dem Locking.
>>
>> Das ist ein Layer 8 Problem. Und sollte auch dort gelöst werden. Wenn
>> dazu ein "Ey, gib die Schei&§$&§ Datei endlich frei" gehört dann muß es
>> eben so sein.
> 
> Und dann ist der fragliche User im Meeting oder gar nicht mehr im Haus.

Bitte an admin ein 'kill' ab zu setzen. Oder sind wir dann gleich wieder 
bei einem gnu movemail Problem? [Kuckucksei] :-)

Drama! Drama!

Ich fände es generell besser wenn mir das OS sagt da darf ich nicht ran, 
die hat jemand (x) schon auf. Denn dann kann ich nach x suchen statt 
mutwillig/zufällig daten zu zerstören.

Wo es früher nur 'finger' und 'talk' gab, oder 'mail' da gibt es heute 
doch 'messenger' jeder Art und im Business gilt doch eh 24/7 
Erreichbarkeit oder? Man könnte ja was (Börsenkurs, Feindliche 
Übernahme, Hackerangriff, whatever) verpassen...

Wenn Glück und Geschick von $Firma davon abhängen geht m.E. "daten 
bewahren" vor "Daten kaputt" und ein "logge dich aus wenn du weg gehst" 
sollte man aus div. Gründen eh jedem Mitarbeiter nahe gelegt haben.

Und $Privat reicht vermutlich schon ein Brüllen durch's Haus oder das 
Anstupsen des Partners neben sich. ;)

Ich bin ja sonst kein Freund davon Soziale Probleme auf Krampf Technisch 
lösen zu wollen. Aber hierbei sehe ich eigentlich kein Wirkliches 
Problem. Nur die üblichen o.g. Lösungswege.

Ｂｙｅ／
    ／Ｋａｙ

-- 
"Kann ein Wurstbrot die Welt retten?" :-)

[toc] | [prev] | [next] | [standalone]

#39106

> Anstupsen des Partners neben sich. ;)
> 
> Ich bin ja sonst kein Freund davon Soziale Probleme auf Krampf Technisch 
> lösen zu wollen. Aber hierbei sehe ich eigentlich kein Wirkliches 
> Problem. Nur die üblichen o.g. Lösungswege.

Ich schon, bei Updates. Während das OS läuft hast du jede Menge offene 
Dateien. Bei den meisten Updates werden einige davon überschrieben 
werden müssen, während das OS läuft und sie benutzt.

Mit Locking bekommst du dann die Probleme wie bei Windows.

  Gerrit

[toc] | [prev] | [next] | [standalone]

#39108

Am 16.04.23 um 22:03 schrieb Gerrit Heitsch:

> Ich schon, bei Updates. Während das OS läuft hast du jede Menge offene
> Dateien. Bei den meisten Updates werden einige davon überschrieben
> werden müssen, während das OS läuft und sie benutzt.

Geht es (dir?) dabei um die Vermeidung eines Reboots um updates ab zu 
schließen? Das ist ja bei Win und OS/2 übliches Verfahren, bei Linux nur 
wenn es Kernel oder dem naheliegende Komponenten betrifft. Obwohl 
Live-patching aktuell mehr diskutiert wurde, wie ich so las.

> Mit Locking bekommst du dann die Probleme wie bei Windows.

Bei Binärdateien die nur lesend geöffnet werden!

Ich dachte wir sprechen hier von Benutzerdateien eines unixoiden Systems 
und nicht von systemfiles - weil du zu VMS Versionierung erwähntest. Ein 
Benutzer wird doch wohl kaum systemdateien offen haben, Oder?

Ich nahm an das ein OS hier eine Unterscheidung vornehmen kann. Wenn 
nicht anhand der Zugriffsrechte im Dateisystem so doch zumindest anhand 
interner Strukturen wie kernel-mode, ring0 vs. ring 3 oder; als 
schlechteste aller Möglichkeiten; anhand von dateityp oder datei-endung 
(sofern verfügbar).

Kurzum habe ich angenommen das Locking für userprogresse und dateien 
möglich und implizit verwendet wird und nur bei binärdateien, 
ausführbarem davon ausnahmen gemacht würden.

Hmm. Atomare Operation, Race Conditions wenn nicht? Gehts darum und 
keine Andere Lösung?

Ｂｙｅ／
    ／Ｋａｙ

-- 
"Kann ein Wurstbrot die Welt retten?" :-)

[toc] | [prev] | [next] | [standalone]

#39119

On 4/16/23 22:57, Kay Martinen wrote:
> Am 16.04.23 um 22:03 schrieb Gerrit Heitsch:
> 
>> Ich schon, bei Updates. Während das OS läuft hast du jede Menge offene
>> Dateien. Bei den meisten Updates werden einige davon überschrieben
>> werden müssen, während das OS läuft und sie benutzt.
> 
> Geht es (dir?) dabei um die Vermeidung eines Reboots um updates ab zu 
> schließen? Das ist ja bei Win und OS/2 übliches Verfahren, bei Linux nur 
> wenn es Kernel oder dem naheliegende Komponenten betrifft. Obwohl 
> Live-patching aktuell mehr diskutiert wurde, wie ich so las.

Ja, Systemupdates sollten soweit wie möglich ohne Reboot machbar sein. 
Kernel wäre eine der Ausnahmen und auch daran wird gearbeitet wie du 
schreibst.


>> Mit Locking bekommst du dann die Probleme wie bei Windows.
> 
> Bei Binärdateien die nur lesend geöffnet werden!
> 
> Ich dachte wir sprechen hier von Benutzerdateien eines unixoiden Systems 
> und nicht von systemfiles - weil du zu VMS Versionierung erwähntest. Ein 
> Benutzer wird doch wohl kaum systemdateien offen haben, Oder?

Aber sicher doch, oder was meinst was mit den ganzen shared libraries in 
/lib und /usr/lib ist? Nimm ein beliebiges Anwendungsprogramm und schau 
mit 'ldd' nach welche Libraries benutzt werden.

  Gerrit

[toc] | [prev] | [next] | [standalone]

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

Back to top | Article view | de.alt.folklore.computer

csiph-web