T.R | Title | User | Personal Name | Date | Lines |
---|
138.1 | Any number of things could have happened | PANGLS::BAILEY | | Fri Jun 24 1988 16:03 | 15 |
| Did you try reformating the floppy and repeating the test?
Something is messed up (obviously). Some options:
1) The RAM disk size is 283298 and you did a disk icon to disk
icon (image) copy. I think that copies the structureing info
as well.
2) The floppy got trashed in the copy operation. Loose wires,
chips?
In short, there's no closed form solution to your problem, you just
gotta horse around with some stuff.
STeph
|
138.2 | File size != disk space used | MILRAT::WALLACE | | Fri Jun 24 1988 16:46 | 47 |
| First two important basic facts:
1. TOS allocates disk space in 1024 (1k) byte chunks. Meaning that all
files use a multiple of 1k bytes of disk space.
2. The desktop (and TOS functions) always show you how many bytes
were written to the file.
There is a BIG difference (as much as 1023 bytes) between 1 and 2 above.
This is probably best described with an example:
1. Create a text file with one (1) character in it.
2. A "show info" on the file will show a size of 1.
3. The fact is the space taken up on the disk by the file is 1024
bytes. 1023 of the bytes contain undefined (garbage) data.
4. If the file would have been created with 1024 characters in it
instead of 1, it would have still used 1024 bytes of disk space.
But it's size (with show info) would show as 1024.
Another way you can run out of disk space unexpectedly is because folders
grow (in 1k byte chunks) as files are added to them. I don't recall how many
file entries will fit in 1kb. If you have a 400k ram disk, you will NOT be
able to fit 400 1kb files on it, since some space will be used up by the
folder size.
I frequently run into the same problem when adding files to out PD library.
The solution to this "problem" is to use a directory utility that displays
both the size of the file and the disk space used by it. The program should
also display the amount of disk space used by folders. I don't know of any
existing programs that do this. I'm working on one but it isn't done yet.
After reading Steph's reply I thought I'd add these numbers that are
relevant to your specific example to furhter indicate that I don't
think anything went wrong, you just tried to use more disk space than
you had.
Each of your 4104 byte files will use 5120 (5k) bytes of disk space.
Since only 69 of the 71 files would copy we'll take 69*5120 and come up
with 353280 bytes of disk space used on the floppy. I don't know
exactly how much free space is on a blank SS floppy but it must be at
least this. It would take 71*5120 or 363520 bytes of disk space to
store all 71 of your files even though the desktop would only show them
taking up 71*4104 or 291384 bytes.
Of course all of this indicates that your ram disk must have been at
least 363520 bytes in size (was it 400kb?) in order for it to hold all
71 files.
Ray
|
138.3 | Thnks, .2 was it! | FREKE::LEIGH | | Fri Jun 24 1988 17:58 | 16 |
|
RE: .2
Thanks, that fits right in line with what happened. That explains it.
There are ~356000 free bytes on a SS disk. Your numbers fit on both
sides of that. This happened after both reformatting several times and
copying small blocks of files at a time, etc. I didn't copy icon to]
icon as that tends to not work on not exactly same size disks.
BTW: ramdisk was 585K (Enough that UNITERM still runs :-) )
Thanks
Chad
|
138.4 | One slip, a Momentary Lapse of Reason | STAR::HEERMANCE | Return of the Crash Dumps from Hell | Mon Sep 19 1988 13:04 | 18 |
| Last night I did something stupid. I booted without FOLDERXXX.PRG
with the intent to use TURTLE to back up a partition. Not thinking
I moved a few files around and also did a show info on partition C.
I know it was stupid but I didn't think before I acted. Well, now
my free space on that partition is bogus by about 100K. I can not
trust that partition even though things look good on the surface.
I must now rebuild that partition. Do I need to reformat it or is
simply deleting all files safe enough? I could use TURTLE to back
that partition to floppies and then restore and sort through the
mess that is left with (hopefully) and intact FAT table.
I really wish that TURTLE didn't require the deactivation of the
FOLDERXXX program. :^(
Thanks in advance,
Martin H.
|
138.5 | Try letting DLII fix the disk | MILRAT::WALLACE | | Mon Sep 19 1988 14:26 | 24 |
| Can't say for sure but I would guess that the 40 folder bug would
not screw up any formatting information, it could just mess up fats
and directories. So deleting all the files (in that partition) should
be sufficiant.
What I would suggest first is to let DLII (a PD disk checking,
correcting, rebuilding tool) try to repair the disk for you. You may
not have to delete and restore all those files after all (no
guarantees).
1. Backup all partitions
2. Run DLII, and "CHECK" all partitions (can only do one at
a time).
3. If DLII says the partition is bad (can be bad DIRECTORIES,
bad FATS, or crossed linked SECTORS, something to this
affect) then have it do the rebuild.
Well, you realy need to read the DLII doc's and read the "screens"
as they come up, but the two points I was trying to make is "back
up the disk" and "check ALL partitions".
You can also use DLII to check out the disk and just tell you what
it thinks is wrong (ie: you don't have to have it do the fixing).
Ray
|
138.6 | Is it on-line? | PRNSYS::LOMICKAJ | Jeff Lomicka | Wed Sep 21 1988 11:46 | 2 |
| Is DLII available on this network? A "search" of 9.* for "DLII" came up empty.
|
138.7 | | STAR::HEERMANCE | Return of the Crash Dumps from Hell | Thu Sep 22 1988 10:03 | 11 |
| Jeff,
I found it one of the directories mentioned in note 9. I can't
remember which. If you want a copy write me and we can try to
copy it to your public directory.
I used it on my hard disk and it picked up a few problems and
by deleting a few files I was able to repair it. I'm not so
sure I trust that partition though.
Martin H.
|
138.8 | | PRNSYS::LOMICKAJ | Jeff Lomicka | Fri Sep 23 1988 14:44 | 10 |
| The particular problem I have is that I sometimes run a program that
generates a very large output file, and then crashes or get's rebooted
before it exits. The result of this is that I have lost the free space
forever, since the file was never closed and therefore isn't in the
directory. Currently I have to backup the partition and zero it to get
the space back. I'm looking for a way to get it back without so much
work. I'm hoping that DLII will do this.
If you put it on a disk and give it to Bill, I'll upload it to my Atari
directory on PRNSYS::.
|
138.9 | DLII or DL_II? | MILRAT::WALLACE | | Fri Sep 23 1988 16:34 | 8 |
| DLII will do it for you! I thought a previous reply mentioned he
found it on the net? If not I can upload it this weekend.
DLII (my library listing actualy lists it as "DL_II" I'm not sure
which it is) is also good for running prior to doing any backups.
This insures that you never backup a bad partition.
Ray
|
138.10 | DLII is now on the net | MILRAT::WALLACE | | Fri Sep 23 1988 19:11 | 4 |
| DLII can be copied from
MILRAT::DISK$USER3:[WALLACE.PUBLIC.ST]DLII.ARC
Ray
|