On Thu, Sep 12, 2013 at 12:01:30PM +0200, Reimar Grabowski wrote:
> On Thu, 12 Sep 2013 07:10:19 +0200 Jürgen Hestermann
> wrote:
>
> > Ahh, that's the reason: It's (another) sloppiness in Unix systems
> > and has creeped into Windows from there.
> Unfortunately M$ hasn't implemented it correctly
On Thu, 12 Sep 2013 07:10:19 +0200
Jürgen Hestermann wrote:
> Ahh, that's the reason:
> It's (another) sloppiness in Unix systems and has creeped into Windows from
> there.
Unfortunately M$ hasn't implemented it correctly (like always) and enriched the
experience with their common inconsistenci
Am 2013-09-11 19:36, schrieb Reimar Grabowski:
IEEE Std 1003.1, 2004 Edition (http://pubs.opengroup.org/onlinepubs/009695399/)
says: 3.266 Pathname A character string that is used to identify a file. In the
context of IEEE Std 1003.1-2001, a pathname consists of, at most, {PATH_MAX}
bytes, in
On Windows, too:
C:\>cd \backup\\\///\\\sich
C:\backup\sich>
Only the first backslash has to be (only one) backslash;
no slash allowed.
Kind regards
Bernd
Am 11.09.2013 19:36, schrieb Reimar Grabowski:
On Wed, 11 Sep 2013 17:37:36 +0200
Jürgen Hestermann wrote:
And double delimiters *a
On Wed, 11 Sep 2013 17:37:36 +0200
Jürgen Hestermann wrote:
> And double delimiters *are* ambiguous:
> Has a (one letter) file name been forgotten or was an additional
> delimiter typed (or appended by bad programmed routines)?
Ambiguity is not defined by how the symbol came into being. You just
Am 2013-09-11 10:04, schrieb Mattias Gaertner:
> Many webservers are running on Linux, where double path delims are
> pretty normal. You see them pretty often. A common cause are lines like
> this:
> File=$Directory/filename.ext
> You don't need to check if $Directory has already a '/' at the end,
On Tue, 10 Sep 2013 20:30:16 -0400
wrote:
> On Tuesday, September 10, 2013 11:35 AM, Jürgen Hestermann
> wrote:
> > Am 12013090922:28, schrieb Tomas Hajny:
> > > ...and the issue is that at least some Windows API functions happily
> > accept
> > such paths,
> > > i.e. programs using such
On Tuesday, September 10, 2013 11:35 AM, Jürgen Hestermann
wrote:
> Am 12013090922:28, schrieb Tomas Hajny:
> > ...and the issue is that at least some Windows API functions happily
> accept
> such paths,
> > i.e. programs using such API functions accept them too.
> > If FPC RTL manages t
Am 2013-09-09 22:28, schrieb Tomas Hajny:
> ...and the issue is that at least some Windows API functions happily accept
such paths,
> i.e. programs using such API functions accept them too.
> If FPC RTL manages to "translate" a path accepted by Windows
> (and other programs not compiled to FPC to
On Mon, September 9, 2013 18:55, Sven Barth wrote:
> On 09.09.2013 18:31, Jürgen Hestermann wrote:
>>
>> Am 2013-09-08 19:56, schrieb Sven Barth:
>>> On 08.09.2013 10:44, Jürgen Hestermann wrote:
In my many decades of MS experience I never have seen double path
delimiters anywhere. How do
Am 2013-09-08 19:56, schrieb Sven Barth:
On 08.09.2013 10:44, Jürgen Hestermann wrote:
In my many decades of MS experience I never have seen double path
delimiters anywhere. How do you generate them? I would not know how to do it.
Windows Explorer does not allow them, because it uses the long
On 09.09.2013 18:31, Jürgen Hestermann wrote:
Am 2013-09-08 19:56, schrieb Sven Barth:
On 08.09.2013 10:44, Jürgen Hestermann wrote:
In my many decades of MS experience I never have seen double path
delimiters anywhere. How do you generate them? I would not know how
to do it.
Windows Explorer
Am 09.09.2013 14:34, schrieb Mattias Gaertner:
On Mon, 09 Sep 2013 13:25:31 +0200
Sven Barth wrote:
[...]
Actually the problem is that Windows has multiple current directories,
but you can only read the one of the active drive.
This. Is. Wrong.
If the GetFullPathName works, I'm glad that I
On Mon, 09 Sep 2013 13:25:31 +0200
Sven Barth wrote:
>[...]
> > Actually the problem is that Windows has multiple current directories,
> > but you can only read the one of the active drive.
> This. Is. Wrong.
If the GetFullPathName works, I'm glad that I was wrong. :)
Mattias
_
Am 09.09.2013 13:47, schrieb Sven Barth:
Am 09.09.2013 13:31, schrieb Sven Barth:
Am 08.09.2013 22:32, schrieb Tomas Hajny:
On Sun, September 8, 2013 19:32, Sven Barth wrote:
On 08.09.2013 14:17, Bart wrote:
On 9/8/13, Tomas Hajny wrote:
Why do you believe that ExpandFilename is not threads
Am 09.09.2013 13:25, schrieb Sven Barth:
Am 08.09.2013 22:13, schrieb Mattias Gaertner:
On Sun, 08 Sep 2013 19:32:23 +0200
Sven Barth wrote:
On 08.09.2013 14:17, Bart wrote:
On 9/8/13, Tomas Hajny wrote:
Why do you believe that ExpandFilename is not threadsafe (on
Windows or
any other pl
Am 09.09.2013 13:31, schrieb Sven Barth:
Am 08.09.2013 22:32, schrieb Tomas Hajny:
On Sun, September 8, 2013 19:32, Sven Barth wrote:
On 08.09.2013 14:17, Bart wrote:
On 9/8/13, Tomas Hajny wrote:
Why do you believe that ExpandFilename is not threadsafe (on
Windows or
any other platform)?
Am 08.09.2013 22:32, schrieb Tomas Hajny:
On Sun, September 8, 2013 19:32, Sven Barth wrote:
On 08.09.2013 14:17, Bart wrote:
On 9/8/13, Tomas Hajny wrote:
Why do you believe that ExpandFilename is not threadsafe (on Windows or
any other platform)?
..
The only platform specific part inside
Am 08.09.2013 22:13, schrieb Mattias Gaertner:
On Sun, 08 Sep 2013 19:32:23 +0200
Sven Barth wrote:
On 08.09.2013 14:17, Bart wrote:
On 9/8/13, Tomas Hajny wrote:
Why do you believe that ExpandFilename is not threadsafe (on Windows or
any other platform)?
[...]
And that is exactly the po
On Sun, September 8, 2013 19:21, Bart wrote:
> On 9/8/13, Tomas Hajny wrote:
.
.
>> Good, thanks for the pointer. We may indeed want to add some safeguards
>> to
>> the Windows GetDir implementation (or possibly check some alternative
>> solution for finding out the current directory on other dr
On Sun, September 8, 2013 19:32, Sven Barth wrote:
> On 08.09.2013 14:17, Bart wrote:
>> On 9/8/13, Tomas Hajny wrote:
>>
>>> Why do you believe that ExpandFilename is not threadsafe (on Windows or
>>> any other platform)?
>> ..
>>> The only platform specific part inside
>>> ExpandFilename is a ca
On Sun, 08 Sep 2013 19:32:23 +0200
Sven Barth wrote:
> On 08.09.2013 14:17, Bart wrote:
> > On 9/8/13, Tomas Hajny wrote:
> >
> >> Why do you believe that ExpandFilename is not threadsafe (on Windows or
> >> any other platform)?
>[...]
> > And that is exactly the point.
> > GetDir calls GetCuren
On 08.09.2013 10:44, Jürgen Hestermann wrote:
Am 2013-09-07 21:46, schrieb Bart:
> On 9/7/13, Jürgen Hestermann wrote:
>> Of course! Why the hell should there be double pathdelims? And why
>> (silently) accept them as if they were one?
> There should not be, but (history: DOS and) WinApi acc
On 08.09.2013 15:29, Tomas Hajny wrote:
of ExpandFilename - well, that may be the case, but that is not special
for Windows and it should be the responsibility of the programmer either
not to change the current directory in other threads,
But GetDir just does that: it changes the current direct
On 08.09.2013 14:17, Bart wrote:
On 9/8/13, Tomas Hajny wrote:
Why do you believe that ExpandFilename is not threadsafe (on Windows or
any other platform)?
..
The only platform specific part inside
ExpandFilename is a call to GetDir function retrieving the current
directory. If that is not '
On 9/8/13, Tomas Hajny wrote:
> OK, I'll have a look at the MSDN link once I sit at some machine with a
> bigger display than my phone.
;-)
> Good, thanks for the pointer. We may indeed want to add some safeguards to
> the Windows GetDir implementation (or possibly check some alternative
> so
On 9/8/13, Jürgen Hestermann wrote:
> It also says there that multithreaded applications should not use relative
> paths.
> It seems that WinAPI functions which allow relative paths suffer from the
> same problem:
> They have to call GetCurrentDirectory too and are therefore not thread-safe
> eit
On Sun, September 8, 2013 14:17, Bart wrote:
> On 9/8/13, Tomas Hajny wrote:
>
>> Why do you believe that ExpandFilename is not threadsafe (on Windows or
>> any other platform)?
> ..
>> The only platform specific part inside
>> ExpandFilename is a call to GetDir function retrieving the current
>>
Am 2013-09-08 14:17, schrieb Bart:
> And that is exactly the point.
> GetDir calls GetCurentDirectory and MS says (see:
>
http://msdn.microsoft.com/en-us/library/windows/desktop/aa364934%28v=vs.85%29.aspx)
> that multithreaded applications should not call GetCurrentDirectory.
It also says there
On 9/8/13, Tomas Hajny wrote:
> Why do you believe that ExpandFilename is not threadsafe (on Windows or
> any other platform)?
..
> The only platform specific part inside
> ExpandFilename is a call to GetDir function retrieving the current
> directory. If that is not 'threadsafe' by itself (on Wi
On Sat, September 7, 2013 18:49, Bart wrote:
.
.
> You would also not be able to open files with a relative path:
> FileExists('foo\bar.txt') wil then internally be translated to "Ask
> the WinApi if '\\?\foo\bar.txt' exists", and this will fail, since the
> '\\?\' scheme needs a fully qualified
Am 2013-09-07 21:46, schrieb Bart:
> On 9/7/13, Jürgen Hestermann wrote:
>> Of course! Why the hell should there be double pathdelims? And why
>> (silently) accept them as if they were one?
> There should not be, but (history: DOS and) WinApi accept them, so the
> are NOT illegal in normal filena
>[...]
> This is especially a problem with Lazarus (the IDE itself), where
> config files and include directives may contain '/', or are defined as
> relative paths.
Filenames from other platforms have to be converted by the application (here:
Lazarus IDE) before passing them to RTL file function
On 9/7/13, Jürgen Hestermann wrote:
> Of course! Why the hell should there be double pathdelims? And why
> (silently) accept them as if they were one?
There should not be, but (history: DOS and) WinApi accept them, so the
are NOT illegal in normal filenames.
> '/' etc, because these are illega
Am 2013-09-07 18:49, schrieb Bart:
> That would be wrong.
> Prepending wiht '\\?\ means that everything should be taken literally,
> so trying to open/read etc. through WinApi will fail if filename
> contains double pathedlims,
Of course! Why the hell should there be double pathdelims? And why (s
On 9/7/13, Jürgen Hestermann wrote:
> Am 2013-09-07 12:52, schrieb Bart:
>
> > Note that '//?/C:/foo/bar' in contrast happily opens 'C:\foo\bar'
> > (nice touch from M$).
>
> Why is this a "nice touch"? IMO it is crap.
You missed the intended sarcasme sign. ;-)
>
> In general I would prefer
Am 2013-09-07 18:07, schrieb Sven Barth:
> The "\\?\" paths don't support relative paths
Then relative paths need to be expanded internally before use. If I have a
deeply nested directory structure with paths longer than 255 characters then
relative paths should work the same as when having sho
Am 07.09.2013 16:19 schrieb "Jürgen Hestermann" :
> > My question is: should DoDirSeparators handle this case and leave the
> > filename untouched if it starts with '\\?\', or should we leave it up
> > to the programmer not calling functions like ExpandFilename if a
> > filename starts with '\\?\'
Am 2013-09-07 12:52, schrieb Bart:
> Note that '//?/C:/foo/bar' in contrast happily opens 'C:\foo\bar'
> (nice touch from M$).
Why is this a "nice touch"? IMO it is crap. This kind of inconsistencies in MS
programs lead to false assumptions and mislead the user (programmer). If characters are
Hi,
This is a folowup off a discussion in LazarusDev mailinglist.
It concerns "sanitizing" filenames on the Windows platform.
The Windows API for handling filenames in most cases happily accepts
filenames that have '/' in them. It treats '/' as a pathdelimiter.
It also is very forgiving in using
40 matches
Mail list logo
