Prev: execution times for Open64 Fortran 95 compiler
Next: data types inside interface
From: nmm1 on 31 Jul 2010 04:20
In article <c7262ea6-acec-4857-977a-2f21e81020ed(a)y32g2000prc.googlegroups.com>,
Steven Correll <steven.correll(a)gmail.com> wrote:
><robert.corb...(a)oracle.com> wrote:
>> >The Fortran run-time systems for UNIX and UNIX-like operating systems
>> >have assumed that the devno and inode numbers taken together uniquely
>> >identify a file. =A0On other operating systems, the file name has been
>> >assumed to uniquely identify the file.
>
>On Jul 30, 3:37 am, n...(a)cam.ac.uk wrote:
>> In article <197c4f59-aa19-4ec4-a8dd-e50386359...(a)i4g2000prf.googlegroups.=
>com>,
>> And the concept that files can be uniquely identified
>> by a file name is one that Unix has, but not MVS.
>
>I believe Robert Corbett's point was that files cannot be uniquely
>identified by name on Unix, at least not for purposes of implementing
>INQUIRE. Because many links with different names may point to the same
>file, the runtime system must map the name to a devno/inode pair, and
>ask itself whether any logical unit is connected with that pair.

That is true, but was not my point. Under Unix and Unix-like systems,
a file name uniquely identifies a file, but a file does not have a
unique name. Robert Corbett was describing something that is commonly
done, because it is reasonably reliable and is easily implementable.

As Glen Herrmannsfeldt says, the situation is very different under
MVS.


Regards,
Nick Maclaren.
From: Ron Shepard on 31 Jul 2010 13:21
In article <i30mcb$ft6$1(a)smaug.linux.pwf.cam.ac.uk>, nmm1(a)cam.ac.uk
wrote:

> That is true, but was not my point. Under Unix and Unix-like systems,
> a file name uniquely identifies a file, but a file does not have a
> unique name.

In addition to hard and soft links, which can map multiple file
names to a single file, there are also mixtures of absolute and
relative addressing. For example, if the current default directory
path (using MacOSX as an example) is /Volumes/s/projects/molecules,
then all of the following filenames point to the same file

file.dat
../file.dat
.../molecules/file.dat
.../molecules/./file.dat
.../molecules/../molecules/file.dat
.../molecules/../molecules/./file.dat
/Volumes/s/projects/molecules/file.dat
/Volumes/s/projects/molecules/./file.dat

and so on ad infinitum. Also, the / separators can be repeated

..//file.dat
...//molecules//file.dat

and so on. The important point is that ./ and ../ are part of the
unix file system, and every directory has them defined, they are not
shell-specific aliases or anything like that. There are other ways
to address files in unix systems that may (or may not) be supported
by the fortran library. These include things like

$PWD/file.txt
$HOME/file.txt
$SOME_USER_DEFINED_ENVIRONMENT_VARIABLE/file.txt
~username/file.txt

If supported, then these can also be combined with ./ and ../ in
arbitrary ways.

All of this affects fortran in various ways. One way is that after
the sequence

open(unit=n,file=filename1)
inquire(unit=n,name=filename2)

the character strings filename1 and filename2 are not necessarily
equal. They are the same with some fortran compilers, but they are
typically different with others. For example, filename1 might have
been set to one of the above relative pathnames, while filename2
might be returned to have the absolute pathname (or one of them, in
the case of multiple links). As far as I know, none of this is
specified in either the fortran standard or the POSIX standard. It
is just up to the compiler writers to try to determine which
approach is best for their users.

$.02 -Ron Shepard
From: glen herrmannsfeldt on 31 Jul 2010 13:42
nmm1(a)cam.ac.uk wrote:
(snip)

> That is true, but was not my point. Under Unix and Unix-like systems,
> a file name uniquely identifies a file, but a file does not have a
> unique name. Robert Corbett was describing something that is commonly
> done, because it is reasonably reliable and is easily implementable.

> As Glen Herrmannsfeldt says, the situation is very different under
> MVS.

and just about every system other than Unix (and related systems).

MS-DOS has drive letters, VM/CMS has file mode letters, VMS
has device names, and other DEC created systems have ways
to specify the device. In those cases, though, there is a way
to specify disk device/file on device as one string.

e:\somefile.txt, somefile txt e, DSKE:somefile.txt

There is no such single string form for MVS.

//SYSIN DD DSN=SOMEFILE.TXT,VOL=SER=DISKE,UNIT=DISK,DISP=SHR

The file name (DSN) and device (VOLume SERial number) are
specified separately.

-- glen
From: glen herrmannsfeldt on 31 Jul 2010 13:48
Ron Shepard <ron-shepard(a)nospam.comcast.net> wrote:
(snip)

> In addition to hard and soft links, which can map multiple file
> names to a single file, there are also mixtures of absolute and
> relative addressing.
(snip)

> file.dat
> ./file.dat
> ../molecules/file.dat
> ../molecules/./file.dat
(snip)

> open(unit=n,file=filename1)
> inquire(unit=n,name=filename2)

> the character strings filename1 and filename2 are not necessarily
> equal. They are the same with some fortran compilers, but they are
> typically different with others. For example, filename1 might have
> been set to one of the above relative pathnames, while filename2
> might be returned to have the absolute pathname (or one of them, in
> the case of multiple links). As far as I know, none of this is
> specified in either the fortran standard or the POSIX standard. It
> is just up to the compiler writers to try to determine which
> approach is best for their users.

In expanding environment variables or a ~ reference to $HOME,
it would not be surprising for INQUIRE to return the absolute
path name. For symbolic links, it is not so hard to find
the linked-to name and use that.

In the case of hard links, it would be very surprising
to find another hard link to the same file returned. The way to
find such is to search the whole file system for another file
with the same inode number.

-- glen
From: JB on 31 Jul 2010 16:53
On 2010-07-31, Ron Shepard <ron-shepard(a)NOSPAM.comcast.net> wrote:
> In article <i30mcb$ft6$1(a)smaug.linux.pwf.cam.ac.uk>, nmm1(a)cam.ac.uk
> wrote:
>
>> That is true, but was not my point. Under Unix and Unix-like systems,
>> a file name uniquely identifies a file, but a file does not have a
>> unique name.
>
> In addition to hard and soft links, which can map multiple file
> names to a single file, there are also mixtures of absolute and
> relative addressing. For example, if the current default directory
> path (using MacOSX as an example) is /Volumes/s/projects/molecules,
> then all of the following filenames point to the same file
>
> file.dat
> ./file.dat
> ../molecules/file.dat
> ../molecules/./file.dat
> ../molecules/../molecules/file.dat
> ../molecules/../molecules/./file.dat
> /Volumes/s/projects/molecules/file.dat
> /Volumes/s/projects/molecules/./file.dat
>
> and so on ad infinitum.

And, thanks to POSIX delete-on-last-close semantics, you can do
funnyness such as

open(10, file='foo')
call unlink('foo') ! Or system('rm foo') or something like that
open(11, file='foo')

And now you have two units with the same file name but referring to
different files. Of course, since you deleted the file inbetween, the
file name for unit 10 is invalid in the sense that it's no longer
present in the directory.

Anyway, as Mr. Corbett already mentioned, the POSIX'y way of thinking
is to forget about comparing file names and instead compare whether
the device and inode numbers match.

> All of this affects fortran in various ways. One way is that after
> the sequence
>
> open(unit=n,file=filename1)
> inquire(unit=n,name=filename2)
>
> the character strings filename1 and filename2 are not necessarily
> equal. They are the same with some fortran compilers, but they are
> typically different with others. For example, filename1 might have
> been set to one of the above relative pathnames, while filename2
> might be returned to have the absolute pathname (or one of them, in
> the case of multiple links). As far as I know, none of this is
> specified in either the fortran standard or the POSIX standard.

Yes; Fortran has no concept of directories, or symlinks for that
matter, and POSIX doesn't specify anything about Fortran.

For another related implementation-defined behavior, consider dangling
symlinks, and how open and inquire should handle them. This was
discussed on the gfortran list not terribly long ago:

http://gcc.gnu.org/ml/fortran/2009-09/msg00090.html

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41387



--
JB
First  |  Prev  | 
Pages: 1 2 3
Prev: execution times for Open64 Fortran 95 compiler
Next: data types inside interface