disk full up!!! why???

[Calum]

right, i filled up my floppy disk with stuff (using linux) and then i used rm to delete it all, except one file that uses 38 bytes. When i try to copy stuff onto the disk, i get this message: "no space left on device", in desperation i reboot into windows, and find explorer.exe telling me that there is 714kb used out of a possible 714kb. Now since winME does not format 720 kb disks, i have to reboot into linux to even do that. i do not want to format every time i want to use the disk again, what is the matter here? i use supermount by the way, does this make any odds?

why?

thanks............

[creedon]

quote:Originally posted by Calum:
right, i filled up my floppy disk with stuff (using linux) and then i used rm to delete it all, except one file that uses 38 bytes. When i try to copy stuff onto the disk, i get this message: "no space left on device", in desperation i reboot into windows, and find explorer.exe telling me that there is 714kb used out of a possible 714kb. Now since winME does not format 720 kb disks, i have to reboot into linux to even do that. i do not want to format every time i want to use the disk again, what is the matter here? i use supermount by the way, does this make any odds?

why?

thanks............

Stab in the dark; could it be that, since everything is seen as a file in Linux, you have to delete all the data on the disk in order for Linux to see it as an empty file?  I know that sounds stupid, but it kinda makes SOME sense.
Feel free to flame me on this one.

[voidmain]

How are you copying files to the floppy? Are you mounting the floppy disk then copying files to it, then deleting files and removing the disk without first "unmounting the disk"?  In Linux (and most other UNIX systems) a lot of IO is cached (delayed writes).  Makes things much faster.  However, if you remove a disk without unmounting it then your "deletes" may have been cached and never actually occured.  Also, the "sync" command will flush all of the cached disk IO.

[creedon]

quote:Originally posted by VoidMain:
How are you copying files to the floppy? Are you mounting the floppy disk then copying files to it, then deleting files and removing the disk without first "unmounting the disk"?  In Linux (and most other UNIX systems) a lot of IO is cached (delayed writes).  Makes things much faster.  However, if you remove a disk without unmounting it then your "deletes" may have been cached and never actually occured.  Also, the "sync" command will flush all of the cached disk IO.

YEAH!  What HE said!!!

[Calum]

quote:Originally posted by VoidMain:
How are you copying files to the floppy? Are you mounting the floppy disk then copying files to it, then deleting files and removing the disk without first "unmounting the disk"?  In Linux (and most other UNIX systems) a lot of IO is cached (delayed writes).  Makes things much faster.  However, if you remove a disk without unmounting it then your "deletes" may have been cached and never actually occured.  Also, the "sync" command will flush all of the cached disk IO.

aha! something like this is most likely the problem, however i am not doing any of this disk hotswapping that you suggest. i am using supermount for the floppy and cd drives, which is supposed to make the mounting and unmounting transparent in the same way as they are in windows (most of the time). It works fine with the CD drive, where the system gets a message every time you eject or put a new CD in, but with the floppy it is a little odder. i can not umount or mount unless root, with supermount, and if i do either of those, supermount no longer attempts to mount and umount for me and i must do all of that by hand.

nevertheless, i am not doing anything unusual. in many cases i have shutdown the computer with a 'shutdown -h now' while the floppy is still in the drive, so the system should have had ample time to complete its de-caching.

Another problem has arisen in a similar vein:

when i try to copy or move files to or from my floppy drive using konqueror or xftree, and i think galeon as well (or whichever the gnome file manager thing is), i sometimes get the computer totally lock up in the middle of the operation. desktop freezes, mouse does not move cursor, ctrl-alt-backspace does not work, ctrl-alt-f1 does not work, ctrl-alt-del does not work, and i need to literally power off and reboot, which causes an fsck. i cannot recall ever having this problem while using 'cp' from a prompt or an xterm, and it only happens occasionally. any idea what's going on?

the case on my (onboard laptop) floppy drive is a little cracked and sometimes leads the system (whether it be windows or linux) to think that the disk is write protected when it is not. this is not usually a problem, once it realises it is not write protected, it carries on fine.

this morning, for example, i copied a folder of perl tutorials onto my floppy using konqueror, then i tried to copy a folder of C++ tutorials too, same circumstances, and... total freeze up, requiring reboot.

any ideas? Thanks, folks...

[Calum]

ps, re: that caching thing, is there a way to make linux perform all the deletes and so on in its cache to get them out of the way, by entering some command? also, is there a way to automate it, so it does it at , for example, ten minute intervals?

[flap]

quote:Originally posted by VoidMain:
Also, the "sync" command will flush all of the cached disk IO.

[Calum]

yes, yes, yes! we're not all perfect you know!      :rolleyes:

[Master of Reality]

quote:Originally posted by Calum/ halfbob:
yes, yes, yes! we're not all perfect you know!        :rolleyes:  

I am.... so is Bob. We will have a utopia, Bob.

[Calum]

ta, folks! now any ideas about my hideous copy/move/uh-oh-it-froze-again dilemma?

[voidmain]

I have no idea what could be causing your "freeze" problem.  Never seen such a thing. But as far as automount. Yes it will automount the floppy if you have it so configured but if you press the eject button while it's mounted you are going to have problems as there is no way the system can tell when you are planning on pressing the eject button. With CDs there is an "eject" command which will unmount the CD before ejecting.

There are several ways you can unmount the disk as a normal user. I would suggest the best way is to add the "user" tag in the options in /etc/fstab in the entry for your floppy. Now since you are using KDE if you have a floppy device ICON on your desktop you should also get the "unmount" option when you right click on it.

I suspect the "freeze" problem might be associated with ejecting the floppy while it is mounted and KDE expects to still see the file system there and it would have to wait for a time-out (could be a very long time).  Maybe I've never run across this problem because I always unmount before ejecting.. I don't know if there is a way to set a timeout to a lower setting, or what would even need to be adjusted.

[Pantso]

Ah! Unmounting. Might seem like one of those Linux oddities at first, but it's a very important and practical characteristic. It could prove to be a very important feature in a multi-user enviroment as well, where you have several programs and users wanting access to the same medium at the same time.

Basically what mount does is to incorporate or register the medium on the directory tree. And as void main said, never take the medium out of the drive before you unmount because your system would propably freeze.

[Calum]

voidmain, thank you for your thoughts however i think i may have inadvertantly handed you the wrong end of the stick,

i use XFce now as my desktop, so cannot have icons on the desktop, now the freezing i experience happens immediately a couple of seconds after i attempt to drag and drop from a /mnt/home/ window onto a /mnt/floppy window, but it only happens sometimes. maybe 20-30% of the time. it also happens in other file browsers too.

it's not an X thing either, and the floppy drive does not spin while doing it either.

do you think this may also be a caching issue? some sort of loop? where the files to be transferred get cached but do not get put on the disk, and maybe the data all back up against itself?

just a wild stab in the dark.

thanks for the thoughts anyway, chaps!  

[voidmain]

Does the same thing happen in KDE?  It should have nothing to do with caching because that is all done well below the window manager level and is something that shouldn't even be known to the window manager. If it doesn't have problems copying files to the floppy at a shell prompt or from any other Window manager then I would suggest the problem lies with XFce. Now, since the floppy is a much slower device maybe that is exposing a problem with XFce. Let me know if the problem also exists outside of XFce and I'll do a little research for ya.

[KernelPanic]

this is probably completely wrong (is it void main?) but couldnt you use the CLI copy command in a terminal window and copy from /home/calum to /dev/fd0.