page@ulowell.cs.ulowell.edu (Bob Page) (12/02/87)
I realize this is too late for the NewFS, since it has been in beta for a while, but here are some suggestions for a future version of the FS. First is file truncation. This can be done today with no sweat, but it requires a Truncate() routine be part of DOS. If I posted a Truncate() routine to the net today, it might not work with the newFS, and I'd like to keep everything working OK. So, I guess this is a suggestion to put a Truncate() in the dos.library. Second is 'file links'. Links allow you to have more than one name for an individual file (No flames about necessity; people who don't use multitasking don't think it's needed either). There are some unused and redundant longwords in the file header, how about claiming one (or maybe the high byte of the protection longword) for a link count? Here are two ways to get the added functionality. I favor the first approach: 1. - create a new file subtype called ST.LINK, and have it point BACK at an ST.FILE (as if the 'file' were a parent). The file header has a longword that points to a link map, which is another filetype like the LIST type that contains pointers to all the links, and to another link map if more are needed. - deleting a 'link' only deletes the link from the link map. Deleting the 'file' will really delete a link from the link map, and rename the file header to the name of the link that you just deleted. Pretty slick, eh? You'll also have to change the parent dir's hash table .. rehash it and put the block number in a new place (if the link and file are in the same directory), or delete the old value and install a new on in the 'new' parent directory. Pretty ugly, eh? Of course deleting a file without a link map means it has no links; you delete it just like you do now. 2. - clone an existing file header, change the name, modify the parent's hash table, and increase the link count on all headers that point to the data. - a change to Delete() so it looks at the link count in the file header. If the link count is >1, it will delete the file header and decrement the link count on all headers that point to the data. For link counts of 1, just do the normal Delete(). - change other FS commands (like setting file protection, changing date stamps, hash tables, etc) to do it across all links that point to the same data. This means either keeping a link map, similar to approach #1. The first approach requires fewer changes to dos.library, and is almost a 'soft hard' link (in UNIX terms). The second approach is more of a 'hard' link, but more work to implement. Making symbolic links across file systems doesn't seem to be needed, but links on directories (rather than just files) would be a win. Anyway, there are two suggestions. ..Bob -- Bob Page, U of Lowell CS Dept. page@ulowell.edu ulowell!page "I've never liked reality all that much, but I haven't found a better solution." --Dave Haynie, Commodore-Amiga
page@ulowell.cs.ulowell.edu (Bob Page) (12/03/87)
Another suggestion - modify the Mount and Format commands to allow the user to specify a larger block size. For example, I'd like to have 2048-byte blocks in my Data: partition, or on my Download floppy. How hard-coded is the current 512-byte value? ..Bob -- Bob Page, U of Lowell CS Dept. page@ulowell.edu ulowell!page "I've never liked reality all that much, but I haven't found a better solution." --Dave Haynie, Commodore-Amiga
pds@quintus.UUCP (Peter Schachte) (12/03/87)
Unix links are a great idea for the Amiga! Hard links and symbolic links each have their uses, but I usually find symbolic links more useful. If I had to choose, I take symbolic links. And if we're having symbolic links, why not allow links across devices? This could be very useful on occasion, e.g., when some piece of software expects to find files in a particular place, but you want to put them on some other disk. -- -Peter
daveh@cbmvax.UUCP (12/04/87)
in article <2086@ulowell.cs.ulowell.edu>, page@ulowell.cs.ulowell.edu (Bob Page) says: > > I realize this is too late for the NewFS, since it has been in beta > for a while, but here are some suggestions for a future version > of the FS. > > Second is 'file links'. Links allow you to have more than one name > for an individual file (No flames about necessity; people who don't > use multitasking don't think it's needed either). There are some > unused and redundant longwords in the file header, how about claiming > one (or maybe the high byte of the protection longword) for a link > count? Here are two ways to get the added functionality. ... I AGREE! We need links! I favor the idea of symbolic links, like in Apollo's Aegis and on BSD UNIX, rather than hard links. You don't need a link count with symbolic links. A link can be another type of disk block. It basically stores information about itself, and a symbolic pointer (pathname) to the thing it's linked to. This way, all files and directories stay exactly the same. When a link is Open()ed or CurrentDir()ed, it returns the specifics of the object it's linked to. This requires knowledge of links by the File System handler, but none by any existing programs, of course. And one new packet, ACTION_CREATE_LINK or somesuch. > ..Bob > -- > Bob Page, U of Lowell CS Dept. page@ulowell.edu ulowell!page > "I've never liked reality all that much, but I haven't found a > better solution." --Dave Haynie, Commodore-Amiga -- Dave Haynie Commodore-Amiga Usenet: {ihnp4|uunet|rutgers}!cbmvax!daveh "The B2000 Guy" PLINK : D-DAVE H BIX : hazy "I can't relax, 'cause I'm a Boinger!"
erd@tut.UUCP (12/05/87)
In article <387@cresswell.quintus.UUCP> pds@quintus.UUCP (Peter Schachte) writes: > >Unix links are a great idea for the Amiga! Hard links and symbolic >links each have their uses, but I usually find symbolic links more >useful. If I had to choose, I take symbolic links. Me too. I would like to see symbolic links for using argc[0], like for compress (giving compress, uncompress, and zcat in one executable, without aliasing). I don't even need symbolic links across devices (since we haven't got a true root/tree file structure) Any chance of symbolic links, O mighty filesystem gurus? -ethan -- Ethan R. Dicks | ###### This signifies that the poster is a member in 2433 N. Fourth St| ## good sitting of Inertia House: Bodies at rest. Columbus OH 43202| ## (614) 262-0461 | ###### "You get it, you're closer."
peter@sugar.UUCP (Peter da Silva) (12/05/87)
In article <2086@ulowell.cs.ulowell.edu>, page@ulowell.cs.ulowell.edu (Bob Page) writes:
< I realize this is too late for the NewFS, since it has been in beta
< for a while, but here are some suggestions for a future version
< of the FS.
<
< First is file truncation...
Why do you need it? Not a flame, a request for info.
< Second is 'file links'...
Important.
< 1. - create a new file subtype called ST.LINK, and have it point
< BACK at an ST.FILE (as if the 'file' were a parent). The file
< header has a longword that points to a link map, which is
< another filetype like the LIST type that contains pointers to
< all the links, and to another link map if more are needed.
< - deleting a 'link' only deletes the link from the link map.
< Deleting the 'file' will really delete a link from the link
< map, and rename the file header to the name of the link that
< you just deleted.
Like it. Like it.
< Pretty slick, eh? You'll also have to
< change the parent dir's hash table .. rehash it and put the
< block number in a new place (if the link and file are in the
< same directory), or delete the old value and install a new
< on in the 'new' parent directory.
Wouldn't the Rename() take care of that?
< Pretty ugly, eh? Of course
< deleting a file without a link map means it has no links;
< you delete it just like you do now.
And it's backward compatible.
< 2. - clone an existing file header...
I've seen people do this in MS-DOS. It's pretty gross. Too much overhead.
--
-- Peter da Silva `-_-' ...!hoptoad!academ!uhnix1!sugar!peter
-- Disclaimer: These U aren't mere opinions... these are *values*.rogerh@arizona.edu (Roger Hayes) (12/07/87)
As long as we are talking about links ...
I would like to be able to protect each name of a file separately.
Then I can have "use" links with read-only protection, and "create"
links with write protection. Handy when I have a .o I want to re-use.
This is easy to get with the clone-the-header kind of link; how would
you do it with the clever kind?
Roger Hayes
rogerh@arizona.edu
{hao!noao,ihnp4,cornell}!arizona!rogerhpeter@sugar.UUCP (Peter da Silva) (12/07/87)
> [symbolic links so you can move files around behind a program's back]
Isn't that what Assign is for?
I'd be more interested in a symbolic (late binding) Assign. I'd like to be
able to do things like "assign include: Aztec:include" in my startup sequence
without it asking me to insert Aztec: then & there. Right now assignments
are handled by throwing around locks on directories. An alternative that
would let you not bind an assignment until it's actually used (OK to turn
it into a lock then, though) would be a benefit.
--
-- Feature: a neat idea that the programmer thinks of.
-- Benefit: a neat idea that the user thinks of.
--
-- Not all features are benefits.
--
-- Peter da Silva `-_-' ...!hoptoad!academ!uhnix1!sugar!peter
-- Disclaimer: These U aren't mere opinions... these are *values*.peter@sugar.UUCP (Peter da Silva) (12/07/87)
Why hard links are better than symbolic links for some purposes... ln myfile yourfile rm myfile cat yourfile Even better idea: trash Tripos, and put in something with a UNIX-like flavor. Hard links, inodes, the whole schmeer. Hashed directories are a botch. -- -- Peter da Silva `-_-' ...!hoptoad!academ!uhnix1!sugar!peter -- Disclaimer: These U aren't mere opinions... these are *values*.
pds@quintus.UUCP (Peter Schachte) (12/10/87)
In article <1236@sugar.UUCP>, peter@sugar.UUCP (Peter da Silva) writes: > > [symbolic links so you can move files around behind a program's back] > > Isn't that what Assign is for? Not the same thing at all. You can't put an assign in a directory. Symbolic links can be very handy for creating a directory that has pointers to file that are actually located all over the disk(s). It effectively allows you to have more than one directory structure for the same files without having to have multiple copies. > I'd be more interested in a symbolic (late binding) Assign. I'd like to be > able to do things like "assign include: Aztec:include" in my startup sequence > without it asking me to insert Aztec: then & there. Amen. -- -Peter Schachte pds@quintus.uucp ...!sun!quintus!pds
page@ulowell.cs.ulowell.edu (Bob Page) (12/12/87)
peter@sugar.UUCP (Peter da Silva) wrote:
>Why do you need [file truncation]? Not a flame, a request for info.
For example, the CHOP utility would use it, for hacking off the extra
bytes from an XMODEM transfer. Essentially Truncate() can be done by
copying the file (except for the last n bytes) to a new file and
deleting the original, but that takes lots of time and space.
Re: file links, I have it from a reliable source that the newFS from
CBM has file links in it, and they do it a different way than the two
methods I described. I don't know enough about the method, but it
looks like they create a block with a LINK type flag and have two
pointers (front and back), thus creating a doubly-linked list of file
headers; the head (?) containing all the traditional info (size,
block list, modification date, etc).
If this is true, deleting a link is easy, and deleting the head just
means Rename() the head and delete the tail (or some other node in
the list, I don't know the details).
However, it means you have to modify DOS to always traverse the list
when you need to know anything in the file besides its name, unless
you keep all the information about the file header in each link block
- in which case you're just cloning file headers, like method #2 I
described in my original article.
I'd like to know more about this - from the description I got it seems
potentially time-consuming (potentially n seeks for a file with n
links). And I'd like to know if it works with directory blocks.
I'd rather see those forward and back pointers used for something else,
like a 'creation date' or some such (note the current implementation
uses the date fields for 'last modified date').
..Bob
--
Bob Page, U of Lowell CS Dept. page@ulowell.edu ulowell!page
"I've never liked reality all that much, but I haven't found a
better solution." --Dave Haynie, Commodore-Amigamichael@stb.UUCP (Michael) (12/12/87)
In article <1236@sugar.UUCP> peter@sugar.UUCP (Peter da Silva) writes: >> [symbolic links so you can move files around behind a program's back] > >Isn't that what Assign is for? > >I'd be more interested in a symbolic (late binding) Assign. I'd like to be >able to do things like "assign include: Aztec:include" in my startup sequence >without it asking me to insert Aztec: then & there. Right now assignments >are handled by throwing around locks on directories. These are not the same. A late (or not) binding Assign is NOT the same as symbolic links. Symbolic links are dependend on where in the file system you are. Assigns (Which, I agree should be symbolic, not locks) are global. Assigns take a LOCK on the file--try doing things with a locked file. But yes, I'd rather see symbolic links than no links. Hard links are messy on AmyDos; so, maybe we don't get them. -- : Michael Gersten ihnp4!hermix!ucla-an!remsit!stb!michael : sdcrdcf!trwrb!scgvaxd!stb!michael : "Copy Protection? Just say 'Off site backup'. "
peter@sugar.UUCP (Peter da Silva) (12/15/87)
pds@quintus.UUCP (Peter Schachte) writes: > In article <1236@sugar.UUCP>, peter@sugar.UUCP (Peter da Silva) writes: > > > [symbolic links so you can move files around behind a program's back] > > Isn't that what Assign is for? > Not the same thing at all. You can't... It's not the same thing, but it can be used for the same purpose. Instead of hardcoding path names in your program and using slinks to fake them out, you hard code assignments in the program and use assignments to fake them out. Same result, different mechanism. No reason to do both. > > I'd be more interested in a symbolic (late binding) Assign. > Amen. -- -- Peter da Silva `-_-' ...!hoptoad!academ!uhnix1!sugar!peter -- Disclaimer: These U aren't mere opinions... these are *values*.
peter@sugar.UUCP (Peter da Silva) (12/16/87)
Somone else didn't read what I said... In article <10002@stb.UUCP>, michael@stb.UUCP (Michael) writes: > In article <1236@sugar.UUCP> peter@sugar.UUCP (Peter da Silva) writes: > >> [symbolic links so you can move files around behind a program's back] > >Isn't that what Assign is for? > These are not the same. A late (or not) binding Assign is NOT the same as > symbolic links. I didn't say they were the same. I said they were for the same purpose. If I'd wanted to say they were the same, I'd have left out the last word of that sentence and said: > >Isn't that what Assign is? -- -- Peter da Silva `-_-' ...!hoptoad!academ!uhnix1!sugar!peter -- Disclaimer: These U aren't mere opinions... these are *values*.