🚀 go-pugleaf

Babak wrote:
> I had wrote some CopyFile functions in my software

<help>
If the function succeeds, the return value is nonzero.
If the function fails, the return value is zero.
To get extended error information, call GetLastError.
</help>

 >  CopyFile("profiles.DB","c:\\Portable\\profiles.DB",true);

What is the returnvalue if CopyFilefails ? And what does GetLastError
report ?

I would suggest an absolute path in the first parameter too.

Hans.

Hans Galema wrote:

> I would suggest an absolute path in the first parameter too.

Absolutely :)

One of our golden rules. Relative paths should only exist outside of
the executing image and even then they should be relative to some fixed
'anchor' file.

We also insist on directory paths having a trailing terminator at all
times. It not only helps avoid having to check first before appending
the file name but on several occasions has helped us during debugging.

-- 
Andrue Cope [TeamB]
[Bicester, Uk]
http://info.borland.com/newsgroups/guide.html

Andrue Cope [TeamB] wrote:

> We also insist on directory paths having a trailing terminator at all
> times. It not only helps avoid having to check first before appending
> the file name but on several occasions has helped us during debugging.

That is just a choice I suppose. You could as well have decided always
without. Or is there more behind it ?

Hans.

Hans Galema wrote:

> That is just a choice I suppose.
> You could as well have decided always without. Or is there more 
> behind it ?

It's part of our coding standards. Shortage of resources (ie;two
people) and size of code base (~20MB) plus the nature of our work
environment (task driven and frequently interrupted) mean that coding
and data standards are important. If a bug stops an engineer getting
their work done we have to be able to switch track and fix it as
quickly as possible. We don't have the time to relearn minutae of
source code nor to document every last detail.

Another reason is that we have had to implement path parsing functions
and by coming up with a definitive set of rules it's easier. We tend to
favour pedantic algorithms in our code. That way (in theory) the state
of an executing process is more easily predicted.

FWIW:

4.2.1. Definition:Object name
A sequence of any characters except �\� and �:�.

4.2.2. Definition:Volume ID
An object name and trailing ':'.

4.2.3. Definition:Directory path
A series of object names all of them having a trailing '\'.

4.2.4. Definition:File name
An object name appearing at the end of a directory path.

4.2.5. Definition:File name extension (informational only)
An object name that follows the rightmost �.� in a file name. 

4.2.6. Definition:Stream name
An object name following a file name and separated by ':'.

A fully qualified file path is therefore:

[<Volume ID>]\<directory path><filename>[:<stream name>]

-- 
Andrue Cope [TeamB]
[Bicester, Uk]
http://info.borland.com/newsgroups/guide.html

Andrue Cope [TeamB] wrote:

> 4.2.1. Definition:Object name
> A sequence of any characters except �\� and �:�.

So '/' is allowed.

> 4.2.2. Definition:Volume ID
> An object name and trailing ':'.
> 
> 4.2.3. Definition:Directory path
> A series of object names all of them having a trailing '\'.

C:\ape\
is not a directory path ?

> 4.2.4. Definition:File name
> An object name appearing at the end of a directory path.
> 
> 4.2.5. Definition:File name extension (informational only)
> An object name that follows the rightmost �.� in a file name. 
> 
> 4.2.6. Definition:Stream name
> An object name following a file name and separated by ':'.
> 
> A fully qualified file path is therefore:

Sorry, but you should first /define/ what a fully qualified path is,
before you show how it looks, I think.

> [<Volume ID>]\<directory path><filename>[:<stream name>]

And is this covered:
\\computername\c\apes\

Just some thoughts FWIW.

Hans.

Hans Galema wrote:

> > 4.2.1. Definition:Object name
> > A sequence of any characters except �\� and �:�.
> 
> So '/' is allowed.

No that's considered to be a post-processing feature. Again it's about
standardising. Paths while we are working on/with them have '\'. If
they need to have '/' the conversion is performed as late as possible
and is considered to be a 'fix up' operation.

> C:\ape\
> is not a directory path ?

Heh, generally we would say that it is but officially it's a volume ID
and directory path. At the moment the distinction doesn't really matter
but if we ever move development to Linux it might become more important.

> Sorry, but you should first define what a fully qualified path is,
> before you show how it looks, I think.

You could be right. Changes to our database recently and even corporate
structure mean that we are going to have to revisit our path handling
anyway. We have extensions that allow us to specify virtual files
(files within databases so a path containing two paths <g>) and a
subset for specificying devices (like the Windows \\.\ syntax) and they
haven't changed in over a decade.

> And is this covered:
> \\computername\c\apes\
> 
> Just some thoughts FWIW.

It's not, no. All our I/O is performed using the wide path form so the
'\\' would be stripped off prior to processing then added later. That
would produce a relative path so some functionality might get confused.
Normal I/O seems fine having tested it but I think some of our database
handling might a bit upset not having a volume ID.
-- 
Andrue Cope [TeamB]
[Bicester, Uk]
http://info.borland.com/newsgroups/guide.html