Michael G Schwern wrote:
On Fri, Sep 30, 2005 at 12:25:04PM -0400, John E. Malmberg wrote:
The current interface is good enough for the default filesystem, I
guess, but you should be able to ask about a specific file system,
e.g.:
my $x = File::System::Spec->new(File::Spec->catfile(.. the path
...));
$x->case_tolerant; # asks about the filesystem hosting the path
I envisioned that this module would be for setting or reading
properties, so a 'new' method does not seem to fit in with that.
A new definately fits in because there is more than one file system on a
system, thus more than one object. Starting out from scratch with the
assumption that there is only one filesytem to worry about deliberately
cripples the interface.
And if nothing else it means you don't have to write File::System::Spec
over and over and over and over again.
I misunderstood the meaning of the new method. I see now that it
returns a new storage variable with the properties underneath it.
I do not know how to have vms.c override the new method because it may
not know about properties that have been added since the last update to
vms.c.
Would a push and pop methods also be needed to allow saving and
restoring of the properties before a change?
And I expect that more methods to expose properties of file systems will
end up being added to this module as the maintainers of other platforms
add their contributions.
I think we need to coordinate because I already have started this module,
too and I have a *really* good idea of the sorts of things I need to know.
http://svn.schwern.org/svn/CPAN/File-System-Spec/trunk/lib/File/System/Spec.pm
That describes for the current values.
What is probably also needed is the ability to also get the following:
A. The values to work with any file system on the platform.
B. The values that can be changed for a specific file system / platform
C. The minimum values that can be set for a file system / platform.
D. The maximum values that can be set for a file system / platform.
E. The normal default values for a file system/platform.
For some of the properties, there needs to be a way to indicate that the
answer is not known, or not applicable.
And of course just because a file system has those properties does not
mean that the Perl on that platform can handle them, which is currently
the case on VMS.
For example, the ODS-5 file system has support for hard links before
8.2, but the 8.2 operating system is the only one that allows obtaining
that information.
And prior to that it supported the ability to have multiple filenames
point to the same file on the disk, but that feature was not 100%
compliant with the expectations of POSIX program for hard links, but was
good enough for most uses of it.
So a property of "posix_hardlinks" may be useful in addition.
The "is_versioning" also applies to the ISO-9660 file system for CD-ROMS
even though that I am not aware of any operating system other than VMS
that can access the older versions.
The table at the following URL shows a few other properties that Perl
scripts may need to know about.
http://h71000.www7.hp.com/doc/82FINAL/5763/5763pro_003.html#feature_logicals_sec
Many of them are special case things that Perl on VMS is already taking
care of, and total flexibility of supporting all the options is probably
not needed, many of them are fine tuning on the degree of UNIX behavior.
And many of the options are mutually exclusive. And some of them only
exists to provide backwards compatibility with what has turned out to be
an incorrect behavior.
My simplified list from that would be these:
remove_open_files - Open Files can be unlinked.
wide_file_names - 16 bit wide unicode file names supported. (Can
Perl even deal with these now?)
unix_umask_behavior - Support UNIX umask behavior.
And what type of timeframe is planned for this, as it is blocking my
getting Perl on VMS to support the current features of the ODS-5 file
system.
-John
[EMAIL PROTECTED]
Personal Opinion Only
