rznowski@psuvax1.UUCP (03/27/85)
Recently a problem has arisen, and we are looking for solutions.
The problem is as follows:
There are two users, user T with a tape and user N - no tape.
User T has a tape mounted with 100 files and is going to add
another file onto the end of the tape. He uses the command
"tar r file101". After this command has executed, the tape
will still be mounted and online.
User N types the command "tar cv tarout myfile". (command
should be "tar cvf tarout myfile") The output of tar will
be: "tar: tarout: no such file or directory". HOWEVER,
the tape belonging to user T will have been erased and only
one file will be there (namely myfile).
As you can see, alot of information has been lost by user T,
perhaps it cannot be recovered. The reason that we have
run into this problem, is that we have just added many new
users who are just learning about the system, and now many
more people are using tapes as offline storage.
Please reply to either:
Mark Starner starner@psuvax1
Stephen Roznowski rznowski@psuvax1
--
Stephen J. Roznowski
Pennsylvania State University
{allegra, akgua, ihnp4}!psuvax1!rznowskiroot@bu-cs.UUCP (Barry Shein) (03/31/85)
I'll repeat my simple suggestion regarding tape drive access under UNIX, no one has complained yet though I don't use it (yet, no one here seems to ever USE tapes.) 1.Create a pseudo user who will own the drives when free, the name 'free' is an excellent choice. 2. chown all tape devices to 'free' and remove other permissions. 3. Write a little shell script or C program to chown to the current effective uid of the person running this program a tape drive (all minor devices). Make it setuid() to root. After it does the chowns it setuid's to the effective uid and forks a shell and waits for exit. On exit it chowns the tape devices back to 'free'. Maybe call this 'mtmount', arg could be unit number if you have more than one tape. Now just a 'ls -l /dev/mt0' or whatever tells a user that a tape is 'free' (or who is using it so they can use 'write' if need be.) Also, hangups and logouts should now free the tape up (catch SIGHUP in the mtmount prog.) Hey, like all advice on this net, it's 'free' :-) -Barry Shein, Boston University
gwyn@brl-tgr.ARPA (Doug Gwyn <gwyn>) (04/01/85)
You need a utility for allocating (and deallocating) devices (should also work with any type of file). When unallocated, the device would be owned by, say, "public". The allocator would be set-UID "public" (set-UID "root" on non-AT&T systems) and would give the device to the requestor if someone else didn't already have it. This is just the simplest sketch of what such a utility should do. I have complete design notes for a full system that handles daemon processes, failure to deassign upon logout, generic device classes, and sundry other considerations. Unfortunately I never got around to implementing the design. Some such utility should be standard.
jph@whuxlm.UUCP (Holtman Jim) (04/03/85)
> You need a utility for allocating (and deallocating) devices (should > also work with any type of file). When unallocated, the device would > be owned by, say, "public". The allocator would be set-UID "public" > (set-UID "root" on non-AT&T systems) and would give the device to the > requestor if someone else didn't already have it. > > This is just the simplest sketch of what such a utility should do. > I have complete design notes for a full system that handles daemon > processes, failure to deassign upon logout, generic device classes, > and sundry other considerations. Unfortunately I never got around > to implementing the design. Some such utility should be standard. If UNIX(tm) were really a user friendly system, it would support `labeled' tapes and then you would have this problem. The system would read the tape label before writing on it to ensure it really was the one that was requested.
wls@astrovax.UUCP (William L. Sebok) (04/05/85)
> If UNIX(tm) were really a user friendly system, it would support > `labeled' tapes and then you would have this problem. The system > would read the tape label before writing on it to ensure it really > was the one that was requested. Until you needed to handle a tape written elsewhere in which case the system would suddenly become very UNFRIENDLY. Most of the time it has seemed to me that the fancy tape restrictions have just gotten in the way. The trouble tends to be that each system thinks that it's tape format it the only one in existence. The rest of the world is "FOREIGN". Dealing with multiple tape formats tends to be especially necessary in astronomical sites. Data is exchanged between different sites and different telescopes. This is often in different tape formats, often generated on different machines. Standards have arisen (notably the FITS standard for image transfer) but much of the time they correspond to no single operating system's "native" tape format. -- Bill Sebok Princeton University, Astrophysics {allegra,akgua,burl,cbosgd,decvax,ihnp4,noao,princeton,vax135}!astrovax!wls
tihor@acf4.UUCP (Stephen Tihor) (04/06/85)
Gee I dunno, the only systems here that can't write ANSI-standard D-format variable length record tapes are out of the box Unix's. The vendor provided systems that come with user accessible tape dirves seem to handle ANSI standard D-format (and block fixed sized record) tapes well.
louie@umd5.UUCP (04/07/85)
In article <573@astrovax.UUCP> wls@astrovax.UUCP (William L. Sebok) writes: >> If UNIX(tm) were really a user friendly system, it would support >> `labeled' tapes and then you would have this problem. The system >> would read the tape label before writing on it to ensure it really >> was the one that was requested. > >Until you needed to handle a tape written elsewhere in which case the >system would suddenly become very UNFRIENDLY. Most of the time it has >seemed to me that the fancy tape restrictions have just gotten in the >way. The trouble tends to be that each system thinks that it's tape >format it the only one in existence. The rest of the world is "FOREIGN". Now wait just a minute! That's what ANSI STANDARD tape labels are for. The labels are a standard format, not the data on the tape. Even IBM systems can recognize the tape labels written by a Sperry system. The idea is that the operating system processes the labels transparently to the user, such that the user never sees the labels on the tape. When the tape is mounted, the OS reads the VOL1 label to verify that the reel number requested matches the one on the tape. There's more to it than that.. You obviously have never had one of your (unlabeled) tapes destroyed due to an operator mounting reel "P8610" instead of "P8601". -- Louis A. Mamakos WA3YMH University of Maryland, Computer Science Center Internet: louie@umd5.arpa UUCP: {seismo!umcp-cs, ihnp4!rlgvax}!cvl!umd5!louie
jsdy@hadron.UUCP (Joseph S. D. Yao) (04/11/85)
> If UNIX(tm) were really a user friendly system, it would support > `labeled' tapes and then you would have this problem. The system > would read the tape label before writing on it to ensure it really > was the one that was requested. I would like to disagree strongly (but in a user-friendly manner). The operating system has no business whatsoever interpreting what is on a raw device like a tape, unless it is mounted as (say) a file system. If UNIX had decided on some label format, even ANSI label format, then it would not be possible (as possible?) to use it as such a powerful tool for decrypting the rest of the world's tapes. Have you ever t r i e d interpreting, say, a TOPS-20 tape under VMS? I have. No fun. And that's from the same manufacturer! Joe Yao hadron!jsdy@seismo.{ARPA,UUCP}