douglee@becker.UUCP (Doug Lee) (12/14/89)
quick question for AmigaDOS gurus. While capturing to ram: with my terminal , I can do a list at any time and get the current size of the file I'm writing to. When capturing to rad: I get 'empty' for filesize until I close it. Why do these two devices behave so differently when there is a write lock? <<<Doug>>> -- Doug Lee douglee@becker 416-461-5357
mks@cbmvax.commodore.com (Michael Sinz - CATS) (12/15/89)
In article <1336@becker.UUCP> douglee@becker.UUCP (Doug Lee) writes: > > quick question for AmigaDOS gurus. While capturing to ram: with my terminal > , I can do a list at any time and get the current size of the file I'm writing > to. When capturing to rad: I get 'empty' for filesize until I close it. Why > do these two devices behave so differently when there is a write lock? > <<<Doug>>> First, some background: RAM: is a filing system and device all rolled up into one. It is not OFS or NFS or anything else. RAD: is a device that can have a filing system attached to it. (OFS or NFS or ...) Now, with that in mind, let's look at the list command and what it does: The list command basically, (no real details here) will have to do a Examine() on the file and check the file info block. If you check a file that is open, the size displayed is that of what the filing system is reporting from the directory entry. In RAM:, the filing system updates that information every time some data is written. Why not, as it has to keep track of it somewhere anyway and in RAM: it does not take any real time to get at the directory entry. On a floppy or hard disk, you would not want the filing system to write that new information every time there is some data written to the file. (Write a byte, seek to the directory entry, read it, change it, write it...) For this reason, filing systems normally only update such information on close of the file or on certain flush situations. Since RAD: uses a normal filing system, it is the filing system that does not update that value just like on floppies or hard disks. If you want RAD: to update that information, you are always more than welcome to write a new filing system and use that with RAD: >-- >Doug Lee >douglee@becker >416-461-5357 /----------------------------------------------------------------------\ | /// Michael Sinz -- CATS/Amiga Software Engineer | | /// PHONE 215-431-9422 UUCP ( uunet | rutgers ) !cbmvax!mks | | /// | |\\\/// When people are free to do as they please, | | \XX/ they usually imitate each other. | \----------------------------------------------------------------------/
peter@sugar.hackercorp.com (Peter da Silva) (12/17/89)
In article <9032@cbmvax.commodore.com> mks@cbmvax.commodore.com (Michael Sinz - CATS) writes: > [don't want to rewrite deirectory block on every write] For this > reason, filing systems normally only update such information on close > of the file or on certain flush situations. The other thing is to change the get file info call to use the real data instead of going to disk for it. Makes sense, anyway... if it's in memory for the open file anyway why bother rereading it? UNIX effectively does this. -- Peter "Have you hugged your wolf today" da Silva <peter@sugar.hackercorp.com> `-_-' 'U` "I haven't lost my mind, it's backed up on tape somewhere"
tell@oscar.cs.unc.edu (Stephen Tell) (12/17/89)
In article <9032@cbmvax.commodore.com> mks@cbmvax.commodore.com (Michael Sinz - CATS) writes: >In article <1336@becker.UUCP> douglee@becker.UUCP (Doug Lee) writes: >> >> quick question for AmigaDOS gurus. While capturing to ram: with my terminal >> , I can do a list at any time and get the current size of the file I'm writing >> to. When capturing to rad: I get 'empty' for filesize until I close it. Why >> do these two devices behave so differently when there is a write lock? >> <<<Doug>>> > For this >reason, filing systems normally only update such information on close >of the file or on certain flush situations. > >| /// Michael Sinz -- CATS/Amiga Software Engineer | >| /// PHONE 215-431-9422 UUCP ( uunet | rutgers ) !cbmvax!mks | One reason that you might want the other behavior (update directory a lot) is so that in case of a guru you can still get back part of the file, and maybe even restart the transfer. How can one force a flush of a file opened in the various ways (5 of them: Open, manx open/fopen, lattice open/fopen)? Does doing this flush operation guarantee that the write has occured, or is there an equivilent to the unix sync() that one can call? This seems like a desirable option for file-transfer programs, and for programs that write a debugging logfile (so you can see where they died). -------------------------------------------------------------------- Steve Tell tell@wsmail.cs.unc.edu CS Grad Student, UNC Chapel Hill.