🚀 go-pugleaf

In article <46ohv4$jnf@wuff.franken.de>, krydom@laddie.franken.de (Benjamin Kunz) writes:
|> Hi!
|> 
|> Ein Freund von mir aus dieser box, der kein UseNet hat, hat versehentlich
|> ein ewig langes und gutes MOD, an dem er ewig rumgebastelt hat, geloescht..
|> Kann mir bitte jemand Tips fuer ihn geben, wie er es widerherstellen kann?
|> Ich kenne mich leider ueberhaupt nicht damit aus.. 
|> Auf die Platte wurde noch nichts geschrieben..

Schicksal ... :)

Probiers mal mit DiskSalv aus dem Aminet !

-- 
 ____ 
|_||_  Ceterum Censeo MEGAHARD Esse Delendam    
| | _| HTS Sven Heithecker s.heithecker@tu-bs.de

krydom@laddie.franken.de (Benjamin Kunz) writes:

>Hi!

>Ein Freund von mir aus dieser box, der kein UseNet hat, hat versehentlich
>ein ewig langes und gutes MOD, an dem er ewig rumgebastelt hat, geloescht..
>Kann mir bitte jemand Tips fuer ihn geben, wie er es widerherstellen kann?
>Ich kenne mich leider ueberhaupt nicht damit aus.. 
>Auf die Platte wurde noch nichts geschrieben..


	undelete, disksalve,.....


	walter

-- 
-----
"Did you just see what I didn't see?"
"No."
"Neither did I!"
-----

Hi Ben,
On 26 Oct 1995, Benjamin Kunz wrote:

> Hi!
> 
> Ein Freund von mir aus dieser box, der kein UseNet hat, hat versehentlich
> ein ewig langes und gutes MOD, an dem er ewig rumgebastelt hat, geloescht..
> Kann mir bitte jemand Tips fuer ihn geben, wie er es widerherstellen kann?
> Ich kenne mich leider ueberhaupt nicht damit aus.. 
> Auf die Platte wurde noch nichts geschrieben..
> 
Dann lass Deinen Kumpel mal Disksalv ueber die Platte sausen. Wenn er
Glueck hat und auf die Platte wurde nicht (allzuviel) geschrieben, dann
kann er damit sein Mod wieder aus dem Muell ziehen.

        Tschoe
        Thom

-------------------------------------------------------------------
bye bye (c) by Thom     | Thorsten Marquardt
                        | EMail: THOM@kaupp.chemie.uni-oldenburg.de
                        | Member of the pzt project.
                        | http://kaupp.chemie.uni-oldenburg.de/pzt
-------------------------------------------------------------------

Saluton!

Benjamin Kunz (krydom@laddie.franken.de) wrote:
: Ein Freund von mir aus dieser box, der kein UseNet hat, hat versehentlich
: ein ewig langes und gutes MOD, an dem er ewig rumgebastelt hat, geloescht..
: Kann mir bitte jemand Tips fuer ihn geben, wie er es widerherstellen kann?
: Ich kenne mich leider ueberhaupt nicht damit aus.. 
: Auf die Platte wurde noch nichts geschrieben..
Bei verschiedenen Festplatten-/Disk-Utilities gibt es Undeleteprogramme bzw.
-funktionen. Disksalv habe ich in dieser Funktion selber schon benutzt.
Es gibt es als Version 3 bei Ossovski zu kaufen (der Preis wurde in der
Anzeige in der Amiga 11/95, die ich gerade dabei habe, lustigerweise
vergessen) oder als PD z.B. "ubers AmiNet in der Funktionsm"a"sig kaum
unterschiedlichen Version 2.

                              Ad Astra!
                              JuL

lerchj@sunserver1.rz.uni-duesseldorf.de / Ich bin ein Drache - Und ich wache
J"urgen ''JuL'' Lerch              / Da"s niemand lache - Wenn ich was mache

Benjamin Kunz schrieb in <46ohv4$jnf@wuff.franken.de> über "Amiga FS und
versehentlichesloeschen":

> Ein Freund von mir aus dieser box, der kein UseNet hat, hat versehentlich
> ein ewig langes und gutes MOD, an dem er ewig rumgebastelt hat, geloescht..
> Kann mir bitte jemand Tips fuer ihn geben, wie er es widerherstellen kann?
> Ich kenne mich leider ueberhaupt nicht damit aus.. Auf die Platte wurde noch
> nichts geschrieben..

Es gibt auf dem AmiNet diverse Undelete-Tools, die sowas hinkriegen koennen
muessten, einige davon sind glaube ich sogar besonders schnell, wenn der
urspruengliche Dateiname/Pfad noch bekannt sind.
HarddiskTools wie AmiBack und Quarterback koennen saemtlich solche files
widerherstellen (siehe dort im handbuch).
DiskSalv von Dave Haynie ist ebenfalls in der Lage geloeschte Dateien wieder
zu recovern und IMHO die zuverlaessigste Methode.

> cu ben

*werb an*
Dein Freund soll in Zukunft lieber FTrash benutzen ;-)
*werb aus*

Gruss,
    Fionn
--
fionn@informatik.uni-siegen.de                        IRC: Fionn@#amigager
                               PGP Key available on request
-====### legal notice ###====------------------------------------------------
Microsoft Network is prohibited from redistributing this work in any form, in
whole or in part.  License to distribute this post is available to Microsoft
for $499.  Posting without permission constitutes an agreement to these terms.

krydom@laddie.franken.de (Benjamin Kunz) schrieb am 26.10.95

> Hi!

> Ein Freund von mir aus dieser box, der kein UseNet hat, hat versehentlich
> ein ewig langes und gutes MOD, an dem er ewig rumgebastelt hat, geloescht..
> Kann mir bitte jemand Tips fuer ihn geben, wie er es widerherstellen kann?
> Ich kenne mich leider ueberhaupt nicht damit aus..
> Auf die Platte wurde noch nichts geschrieben..

Meinst du mit Amiga FS das neue AFS ???

Wenn er die Version 15.7 hat,dann kann er einfach mal:

dir :.deldir 

eingeben.Dort speichert AFS die letzten 31 Dateien die geloescht
worden sind.

Wenn er eine aeltere AFS-Version sein eigen nennt,dann hat er Pech
gehabt.Es gibt (noch) kein Tool das dann dieses File wieder
zurueckholen kann.

Bye Micha

In article <46qbvj$i94@ra.ibr.cs.tu-bs.de> y0000135@ws.rz.tu-bs.de (Sven Heithecker) writes:
>In article <46ohv4$jnf@wuff.franken.de>, krydom@laddie.franken.de (Benjamin Kunz) writes:

>|> Ein Freund von mir aus dieser box, der kein UseNet hat, hat versehentlich
>|> ein ewig langes und gutes MOD, an dem er ewig rumgebastelt hat, geloescht..
>|> Kann mir bitte jemand Tips fuer ihn geben, wie er es widerherstellen kann?
>|> Ich kenne mich leider ueberhaupt nicht damit aus.. 
>|> Auf die Platte wurde noch nichts geschrieben..
>
>Schicksal ... :)
>
>Probiers mal mit DiskSalv aus dem Aminet !

Schicksal ist`s , wenn er Disksalv die Fehlerbehebung ueberlaesst. Disksalv produziert
meiner Erfahrung nach mehr Fehler als er behebt.
ABtools scheint mir eine deutlich bessere Hilfe zu sein.

--
  << JUDAS >>  }-O_O-{  `Es wird immer DIE und DIEWO geben.`
                 \_/

Th.Huber <judas@tomtec.abg.sub.org> wrote:

> ABtools scheint mir eine deutlich bessere Hilfe zu sein.

AmiBackTools ist nur eine Alternative, wenn die Blocksize 512 byte
betraegt, bei anderen Werten gibt's nur Muell.

ciao...
--
      ______________________
     / ____________________/        LARS EILEBRECHT  -  Shadowfox@IRC
    / /     ___\ \  __            Internet: SFX@appl2.hrz.uni-siegen.de
    \ \    / __/\ \/ /   __       http://www.unix-ag.uni-siegen.de/~sfx
     \ \  / /_   \  /   /\_\         (PGP key available on request)
 ____/ / / __/   /  \   \/_/   
/_____/ / /     /_/\ \         Cyberspace: "A consensual hallucination..."
       /_/          \_\                    (William Gibson)

krydom@laddie.franken.de (Benjamin Kunz) tipperte am 26.10.1995 17:53:40 
zum Thema "Amiga FS und versehentlichesloeschen" folgendes: 
 
Hi, 
 
BK> Ein Freund von mir aus dieser box, der kein UseNet hat, hat versehentlich 
BK> ein ewig langes und gutes MOD, an dem er ewig rumgebastelt hat, geloescht.. 
BK> Kann mir bitte jemand Tips fuer ihn geben, wie er es widerherstellen kann? 
BK> Ich kenne mich leider ueberhaupt nicht damit aus..  
BK> Auf die Platte wurde noch nichts geschrieben.. 
 
In jeder gut sortierten Box sollte es in der PD-Sektion ein Proggi namens 
UnDelete oder so ähnlich sein (DiskSalve 2 ist sehr gut). Mit dem sollte es 
möglich sein, das File zurückzubekommen (vorausgesetzt es wurde nicht auf 
der Platte rumgeschrieben.) 
 
Und was lehrt uns das: 
 
PUT A COPY ON A FLOPPY ;) 
 
Ciao. 
 
\   /  :~~  :~~}  \   /  :~~   A1200 HD540MB 68030/28RTC MMU 68882 6MB 
 \_/   :~~  :~~\   \_/   :~~ 
        ~~                ~~   e-mail: Verve@M-Light.topnet.sub.de 
>Fact: The largest hailstone ever recorded was over 17 cm across an weighed 680 g.< 
 

In article <43784980.SFX@shadowbase.uni-siegen.de> "Lars Eilebrecht" <SFX@appl2.hrz.uni-siegen.de> writes:
>Th.Huber <judas@tomtec.abg.sub.org> wrote:
>
>> ABtools scheint mir eine deutlich bessere Hilfe zu sein.
>
>AmiBackTools ist nur eine Alternative, wenn die Blocksize 512 byte
>betraegt, bei anderen Werten gibt's nur Muell.

Mal abgesehen davon, dass disksalv selbst bei 512 nur mist fabriziert, ist
im allgemeinen davon auszugehen dass ein Amigauser 512 verwendet.
Nur einige controler sind in der lage n*512 zu verarbeiten, noch weniger
sind in der lage, beliebige blockgroessen handzuhaben.

--
  << JUDAS >>  }-O_O-{  `Es wird immer DIE und DIEWO geben.`
                 \_/

judas@tomtec.abg.sub.org (Th.Huber) writes:

>Nur einige controler sind in der lage n*512 zu verarbeiten, noch weniger
>sind in der lage, beliebige blockgroessen handzuhaben.

Oh, eigentlich koennen _das_ alle Controller. Die meisten koennen sogar
beliebige Sektorgroessen (was verschieden ist, von der logischen
Blockgroesse des Filesystems).

Salut,
-- 
                                Michael van Elst

Internet: mlelstv@serpens.rhein.de
                                "A potential Snark may lurk in every tree."

Th.Huber (judas@tomtec.abg.sub.org) wrote:
> Nur einige controler sind in der lage n*512 zu verarbeiten, noch weniger
> sind in der lage, beliebige blockgroessen handzuhaben.

Vielfache von 512 Bytes sollten _überhaupt_ kein Problem darstellen.
Außerdem wird eine Blocksize von über 512 Bytes sowieso in der Regel
durch Benutzung von de_SectorPerBlock statt durch de_SizeBlock>128
realisiert. Aber auch letzteres bringt keine Probleme mit sich - oder
seit wann kann solch ein Device nur Anfragen beantworten, die über
genau einen Block gehen?

Nenne doch bitte mal ein Device, das bei einer Anfrage von n*512 Bytes
Probleme macht.

--
Angela Schmidt //  email: Angela@rz.uni-karlsruhe.de   phone: +49 721 695307
  IRC: Nessy \X/   http://www.uni-karlsruhe.de/~uk8b/      or +49 731 712316 

In article <47i28d$2jk@serpens.rhein.de> mlelstv@serpens.rhein.de (Michael van Elst) writes:
>judas@tomtec.abg.sub.org (Th.Huber) writes:
>
>>Nur einige controler sind in der lage n*512 zu verarbeiten, noch weniger
>>sind in der lage, beliebige blockgroessen handzuhaben.
>
>Oh, eigentlich koennen _das_ alle Controller. Die meisten koennen sogar
>beliebige Sektorgroessen (was verschieden ist, von der logischen
>Blockgroesse des Filesystems).

Es sollten alle controler koennen, das stimmt. Mir ist selbst nicht klar,
warum es so viele nicht konnten. Ich hatte das Problem, dass das envoyfile-
system alles andere als schnell mit seeks in langen files arbeitet. Abhilfe
schafft natuerlich eine Partition mit 2048Bytes, doch dazu bedurfte es eines
romupdates.. =)

--
  << JUDAS >>  }-O_O-{  `Es wird immer DIE und DIEWO geben.`
                 \_/

In article <47kbm2$hfo@nz12.rz.uni-karlsruhe.de> uk8b@rzstud2.rz.uni-karlsruhe.de (Angela Schmidt) writes:

>Nenne doch bitte mal ein Device, das bei einer Anfrage von n*512 Bytes
>Probleme macht.

alf.device V2.14 (zugegeben version 2.14 ist unverschaemt alt)

evolution.device V2

apollo_scsi.device

Mit allen drei devices war es nicht moeglich eine 2048-byte formatierte
Platte (FFS) zu lesen. Am A3k hingegen war das ohne Probleme moeglich,
wie auch mit dem oktagon neueren datums.


Nebst controlern bringen Groessen >< 512 das Problem mit sich, dass es
kaum Tools gibt, die solche partitionen im Schadensfall wieder fixen koennen.
(ABtools funzt nicht, Disksalv ..(no comment), pd-tools ? (welche ??))
--
  << JUDAS >>  }-O_O-{  `Es wird immer DIE und DIEWO geben.`
                 \_/

Th.Huber (judas@tomtec.abg.sub.org) wrote:
>warum es so viele nicht konnten. Ich hatte das Problem, dass das envoyfile-
                                                                  ^^^^^^^^^
>system alles andere als schnell mit seeks in langen files arbeitet. Abhilfe
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Ha! Unfug! EFS ist unschuldig und macht nur, was das unterliegende
FS macht. Keine Unterstellungen!

/*------------------------------------------------------------------------*/
    Große Dateien

Wenn Sie besonders große Dateien (viele Megabytes) auf Ihrem Amiga Envoy
Server haben, können manche Operationen (wie zum Beispiel Seek) so lange
dauern, daß Envoy die Aktion abbricht. Das ist zwar nicht schön, betrifft
aber nur wirklich große Dateien. Wenn sie technisch versiert sind, können
Sie gegen dieses Problem etwas tun. Das ist bei der Verwendung von großen
Dateien sowieso eine gute Idee, da es allgemein die Zugriffsgeschwindigkeit
auch ohne Envoy oder Netzwerk steigert. Sie können mit HDToolBox Ihre
Festplatte auf dem Server neu partitionieren und dabei die Nummer der
Sektoren pro Block von 1 auf (z.B.) 4 (2KB große Sektoren) erhöhen. Dadurch
reduzieren sie Suchzeiten um etwa den Faktor 16 (1/4 soviele Blocks müssen
in Extensions abgelegt werden, und jede Extension ist vier mal größer).
/*------------------------------------------------------------------------*/


>schafft natuerlich eine Partition mit 2048Bytes, doch dazu bedurfte es eines
>romupdates.. =)

Tja, man muß eben einen vernünftigen Kontroller haben. :^)


-- 
Heinz Wrobel        Private Mail:   heinz@hwg.muc.de
My private FAX: +49 89 850 51 25, I prefer email

In article <heinz.1303@hwg.muc.de> heinz@hwg.muc.de (Heinz Wrobel) writes:
>Th.Huber (judas@tomtec.abg.sub.org) wrote:

>>warum es so viele nicht konnten. Ich hatte das Problem, dass das envoyfile-
>                                                                  ^^^^^^^^^
>>system alles andere als schnell mit seeks in langen files arbeitet. Abhilfe
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
>Ha! Unfug! EFS ist unschuldig und macht nur, was das unterliegende
>FS macht. Keine Unterstellungen!

Tja, dann frage Ich mich, warum BFS fuer envoy das gleiche Problem nicht hat,
setzt es doch ebenfalls auf dem darunterliegenden filesystem auf.

Ein Bild mittels Retinadisplay angezeigt, dauert bei EFS ca. 2min (!), waehrend
BFS schlappe 20sec benoetigt.

Ein simples file kopieren koennen beide systeme, nur wenn ein file stueckweise
gelesen wird, ist BFS eindeutig besser.


--
  << JUDAS >>  }-O_O-{  `Es wird immer DIE und DIEWO geben.`
                 \_/

Th.Huber (judas@tomtec.abg.sub.org) wrote:
>Tja, dann frage Ich mich, warum BFS fuer envoy das gleiche Problem nicht hat,
>setzt es doch ebenfalls auf dem darunterliegenden filesystem auf.
>
>Ein Bild mittels Retinadisplay angezeigt, dauert bei EFS ca. 2min (!), waehrend
>BFS schlappe 20sec benoetigt.

Tja, schick mir doch mal packet snoopdos logs (bitte mit %t im
Buffer format!) des clients und und des servers für genau diese
Aktion mit aktuellen Rechnerkonfigurationsdaten und
lib/device-Versionen. Einmal mit EFS, dann mit BFS. Dann kann ich
Dir wohl dazu mehr sagen.

Mangels Bild und Retina[display] kann ich das nicht selbst
nachvollziehen.

Für Envoy 2.0 gibt es immer noch envoy-help@iam.com und
envoy-bugs@iam.com.

Wie immer gilt:

    Man kann nur das sinnvoll ändern oder verbessern, was
    reproduzierbar ist und von dem man weiß.

>Ein simples file kopieren koennen beide systeme, nur wenn ein file stueckweise
>gelesen wird, ist BFS eindeutig besser.

EFS in Envoy 2.0 optimiert keine Seek(fh, 0, OFFSET_CURRENT)
Zugriffe. Sie werden in 2.0 auch zum Server durchgereicht, damit
man auf jeden Fall die tatsächliche Serverposition bekommt. Wenn
eine SW also z.B. ftell() kontinuierlich einsetzt weil sie zu doof
ist sich die aktuelle Position zu merken, dann wird EFS aus Envoy
2.0 "langsam". Die nächste Envoy Version wird da optimieren.

Das kann hier aber nicht das Problem sein, denn BFS optimiert
überhaupt nichts. Alles wird synchron per DoTransaction()
durchgeführt, selbst R/W-Zeug. Ohne Rücksicht auf Verluste. Noch
dazu ist BFS IMHO eine Fragmentierungsbombe. Wer das mag ...

Ich bin gespannt auf die snoopdos logs.

-- 
Heinz Wrobel        Private Mail:   heinz@hwg.muc.de
My private FAX: +49 89 850 51 25, I prefer email

Heinz Wrobel (heinz@hwg.muc.de) wrote:
>Th.Huber (judas@tomtec.abg.sub.org) wrote:
>>Ein Bild mittels Retinadisplay angezeigt, dauert bei EFS ca. 2min (!), waehrend
>>BFS schlappe 20sec benoetigt.
>
>Tja, schick mir doch mal packet snoopdos logs (bitte mit %t im
>Buffer format!) des clients und und des servers für genau diese
>Aktion mit aktuellen Rechnerkonfigurationsdaten und
>lib/device-Versionen. Einmal mit EFS, dann mit BFS. Dann kann ich
>Dir wohl dazu mehr sagen.

Ok, das ganze ist kein Problem von retinadisplay oder irgendeines
Bildes. Durch einen obskuren Fehler im EFS client verträgt sich
dieser nicht mit dem zgif.datatype. Das nächste Envoy Update wird
dieses Problem beheben. Ein Datum kann ich aber auch nicht
benennen.

Sollte jemand von weiteren Fehlern in Envoy 2.0b wissen, dann wäre
eine englische mail an envoy-bugs@iam.com sicherlich nicht die
schlechteste Idee.

-- 
Heinz Wrobel        Private Mail:   heinz@hwg.muc.de
My private FAX: +49 89 850 51 25, I prefer email