Re: [expath] Re: Finalizing the File Module

> It might be good to add that assumption to the spec.
> ( that implementations are required to provide a stable implementation of resolution against ".").

Sorry for the belated feedback. I’ll add this info to the spec as soon
as I get my hands on it again.

By the way, one more convenience function will be added to the
specification. It lists the full paths of the files and directories
that are found in the specified $dir:

  file:children($dir as xs:string) as xs:string*

Christian




> -----Original Message-----
> From: expath@googlegroups.com [mailto:expath@googlegroups.com] On Behalf Of Mike Sokolov
> Sent: Tuesday, March 25, 2014 9:17 AM
> To: expath@googlegroups.com
> Cc: EXPath
> Subject: Re: [expath] Re: Finalizing the File Module
>
> I guess my assumption was that an implementation would "virtualize" this entirely.  AFAICT file operations are only accessible via the file:
> API?  So it would "just" be a matter of always resolving relative paths against a fixed global working directory.  I don't mean to deny your points about the unreliability of system calls and other cwd abstractions.
>
> -Mike
>
> On 03/25/2014 09:02 AM, David Lee wrote:
>> I agree that the usefulness outweighs the system dependancy issue, and
>> that defining current-directory as the result of file:resolve-path('.') is as good as your going to get.
>>
>> as for sokolv's comment
>> " As long as it is not changeable, multitasking shouldn't cause any problems either I think."
>>
>> That is something you are going to have to hope for, not rely on.
>> Unless you virtualize your own cwd managemenet system all the way down
>> through all implementations you cannot guarantee it wont change on you, nor can you guarentee the equivalence in a mulit-threaded multi-tenancy implementation.  For example xmlsh, which acts as a host for saxon and therefore can be a host for expat may in fact change the virtualized "cwd" in any thread - but in a thread local way ... this may or may not end up as the result of file:resolve-path('.') ... depending on how *that* is implemented.  Usually it "just works right" ...  ( in my case if all dependent libraries use the Java system definition of current directory instead of the OS implementation).
>> My point in this whole conversation is to illuminate the limits and traps of "current working directory" and ideally to limit the defined behaviour from a spec perspective.
>>
>>
>>
>> -----Original Message-----
>> From: expath@googlegroups.com [mailto:expath@googlegroups.com] On
>> Behalf Of Christian Grün
>> Sent: Tuesday, March 25, 2014 6:11 AM
>> To: EXPath
>> Cc: EXPath
>> Subject: Re: [expath] Re: Finalizing the File Module
>>
>> Hi David,
>>
>> thanks for your feedback. I completely agree that it can be very risky to rely on the current working directory. In the context of an XQuery web application, for example, the working directory will usually be defined by the web server, and it is subject to change. In other environments, as you described, it may not exist at all.
>>
>> On the other hand, all file paths in the File Module that can be specified as arguments are explicitly allowed to be relative, and whenever such a relative path is specified, it will be always resolved against a "current working directory" that is (as Michael said) defined by the implementation. In my point of view, the question how useful this is mostly depends on the particular use case and the environment in which the File Module is used. Using relative paths is e. g. very handy if XQuery is used on command-line to perform file operations.
>>
>> Christian
>>
>> PS: The old description of the current-dir() function was partially incorrect. I have changed the second sentence to "This function returns the same result as the function call file:resolve-path('.')".
>> _______________________________________
>>
>> On Mon, Mar 24, 2014 at 11:42 PM, David Lee <dlee@calldei.com> wrote:
>>> I would advise against anything relying heavily on the concept of
>>> "the current directory".
>>>
>>> This is a concept that is simply not reliably portable.  As
>>> tantalizing as it is to believe in "cwd" its a fantasy of epic proportions to bet on it.
>>>
>>>
>>>
>>> Reasons:
>>>
>>> Some operating systems simply do not have the concept at all - it
>>> simply doesnt exist.
>>>
>>> In systems where "cwd" is a OS feature not all portions of a program
>>> have the same concept,
>>>
>>> for example in windows and unix the "cwd" is a process-wide setting.   Thats
>>> simply not convenient for many uses such as multi-tenancy and
>>> multi-threaded applications ... so the concept is often virtualized
>>> to support those applications.  The problem is the virtualization is
>>> not always complete - because to virtualize the CWD usually implies that different components can
>>> independently set it ... yet this is not universally supported.   Even in
>>> OS's where the "cwd" is well defined (at a process level) its amazing
>>> and surprising to discover that many libraries will actually change it on you
>>> without your knowledge - sometimes in a thread-unsafe way.   A common
>>> (legacy) method of deterring the absolute path of the current
>>> directory on unix is to keep doing a chdir("..") and storing the inodes of "." until you
>>> cant anymore then unwind the stack.   Try opening a file in a different
>>> thread via "." while this happens ... :)
>>>
>>>   ( just a FYI on unix/linux the cwd is not stored as a path its an
>>> inode and may have multiple equivalent paths).
>>>
>>>
>>>
>>> Java implementations, for example, recognize that modifying the CWD
>>> is not supportable so simply don't expose any method at all to change it.
>>> In fact the Java JRE doesnt directly support the concept of a CWD at
>>> all ... but that doesn't stop people from pretending (such as trying to get the absolute
>>> path of ".")   In xmlsh I attempt to support changing the cwd on a per-shell
>>> (which may or may not be a separate thread).  This largely but not
>>> entirely works.  It all depends on what API you use ... because I cant set the "real"
>>> CWD its virtualized ..  and only if you go through codepaths that
>>> know about this will it work.
>>>
>>>
>>>
>>> All in all ... if you want a reliable and portable file path handling
>>> I suggest you never use the current directory explicitly but rather
>>> force all file references to be resolved against an absolute path ...
>>> that is generally a supportable feature.  You can set this path in
>>> various places in your module and "call it" the "current directory"
>>> but you need to be  very careful of all the places you make
>>> assumptions about resolving paths ... do they take the system CWD (if
>>> such a thing exists? ) do they take your set CWD ? at what snapshot
>>> in "time" ? can different modules have different settings for the cwd ?
>>> Is it part of a pushed/popped environment or globally set ? What scope ?
>>>
>>> Its very compelling to pretend that the problem is easy ... but its not.
>>>
>>>
>>>
>>> -David
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> Hi Christian,
>>>
>>> I find both functions useful, especially current-dir(). It stands to
>>> reason that an XQuery application may be very interested in the
>>> current directory, in order to be able to resolve relative paths
>>> against the current dir. It should also be noted that file:list
>>> resolves relative paths against the current dir, so that subsequent
>>> use of the listed file names as URI argument in doc() simply MUST
>>> explicitly resolve against the current directory, as the implicit
>>> resolving performed by doc() is against the base URI of the query,
>>> which means the documents are not found (unless the query is contained by the current directory).
>>>
>>> Also noteworthy is that retrieval of the current directoy via
>>> file:parent requires a different argument than '.', as using '.'
>>> yields the parent directory of the current directory, rather than the
>>> current directory. This in turn means that retrieval of the current
>>> directory via file:parent requires the use of some arbitrary (and
>>> possibly fake) file name as argument, like so
>>>
>>>     file:parent('dummy')
>>>
>>> It is very desirable that retrieval of the current directory can be
>>> achieved in a straightforward way, rather than the "tricky" way via file:parent.
>>>
>>> Kind regards,
>>> Hans-Jürgen
>>>
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "EXPath" group.
>>> To unsubscribe from this group and stop receiving emails from it,
>>> send an email to expath+unsubscribe@googlegroups.com.
>>> To post to this group, send email to expath@googlegroups.com.
>>> Visit this group at http://groups.google.com/group/expath.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "EXPath" group.
>>> To unsubscribe from this group and stop receiving emails from it,
>>> send an email to expath+unsubscribe@googlegroups.com.
>>> To post to this group, send email to expath@googlegroups.com.
>>> Visit this group at http://groups.google.com/group/expath.
>>> For more options, visit https://groups.google.com/d/optout.
>> --
>> You received this message because you are subscribed to the Google Groups "EXPath" group.
>> To unsubscribe from this group and stop receiving emails from it, send an email to expath+unsubscribe@googlegroups.com.
>> To post to this group, send email to expath@googlegroups.com.
>> Visit this group at http://groups.google.com/group/expath.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
> --
> You received this message because you are subscribed to the Google Groups "EXPath" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to expath+unsubscribe@googlegroups.com.
> To post to this group, send email to expath@googlegroups.com.
> Visit this group at http://groups.google.com/group/expath.
> For more options, visit https://groups.google.com/d/optout.
>
> --
> You received this message because you are subscribed to the Google Groups "EXPath" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to expath+unsubscribe@googlegroups.com.
> To post to this group, send email to expath@googlegroups.com.
> Visit this group at http://groups.google.com/group/expath.
> For more options, visit https://groups.google.com/d/optout.

Received on Monday, 14 April 2014 19:01:03 UTC