A strange behaviour of a File property

[Andreas Leitgeb]

IMHO, Java errs in exposing any "path separator" at all, because
it just encourages string-bashing. Note that in some file systems
there is no such thing as a "path separator;" on one such I had
files with names like
SYS$DISK:[USERS.ERIC.PROJECT]README.TXT;22

Such beasts still exist in the wild?

$ type DISK2:[ARNE]HELLOWORLD.JAVA;1

[...]

This doesn't yet answer the "in the wild"-part: Is that a machine
still in productive use, or is it merely running under a VAX-emulator
on a PC (just for playing around)?

Anyway, as it seems (gathered from googled pages), java is able to
translate paths like "/disk2/arne/helloworld.java" to what the
system understands, so there'd not really be much of a need for a Java
programmer to explicitly deal with those path construction pecularities.

 

[Andreas Leitgeb]

On 11/11/2011 10:21 PM, Andreas Leitgeb wrote:
[...] Note that in some file systems
there is no such thing as a "path separator;" on one such I had
files with names like
SYS$DISK:[USERS.ERIC.PROJECT]README.TXT;22
Such beasts still exist in the wild?
http://en.wikipedia.org/wiki/Files-11#Disk_organization_and_naming
"A fossil!" I hear you cry, "A dried relic of prehistory!"

I'm not the type who would cry out about it, but I admit, I did think
something more or less similar.

I do not consider version numbers prehistoric relics.

Of course not those... (I think I've seen them even in some modern
filesystems with versioning support).
But I do consider the brackets enclosing the directory part of a
file's path to be such. (namely prehistoric relics)

* Java actually supports both native syntax and traditional
*nix / syntax for filenames

So that gets us back to the start:
Just using "/" as dir-separator is very likely to get you far enough.

 

[Arne Vajhøj]

IMHO, Java errs in exposing any "path separator" at all, because
it just encourages string-bashing. Note that in some file systems
there is no such thing as a "path separator;" on one such I had
files with names like
SYS$DISK:[USERS.ERIC.PROJECT]README.TXT;22
Such beasts still exist in the wild?

$ type DISK2:[ARNE]HELLOWORLD.JAVA;1

[...]

This doesn't yet answer the "in the wild"-part: Is that a machine
still in productive use, or is it merely running under a VAX-emulator
on a PC (just for playing around)?

There are still some in production use.

The one used is hobbyist only though.

Anyway, as it seems (gathered from googled pages), java is able to
translate paths like "/disk2/arne/helloworld.java" to what the
system understands, so there'd not really be much of a need for a Java
programmer to explicitly deal with those path construction pecularities.

I consider it very relevant for an Java app to be able to handle
native file name syntax - after all that is what most likely
will be specified in config files and manually entered.

Arne

 

[Arne Vajhøj]

On 11/11/2011 10:21 PM, Andreas Leitgeb wrote:
[...] Note that in some file systems
there is no such thing as a "path separator;" on one such I had
files with names like
SYS$DISK:[USERS.ERIC.PROJECT]README.TXT;22
Such beasts still exist in the wild?
http://en.wikipedia.org/wiki/Files-11#Disk_organization_and_naming
"A fossil!" I hear you cry, "A dried relic of prehistory!"
I'm not the type who would cry out about it, but I admit, I did think
something more or less similar.

I do not consider version numbers prehistoric relics.

Of course not those... (I think I've seen them even in some modern
filesystems with versioning support).
But I do consider the brackets enclosing the directory part of a
file's path to be such. (namely prehistoric relics)

So / is modern but [] is oldfashioned.

Are there any objective reason for that?

So that gets us back to the start:
Just using "/" as dir-separator is very likely to get you far enough.

It will get you to where a user actually specify a filename
in normal native syntax.

Arne

 

[Eric Sosman]

IMHO, Java errs in exposing any "path separator" at all, because
it just encourages string-bashing. Note that in some file systems
there is no such thing as a "path separator;" on one such I had
files with names like
SYS$DISK:[USERS.ERIC.PROJECT]README.TXT;22
Such beasts still exist in the wild?

$ type DISK2:[ARNE]HELLOWORLD.JAVA;1

[...]

This doesn't yet answer the "in the wild"-part: Is that a machine
still in productive use, or is it merely running under a VAX-emulator
on a PC (just for playing around)?

Anyway, as it seems (gathered from googled pages), java is able to
translate paths like "/disk2/arne/helloworld.java" to what the
system understands, so there'd not really be much of a need for a Java
programmer to explicitly deal with those path construction pecularities.

Speaking as a person who wrote code that tried to mediate
between VMS ("structured") file names and Unix ("just glob it") paths,
I am here to tell you that there are many subtle traps. Version numbers
inevitably got garbled, if not "in translation" then "in manipulation"
on the other side of the fence. The fact that the parent directory of

SYS$DISK:[USERS.ERIC.PROJECT]README.TXT;22
was
SYS$DISK:[USERS.ERIC]PROJECT.DIR;1

baffled innumerable Unixoid programs that thought they could just "take
everything before the rightmost separator" to get the parent's name.
Anybody who thinks the mapping is half a day's work has got another
think coming -- and weeks of unplanned labor, too. I've got the scars.

Common LISP supported a richer filename abstraction, one that could
handle Unix and DOS and Apollo and Mac and VMS and probably others I wot
not of. Steele was certainly aware of LISP's capability (he made money
off a LISP book, after all), so Java's blinkered view is puzzling.

IMHO, File is the second-sloppiest "everyday" core Java class,
losing out only to Date (if "losing" is the right word).

 

[Andreas Leitgeb]

On 11/12/2011 5:09 PM, Andreas Leitgeb wrote:
On 11/11/2011 10:21 PM, Andreas Leitgeb wrote:
[...] Note that in some file systems
there is no such thing as a "path separator;" on one such I had
files with names like
SYS$DISK:[USERS.ERIC.PROJECT]README.TXT;22
Such beasts still exist in the wild?
http://en.wikipedia.org/wiki/Files-11#Disk_organization_and_naming
"A fossil!" I hear you cry, "A dried relic of prehistory!"
I'm not the type who would cry out about it, but I admit, I did think
something more or less similar.
I do not consider version numbers prehistoric relics.

Of course not those... (I think I've seen them even in some modern
filesystems with versioning support).
But I do consider the brackets enclosing the directory part of a
file's path to be such. (namely prehistoric relics)

So / is modern but [] is oldfashioned.
Are there any objective reason for that?

In a way, I envy you (Eric and Arne) for your wider horizon. I've
never got in touch with it, and haven't found any official ISO image
or zip or tarball, either, to get my own hands on it. (I guess the
"open" in "openvms" is more like the one in "openmotif", than the
one in "openoffice".

That said, I do have my "personal reasons" for calling openvms
essentially irrelevant for new software development (a bit like
pre-X MacOS, CP/M - not to mention my sharp pocket-computers from
last decade's eighties). I'm not going to write a thesis on
scientific classification of operating systems by their "obsolete-
ness", though.

It's the same principial reason, btw., that makes others discard
anything non-MS.

 

[Martin Gregorie]

On 11/12/2011 5:09 PM, Andreas Leitgeb wrote:
On 11/11/2011 10:21 PM, Andreas Leitgeb wrote:
[...] Note that in some file systems there is no such thing as a
"path separator;" on one such I had files with names like
SYS$DISK:[USERS.ERIC.PROJECT]README.TXT;22
Such beasts still exist in the wild?
http://en.wikipedia.org/wiki/Files-11#Disk_organization_and_naming
"A fossil!" I hear you cry, "A dried relic of prehistory!"
I'm not the type who would cry out about it, but I admit, I did think
something more or less similar.
I do not consider version numbers prehistoric relics.

Of course not those... (I think I've seen them even in some modern
filesystems with versioning support).
But I do consider the brackets enclosing the directory part of a file's
path to be such. (namely prehistoric relics)

So / is modern but [] is oldfashioned.

Are there any objective reason for that?

So that gets us back to the start:
Just using "/" as dir-separator is very likely to get you far enough.

It will get you to where a user actually specify a filename in normal
native syntax.

.... but its best to get into the habit of assembling a filename along the
lines of
dirNameList + File.separator + fileName

rather than using
dirNameList + "/" + fileName

 

[Andreas Leitgeb]

On 11/11/2011 10:21 PM, Andreas Leitgeb wrote:
IMHO, Java errs in exposing any "path separator" at all, because
it just encourages string-bashing. Note that in some file systems
there is no such thing as a "path separator;" on one such I had
files with names like
SYS$DISK:[USERS.ERIC.PROJECT]README.TXT;22
Such beasts still exist in the wild?
$ type DISK2:[ARNE]HELLOWORLD.JAVA;1

This doesn't yet answer the "in the wild"-part: Is that a machine
still in productive use, or is it merely running under a VAX-emulator
on a PC (just for playing around)?

There are still some in production use.
The one used is hobbyist only though.

These aren't sufficient criteria for "non-obsolete" in my own dictionary

I consider it very relevant for an Java app to be able to handle
native file name syntax - after all that is what most likely
will be specified in config files and manually entered.

If a Java application making use of "/"-heuristics on filenames was deployed
to an openvms platform, then likely those who deploy it will have to explain
to the users how to specify paths for that app. That's bad luck for systems
on the waning side of their project life cycle.

 

[Andreas Leitgeb]

... but its best to get into the habit of assembling a filename along the
lines of
dirNameList + File.separator + fileName
rather than using
dirNameList + "/" + fileName

What I picked up from this semi off topic thread is, that the particular
distinction is utterly irrelevant, and the only portable (in Java's sense)
way to do file-name manipulations would be to wrap the original name in a
File object, and stick to File methods as much as possible, turning back
to a String only at the end of all the jugglings.

If portability means merely "runs on Windows and various unixoids", then
File.separator is at least better than "\\".

 

[Andreas Leitgeb]

Speaking as a person who wrote code that tried to mediate
between VMS ("structured") file names and Unix ("just glob it") paths,
I am here to tell you that there are many subtle traps. Version numbers
inevitably got garbled, if not "in translation" then "in manipulation"
on the other side of the fence. The fact that the parent directory of

SYS$DISK:[USERS.ERIC.PROJECT]README.TXT;22
was
SYS$DISK:[USERS.ERIC]PROJECT.DIR;1

baffled innumerable Unixoid programs that thought they could just "take
everything before the rightmost separator" to get the parent's name.
Anybody who thinks the mapping is half a day's work has got another
think coming -- and weeks of unplanned labor, too. I've got the scars.

I'm still wondering, how this effort was even worth it.

Dinosaur systems typically are left with the software that ran on them
since Jura, and "new SW" often means binary-patching the running
processes directly in memory, rather than deploying brand-new (i.e. less
than 10 years old) code onto them. (Not entirely serious now. ;-)

Anyway, multiplying your effort for the task with the probability of
some random code going to be deployed on openvms makes it rather
cheap after all. Cheaper than having to teach coders to write file
name manipulations portably beyond choice of separator char in the
first place.

 

[Owen Jacobson]

public class Main {
public static void main(String[] args){
File f = new File("."); // try to change the path
...

for(int i=0; i<content.length; i++){
file_array = new File("." + "\\" + content);

First of all, did you change the path also here?
or better: define a variable and use it in both spots.

Second, hardcoding "\\" is the worst approach at assembling a
file name from components. See the docu for File class for
a static field that contains the appropriate separator char
for the current platform. For test code, "/" is often good
enough (even on Windows).

Even better is to forgo the silly string-bashing and let File
figure it out:

File parentDir = ...;
File childFile = new File(parentDir, "child");

You don't need that, either, if all you're doing is enumerating
directory contents like the OP. File exposes a method for obtaining the
entries of a directory *as File objects* already, so reconstructing
File objects from the base names and parent directory is pretty much
wasted effort.

Have a look at the listFiles() method.

-o

 

[Lew]

Eric Sosman said: ....

You don't need that, either, if all you're doing is enumerating
directory contents like the OP. File exposes a method for obtaining the
entries of a directory *as File objects* already, so reconstructing
File objects from the base names and parent directory is pretty much
wasted effort.

Have a look at the listFiles() method.

-o

When quoting him, you left out the part of Eric's post that said:

 

[Eric Sosman]

Speaking as a person who wrote code that tried to mediate
between VMS ("structured") file names and Unix ("just glob it") paths,
I am here to tell you that there are many subtle traps. Version numbers
inevitably got garbled, if not "in translation" then "in manipulation"
on the other side of the fence. The fact that the parent directory of

SYS$DISK:[USERS.ERIC.PROJECT]README.TXT;22
was
SYS$DISK:[USERS.ERIC]PROJECT.DIR;1

baffled innumerable Unixoid programs that thought they could just "take
everything before the rightmost separator" to get the parent's name.
Anybody who thinks the mapping is half a day's work has got another
think coming -- and weeks of unplanned labor, too. I've got the scars.

I'm still wondering, how this effort was even worth it.

In hindsight, you're right. We should have just ditched the
VMS port of our product on the grounds that the platform was too
ugly and/or baroque and/or expensive and/or unfamiliar.

But, alas! We allowed ourselves to be influenced by the market,
instead of holding to our ideological purity. The fact that VMS was
the second most popular platform for our product (in one quarter it
actually took the top spot) caused the bean counters to insist that
we support it. Stupid bean counters!

Dinosaur systems [...]

Note that Unix is even older than VMS.

 

[Andreas Leitgeb]

[...] baffled innumerable Unixoid programs that thought they could just
"take everything before the rightmost separator" to get the parent's name.
Anybody who thinks the mapping is half a day's work has got another
think coming -- and weeks of unplanned labor, too. I've got the scars.

I'm still wondering, how this effort was even worth it.

In hindsight, you're right. We should have just ditched the
VMS port of our product on the grounds that the platform was too
ugly and/or baroque and/or expensive and/or unfamiliar.
But, alas! We allowed ourselves to be influenced by the market,
instead of holding to our ideological purity. The fact that VMS was
the second most popular platform for our product (in one quarter it
actually took the top spot) caused the bean counters to insist that
we support it. Stupid bean counters!

(I appreciate good irony)

How recent was your porting activity? (months, years or decades?)

Dinosaur systems [...]

Note that Unix is even older than VMS.

Yeah, it's also older than OS/2...

 

[Eric Sosman]

[... concerning VMS ...]

How recent was your porting activity? (months, years or decades?)

My active involvement started in the late 1980's and continued
through the mid-1990's. After I left the company in 1998, they
re-engaged me as an out-of-hours independent contractor to do yet
a little more maintenance work. So I guess the time range was
between 1.5-2.5 decades ago. VMS' development, of course, did not
end when my involvement with it ceased.

Still, my principal point is not about support of "dinosaur
systems," but that even the most modern systems we know today will
eventually be dinosaurs. The File class offers an abstraction,
which File.pathSeparatorChar promptly breaches: "Java refuses to
support any system whose file names do not consist of sequences
of component names separated by a single distinguished character."
Given that File offers ways to assemble and disassemble file names
without this knowledge, was exposing the knowledge a bright idea?
Is a programmer better off using that exposed implementation, or
sticking to the higher-level abstraction?

<Falling into a prophetic trance>: The year 2014 will see the
introduction of a brand-new paradigm for thinking about persistent
storage, one in which names cannot be so trivially encoded. By 2017,
systems based on this new scheme will have swept away all the naive
file-naming notions of Unix, MS-DOS, VMS, AIX, and VM; even URI's
will be on their way out. Will Java be part of the problem, or part
of the solution?

 

[Andreas Leitgeb]

[... concerning VMS ...]
How recent was your porting activity? (months, years or decades?)

[ Answer: essentially last century ]

Do you think, the same management would make
that decisions again nowadays for nowadays'
marketshare of VMS?

Anyway, I agree that using the abstraction that File provides
is principially better than doing one's own path-arithmetics.
I also agree, that providing the pathSeparator impedes the
abstraction.

But then again, if that weren't there, then those who don't
hardcode "\\", anyway, would probably query the OS, and do a
short if-elseif-chain for the OS's they know of to pick some
pathSeparator, or construct some File("a","b"), and somehow
(heuristically) extract the pathSeparator from that.

Sometimes, abstraction also gets into your way: how would you
model a relative path that starts with going one or more levels
up? I think to remember that MacOS (before 10) didn't have
such a concept. Did(/does) VMS?

<Falling into a prophetic trance>: The year 2014 will see the
introduction of a brand-new paradigm for thinking about persistent
storage, one in which names cannot be so trivially encoded. By 2017,
systems based on this new scheme will have swept away all the naive
file-naming notions of Unix, MS-DOS, VMS, AIX, and VM; even URI's
will be on their way out. Will Java be part of the problem, or part
of the solution?

A very good argument. I doubt, however, that even those using the
current File API in the cleanest possible way, will necessarily be
fit for those future filesystem changes.

 

[Eric Sosman]

[... concerning VMS ...]
How recent was your porting activity? (months, years or decades?)

[ Answer: essentially last century ]

Do you think, the same management would make
that decisions again nowadays for nowadays'
marketshare of VMS?

Would they decide to sell product on one of the most popular
platforms in their ecosystem? I hope so!

Would they decide to drop a platform because it would mostly
disappear within, oh, sixty-plus financial quarters? I hope not!

Anyway, I agree that using the abstraction that File provides
is principially better than doing one's own path-arithmetics.
I also agree, that providing the pathSeparator impedes the
abstraction.

Sometimes, abstraction also gets into your way: how would you
model a relative path that starts with going one or more levels
up?

File child = ...;
File parent = child.getParent();
File grandparent = parent.getParent();
...

I think to remember that MacOS (before 10) didn't have
such a concept. Did(/does) VMS?

Can't answer for MacOS. In VMS, sure: A file or directory was
either at the topmost level of its file system or it was contained
in a parent directory, and you could find the parent, and so on.

A very good argument. I doubt, however, that even those using the
current File API in the cleanest possible way, will necessarily be
fit for those future filesystem changes.

True: Java has lots of other built-in limitations that make it
unsuitable or at least uncomfortable for "advanced" (or even "large")
files. I guess the Java answer is "We'll pretend the super-files are
databases and make you go through adapters to get at them ..."

</smiley></rant> Oh, did I forget to open these?

 

[Andreas Leitgeb]

On 11/14/2011 12:38 PM, Andreas Leitgeb wrote:
[... concerning VMS ...]
How recent was your porting activity? (months, years or decades?)
[ Answer: essentially last century ]

Do you think, the same management would make
that decisions again nowadays for nowadays'
marketshare of VMS?

Would they decide to sell product on one of the most popular
platforms in their ecosystem?

If it is that, I'd finally be curious about what ecosystem
it is.

Not sure if your answer was covered by the <smilie>-tag,
or whether my question was indeed unclear.

If in a VMS-shell you're curently in directory
data:[a.b.c.d.e.f.g.h.i.j.k.l.m.n]foo.dir
and wanted to access the file
data:[a.b.c.d.e.f.g.h.i.j.k.l.m.n.bar]xyz.txt
would you need to specify the complete path to xyz.txt, or
is there some syntactic pendant to "../bar/xyz.txt" in VMS?

 

[Eric Sosman]

[...]
If in a VMS-shell you're curently in directory
data:[a.b.c.d.e.f.g.h.i.j.k.l.m.n]foo.dir
and wanted to access the file
data:[a.b.c.d.e.f.g.h.i.j.k.l.m.n.bar]xyz.txt
would you need to specify the complete path to xyz.txt, or
is there some syntactic pendant to "../bar/xyz.txt" in VMS?

Sorry; I don't remember. I *do* remember, though that there
is no such thing as being "in" a directory. VMS does not have a
Unix-oid notion of "current working directory," but instead has a
"default file specification." If you hand the system an incomplete
file name, the missing pieces are filled in from the DFS. Thus,
the resolution of incomplete names is a lexical operation, not a
"navigational" operation.

Usually this difference does not obtrude itself upon the user's
consciousness, but there are situations where it becomes important.
For example, the "data" in your example could be a "logical name"
with multiple translations: DISK1:[ANDREAS],DISK2:[READONLY], for
example. You could then tell javac to compile DATA:[.SOURCE]FOO.JAVA
and DATA:[.SOURCE]BAR.JAVA, and javac would happily find your locally-
modified DISK1:[ANDREAS.SOURCE]FOO.JAVA and the still-in-the-repository
DISK2:[READONLY.SOURCE]BAR.JAVA. It's something like the way a Unix
shell follows the PATH variable, except generalized for all files
instead of being limited just to executables.

... but note what this does to the notion of "current directory."
DATA:[.SOURCE]FOO.JAVA and DATA:[.SOURCE]BAR.JAVA have different
parent directories, DISK1:[ANDREAS] and DISK2:[READONLY], respectively.
The idea of being "in" a particular directory may not stand scrutiny.