lowey@sask.UUCP (06/04/87)
Hi, I have a problem that I hope someone can help me with. I'm trying to write a Turbo Pascal program to work on Local Area Networks. This program needs to access files stored on the network. For security reasons these files are marked READ ONLY. The problem is that Turbo Pascal won't see a file if it is marked as read only. Logically what it should do is open a file ok, allow you to read from the file, then give IO error number 03: "File not open for output" if the program tries to write to the file. Instead, I get IO error 01: "File does not exist" when I attempt to RESET the file. I assume the problem occurs because Turbo version 3.01A (which I'm using) was written for MS-DOS 2.0, which did not have file locking capabilites. This implies that I have to use MS-DOS 3.0 or higher function calls to open the files. The trick is opening the files in such a way that I can use the Turbo Pascal READ and READLN procedures to get information from the files. Has anyone run into this problem before, and more important, does anyone have a solution? Many Thanks. ______________________________________________________________________________ | Kevin Lowey |The above is the personal opinion of Kevin | | University of Saskatchewan |Lowey. It does not reflect the position of| | Computing Services |the University of Saskatchewan in any way. | | SaskTel: (306) 966-4826 | | | Bitnet:LOWEY@SASK. (preferred) |I am in no way affiliated with any of the | | UUCP: ihnp4!sask!lowey.uucp |above mentioned companies other than U of S| |________________________________|___________________________________________|
catone@dsl.cis.upenn.edu.UUCP (06/08/87)
In article <760@sask.UUCP> lowey@sask.UUCP (Kevin Lowey) writes: > > The problem is that Turbo Pascal won't see a file if it is marked as >read only. Logically what it should do is open a file ok, allow you to >read from the file, then give IO error number 03: "File not open for output" >if the program tries to write to the file. Instead, I get IO error 01: >"File does not exist" when I attempt to RESET the file. > > I assume the problem occurs because Turbo version 3.01A (which I'm using) >was written for MS-DOS 2.0, which did not have file locking capabilites. >This implies that I have to use MS-DOS 3.0 or higher function calls to open >the files. The trick is opening the files in such a way that I can use the >Turbo Pascal READ and READLN procedures to get information from the files. Actually, the read only attribute has existed since DOS 1.0 and has nothing to do with DOS file locking capabilities, which were introduced in DOS 3.0 and are accessed via DOS service request 5C hex. The problem is that Turbo in attempting to open the file is setting the file attribute field to normal; read only files thus do not produce a match to the directory search. The easiest solution would be to use DOS service request 43 hex, get/change file attributes, to temporarily set the file's attributes to normal. You could then access the file and reset the attributes when you are finished. Since Turbo opened files cannot be simultaneously accessed by more than one process on the network (because of the way Turbo sets the sharing mode bits), the only danger would be someone deleting the file between the time you finish reading it and when you reset the attributes. If security is a real concern, you could use DOS services to create a temporary copy of the file with normal attributes, and use that copy, erasing it when you're done. This of course assumes you have write file privileges on either a network or local drive. The most elegant (and most difficult) solution would be to write an external assembly language routine to return a line to Turbo as the var parameter in a procedure call (like the UpperCase example in the Turbo manual, except not inline). This involves choosing a file access method (FCB style calls versus file handle calls), efficiency concerns (internal blocking/deblocking) and line terminination recognication decisions (CR, LF, or CR/LF). It would be a neat project, and is certainly doable. Not this week, however, at least for me. - Tony catone@dsl.cis.upenn.edu catone@wharton.upenn.edu