[harbour/core] 2834f7: should hb_DirBuild(), etc. use VF API

[Aleksander Czajczynski]

'alcz' via Harbour Commits wrote:
> Log Message:
> -----------
> 2021-04-12 21:18 UTC+0200 Aleksander Czajczynski (hb fki.pl)
> * src/rtl/hbfilehi.prg
> * hb_DirBuild() will now honor UNC "\\server\share\dir\tree" parameter
> on Windows and correctly create specified "\dir\tree" on remote
> server. If your code used a malformed "\\local\path" a regression
> in .prg code may happen on Windows. Previously a "\local\path"
> folder was created on current drive, as if the UNC specifier was
> omitted. It was more or less consistent with other platforms but
> not expected for this platform. Spotted by Maurizio la Cecilia (#233)
> [INCOMPATIBLE]
>
Hi!

I wanted to merge also 3.4 cleanups to this but found out, that 3.2
hb_DirBuild() uses plain OS file API, where 3.4 has calls Harbour VF
API. Please help to make a decision if we should merge this or create
separate hb_vfDirBuild(), hb_vfDirUnbuild(). I'd sligthly prefer
separate funcs - to keep OS path access plain, but don't like such
code/functionality duplication either.

Best regards, Aleksander

[Klas Engwall]

Hi Alexander,

I would also prefer the separate functions, especially since all the
other VF functions are separate from their non-VF siblings. We have code
and functionality duplication in many places in Harbour so it wouldn't
really be a new "problem" to do it like that in this case too.

Regards,
Klas

[Maurizio la Cecilia]

Hi Aleksander,

many thanks for the fix.

About your question, I agree with Klas.

--

Maurizio

--
You received this message because you are subscribed to the Google Groups "Harbour Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to harbour-deve...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/harbour-devel/6074A28E.9010009%40fki.pl.

[Aleksander Czajczynski]

Maurizio la Cecilia wrote:
> Hi Aleksander,
> many thanks for the fix.
> About your question, I agree with Klas.

Hey!

Thanks to both of you. I've prepared a patch now, albeit there is one(?)
function that at least partially uses VF FILE under the name hb_FCopy().
I assume that there is a good reason for this. Though it can act in a
bit differently than hb_vfCopy() - there is a Przemyslaw's description
in the ChangeLog. The .c source behind this: hb_fsCopy is a fallback for
hb_fileCopy if the latter can't do optimized (for example server-side) copy.

See the attachement that adds hb_vfDirBuild(), hb_vfDirUnbuild() and
hb_vfNameExists() - if there are no other doubts, i'll commit it.

Best regards, Aleksander

[Maurizio la Cecilia]

Hi Aleksander,
I tested your patch and all seems to work flawlessly.
IMHO it's ok to commit.
Thanks again and best regards.
--
Maurizio

PS: Not a doubt, but just a curiosity: why not to use extensively
hb_LeftEq() instead of Left() == ?

[Aleksander Czajczynski]

Maurizio la Cecilia wrote:
> I tested your patch and all seems to work flawlessly.
> IMHO it's ok to commit.
> Thanks again and best regards.
>

> PS: Not a doubt, but just a curiosity: why not to use extensively
> hb_LeftEq() instead of Left() == ?

True. For me it will take ages to get used to hb_LeftEq() as first
candidate. Wouldn't help here that the code already had some "Left() ==".
There is more place for extensions in the hb_vfDirBuild() variant, as it
supports more virtual fs prefixes. But i'm not even sure how to test
that, maybe current hb_osPathSeparator checks are enough.

Thanks for the tests.

Best regards, Aleksander