· Text 8160 · w8 · inlagg
Har testad med diskchek men det bli fortfarande kvar information på
skrivan och det går därför inte heller att radera respektive ufd
Vad kosta detta program från tdx
mvh Rainer
Retro Preservation Workspace
Monitorn
Browse archived Monitorn möten and the ABC80 mailing list, with full-text and text-number search.
basreg-850
28 posts in thread
-
-
· Text 8161 · w8 · kommentarKommer inte ihåg vad det kostade. Ca 500 skulle jag tro att de tog. Jag har råkat ut för att vissa Ufd inte går att radera på "vanligt" sätt utan måste göras med DUMP eller liknande program.
-
· Text 8162 · w8 · kommentarGlömde tillägga att det var ca 500 för deras systemskiva som innehåller en hel del andra progam också.
-
-
· Text 8169 · w8 · kommentarVad får du för felmeddelande när du försöker radera UFD:erna? Klagar den på att UFD:et inte är tomt, trots att du inte kan se några filer i det med LIB? Det skulle kunna bli fel i UFD:ets räknare för antal befintliga filer, men jag förstår inte vad som skulle orsaka det.
-
· Text 8170 · w8 · kommentarDet är mycket riktig basregister-800 som körs på 850 hårdisk Registert är eliminerd som vanligt men när man lägger upp nytt registe så står det att en del sektorer är upptagna vilket man kan få efter kopiering och då förmodar jag att avsikten är att disken sedan skall formateras om för att radera allt. I ufd som har används till basregi finns det tydligen rester kvar som inte har försvunnit för felmedelandet blir att ufdn inte är tomt och då går det ej att radera. hur göra? MVH Rainer
-
· Text 8171 · w8 · kommentarOch med LIB ser man alltså inte några filer kvar i UFD:et, är det rätt uppfattat? Om det är så, så verkar ju onekligen BASREG något undermåligt, och då lär du verkligen behöva något som tar bort UFD:et ändå. Om du kör DISKCHEK, får du då inte något meddelande om att bitmap är fel, med anledning av de där upptagna sektorerna? Om du inte får det, bör det betyda att de fortfarande ingår i någon fil, och i så fall kan friställas genom att den/de filen/filerna raderas. Jag skulle vilja rekommendera kommandot "kommentera", i stället för "inlägg" när du kommenterar tidigare texter i en diskussion. På så sätt kommer texterna att hänga ihop i en kedja, så läsaren kan följa den bakåt eller framåt i efterhand. Se vidare "hjälp komm".
-
· Text 8172 · w8 · kommentarJag har också råkat ut för att det inte går att radera UFD:en trots att dom var tomma. Har aldrig kört basreg så det beror nog inte på det programmet. Diskchek hittade inga fel. Raderade det hela genom att skriva in FF i biblioteket med dump.
-
· Text 8178 · w8 · kommentarMenar du att du skrev in FF i filnamnssektorerna? - Stog det alltså något annat där innan? Vad? Annars finns det i första sektorn en räknare för var och en av de sexton sektorerna för antalet filnamn, som skulle kunna bli fel.
-
· Text 8180 · w8 · kommentarJag kommer inte ihåg vad det stog. Det är över ett år sedan det hände sist.
-
-
-
· Text 8175 · w8 · kommentarDet var rätt uppfattad. Det hände vid uppläggning av registret vi defbas att det ramlade ur och sedan går det ej att radera ufd. Under lib (bas elle abs) finns det inga filer kvar i bibloteket men vid försök att radera det kommer felmedelandet att bibloteket ej är tomt. Så tydligen har basreg. lagt ut reservationer på sektorer som ej försvinner. Det är ju ett problem på en hårdisk för man drar sig ju att formatera den med följd att man måste instalera all programvar igen. Enligt samtal med p-data fanns ingen lösning och vid samtal mde tdx så viste ingen om någon dylig systemskiva som fixade till detta. Vem kan fixa ett program som ordnar till en hd. Mvh Rainer
-
· Text 8189 · w8 · kommentarJag har lagt in programmet UFDCHECK.BAS i inlådan. Med det kan du kolla filräknarna i ditt UFD, och eventuellt rätta till dem, om det nu är dem det är fel på. Jag bara hoppas att det fungerar, för jag hade inget trasigt UFD att testa på. Om UFDCHECK händelsevis skulle påpeka att det finns skräp bland filnamnen, föreslår jag att du inte gör någon justering, utan rapporterar här, så kan jag göra en version där man kan titta närmare på "skräpet".
-
· Text 8201 · w8 · kommentarJag körde ditt ufdcheck och fick följande felmedelanden Antal filer i ufd enligt filräknaren 0 antal filnamn med filpekare i ufd 0 Antal ej tomma filnamnspekare i ufd 0 Ufd finns på drive 4 sektor 3266 Tydligen så har basregistret lämnad kvar skräp vid radering Mvh Rainer
-
· Text 8205 · w8 · kommentarAV utsriften att döma, är UFD:et OK, och inga kvarglömda filer döljer sig någonstanns. Vad mer som skulle kunna hindra radering kan jag inte förstå.
-
· Text 8206 · w8 · kommentarDet har gått att radera ufd nu . Jag använde sd10 som är modifierad till 806 och la in ascii 255 på några ställen som det fanns andra värden Efter det gick det att radera ufd. Men fortfarande så får jag uppmaning att städa eller kopiera över registerdata till en annan skiva för ca: 3000 sektoer är tydligen låsta för något om det är gamla raderade register eller annant vet jag ej. MVH Rainer
-
· Text 8209 · w8 · kommentarKörde du XSUFD när du försöker radera UFD:et tidigare? Provade du inte vanliga UFD.BAC? Jag har kollat i UFD.ABS (som ju startas av UFD.BAC) ver 6.00, och det enda som kan få den att klaga på innehållet i det UFD som ska raderas är det som UFDCHECK kallar "Antal ej tomma filnamnsplatser", som ska vara noll, och av ditt inlägg att döma var den det. Om UFD.ABS klagar på detta formulerar den sig "Biblioteket måste vara tomt!". Utöver det, så kan det förstås inträffa fel på disken och fel i det bibliotek som UFD:et självt ligger i. (Du stod väl I det aktuella UFD:et när du körde UFDCHECK? Hm, och du måste stå i det när du ska radera det med UFD.BAC också, annars försöker du radera fader-biblioteket.) Vilka ställen la du in 255 på?
-
· Text 8210 · w8 · kommentarKan inte svara exakt var jag befann mig eller vilket ufd jag använde men försökte flera gånnger utan lyckad resultat. Jag körde dit ufdchek och fick då fram var ufd låg, på den sektor såg jag till att det blev ascii-kod 255 och efter det gick det att radera. Var det fel? Mvh Rainer
-
· Text 8212 · w8 · kommentarMen det är ju just det som UFDCHECK kollar, nämligen att bibliotekssektorerna innehåller 255:or! Och enligt ditt citat av UFDCHECK:s utskrift stod det "0" på alla uppgifter, vilket innebär att det fanns 0 platser där det INTE stod 255. Hur var det, använde du UFD.BAC eller XSUFD (dvs via Meny0)?
-
· Text 8227 · w8 · kommentarJag har varit med om ett UFD som inte har gått att radera p.g.a det har varit filer kvar i det enligt UFD.ABS. Efter det att jag tittade på den sektorn som innehöll ufd:ts namn i faderbiblioteket kom jag fram till att en av de två bytes som vanligtsvis är 0 efter filnamnet inte var 0 utan något annat. Efter det att jag hade satt byten till 0 gick det att ta bort UFD:t. Inte mycket till hjälp vid det här laget, men...
-
· Text 8243 · w8 · kommentarDet finns inga bytes i biblioteket efter filnamnet som brukar vara 0 i UFD-DOS, så jag vet inte hur du menar. Efter filnamnet kommer bara en byte 255. Före filnamnet finns start- sektor och fillängd. I LUX-NET används inte den fillängden, så där är den 0, men det finns inget som störs om den inte är noll ens i LUX-NET. Filnamnsräknarna i första sektorn på UFD:et ska däremot vara 0 för att det ska gå att ta bort, som jag sagt tidigare.
-
· Text 8250 · w8 · kommentarursäkta det var ett tag sen jag tittade på det. FÖRE filnamnet skulle det vara. m.v.h nh
-
· Text 8252 · w8 · kommentar"Före filnamnen" - Menar du då i det UFD som skulle raderas, och inte i faderbiblioteket som du skrev tidigare? I så fall är bör det vara just detsamma som UFDCHECK kollar.
-
· Text 8253 · w8 · kommentarEftersom jag inte vet vad UFDCHECK kollar, utan att jag har haft ett liknande problem en gång skrev jag som jag skrev, och jag menar fortfarande faderbiblioteket. Det enda jag vet var att de två bytesen äå var noll oavsett om det var ett UFD eller en fil.... m.v.h NH
-
· Text 8254 · w8 · kommentarJag läste ditt inlägg fel i hastigheten, och trodde att du ändrat dig även beträffande placeringen. Det JAG vet är att om de två bytearna före filnamnet är noll, så betyder det i princip att filen är 0 sektorer lång, och att ett UFD aldrig ska vara så kort. Ett UFD ska vara sammanlagt 18 sektorer. Om man sätter längden till 0 på en fil, kommer DOS:et att använda den längd som bestäms av filens RIB-sektor (den som håller reda på filens övriga sektorer), medan somliga LIB-program kommer att visa den felaktiga längden 0 på filen. Om en fil har för kort längd angiven, kommer man i från Basic inte att kunna läsa dess avslutande sektorer, men från DOS spelar det ingen roll alls, och UFD.BAC går förstås direkt via DOS:et. Skriver man in 0, på en fil med felaktig längd, kommer den att fungera även frürån Basic. Om en fil har för lång längd angiven, spelar det ingen som hellst roll, varken från Basic eller DOS. Om man skriver på skivan med andra DOS än UFD-DOS (dvs med tidigare DOS, eller med LUX-NET-DOS), kan man fillängdsangivelsen bli fel eller satt till 0. Men, som sagt, fillängdsangivelsen kollas inte av UFD.BAC (finns ingen anledning), och den påverkar inte dess åtkomst till biblio- teket heller, så den saknar helt betydelse. Detta grundar jag på praktiska prov, och på inspektion i programmet UFD.BAC, och jag känner inte till någon annan version av DIABS UFD.BAC/ABS.
-
· Text 8259 · w8 · kommentarJa det kan stämma att det kan vara fillängden , men detta var på en hd i abc-net vilket nog sätter dessa till 0.
-
· Text 8261 · w8 · kommentarJa, ett nät är en helt annan sak. Det är bra att veta vilket DOS det handlar om när man diskuterar en sån här sak.
-
· Text 8264 · w8 · kommentarJo men med tanke på att abcnet kan läsa abc-disketterna direkt så...
-
· Text 8266 · w8 · kommentarJa, jag kan inte komma på vad abcnet skulle använda fillängdsfältet till när det inte är fillängden, och inte är betydelselöst heller. Men i varje fall är abcnet så gammalt att det antagligen till en del liknar äldre "pre-UFD"-DOS. Det viktiga kan vara UFD-programmet snarare än olikheter i diskstrukturen. Vet du vad det är för version på programmet i ABC-net?
-
· Text 8268 · w8 · kommentarDet kommer jag inte ihåg... men det var före catnet & luxnet-tiden d.v.s ABC-NET var det enda som fanns då... m.v.h NH
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-