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.

Received on Tuesday, 25 March 2014 10:11:51 UTC