Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Directory()
158 views
Skip to first unread message
boe...@gmail.com
Nov 5, 2016, 7:07:34 AM11/5/16
to
Hi all,
I've a problem with directory() function and a clipper program on a xp virtual machine using virtual box (Oracle).
For testing and development I have created a virtual machine (xp) over my win10 64bit pc.
I've made 1 shared folder in the xp VM where both clipper sources and dbfs are (the folder is phisically on the win10 hd).
The program run smooth but when I need to use directory() function there appears a bug. I've investigated and it seems that in this case the functions works if there are 8 or less searched files in the folder. When files (eg *.dbf) are more than 8, directory() function returns an empty array.
By copying the folder, in the local disc of VM the problem disappear.
Any hints?
Regards,
Marco
I've a problem with directory() function and a clipper program on a xp virtual machine using virtual box (Oracle).
For testing and development I have created a virtual machine (xp) over my win10 64bit pc.
I've made 1 shared folder in the xp VM where both clipper sources and dbfs are (the folder is phisically on the win10 hd).
The program run smooth but when I need to use directory() function there appears a bug. I've investigated and it seems that in this case the functions works if there are 8 or less searched files in the folder. When files (eg *.dbf) are more than 8, directory() function returns an empty array.
By copying the folder, in the local disc of VM the problem disappear.
Any hints?
Regards,
Marco
_o_ceans
Nov 5, 2016, 7:30:46 AM11/5/16
to
Hi,
Afaik, I confirm there's a problem with DIRECTORY(), but it has to do with
the length of the path passed as 1st parameter; if that path is longer than
a given number of characters (not sure how many exact), then DIRECTORY()
returns an empty array; it is certainly a bug, because DOS itself supports
64 characters as path (plus additional drive letter and colon), with
additionally 12 characters for the file name (or wildcards; including the
extension dot)
I've found that making the path (that would be the 1st argument to
DIRECTORY()) the current DOS path, and querying with DIRECTORY() for a
pathless pattern, helps
f.i. instead of
DIRECTORY(
"c:\clipper5\sources\samples\myprogr\index\database\per_cat\dbf\initial\*.dbf"
)
use:
cPath := CURDIR()
DIRCHANGE(
"c:\clipper5\sources\samples\myprogr\index\database\per_cat\dbf\initial" )
// from CA-TOOLS
DIRECTORY( "*.dbf" ) // or DIRECTORY( ".\*.dbf" )
DIRCHANGE( cPath )
Personally, I switched to Klas Engwall's Long FileName library:
http://www.engwall.com/clipper/lfnlib.htm which has the LF_DIRECTORY()
function that works correctly (even if no support for LFN is available from
the OS)
CA-Clipper's DIRECTORY() (residing in EXTEND.LIB and being a .c source
program, but without the sources actually distributed) should be replaced; I
have tried to replace the 5.2e version with 5.3b's version but to no avail;
it should be replaced by a version that works correctly (within the DOS
specification of 64 characters in a path (at least))
hth,
Frank
<boe...@gmail.com> schreef in bericht
news:2a0dc366-b2a6-4a52...@googlegroups.com...
Afaik, I confirm there's a problem with DIRECTORY(), but it has to do with
the length of the path passed as 1st parameter; if that path is longer than
a given number of characters (not sure how many exact), then DIRECTORY()
returns an empty array; it is certainly a bug, because DOS itself supports
64 characters as path (plus additional drive letter and colon), with
additionally 12 characters for the file name (or wildcards; including the
extension dot)
I've found that making the path (that would be the 1st argument to
DIRECTORY()) the current DOS path, and querying with DIRECTORY() for a
pathless pattern, helps
f.i. instead of
DIRECTORY(
"c:\clipper5\sources\samples\myprogr\index\database\per_cat\dbf\initial\*.dbf"
)
use:
cPath := CURDIR()
DIRCHANGE(
"c:\clipper5\sources\samples\myprogr\index\database\per_cat\dbf\initial" )
// from CA-TOOLS
DIRECTORY( "*.dbf" ) // or DIRECTORY( ".\*.dbf" )
DIRCHANGE( cPath )
Personally, I switched to Klas Engwall's Long FileName library:
http://www.engwall.com/clipper/lfnlib.htm which has the LF_DIRECTORY()
function that works correctly (even if no support for LFN is available from
the OS)
CA-Clipper's DIRECTORY() (residing in EXTEND.LIB and being a .c source
program, but without the sources actually distributed) should be replaced; I
have tried to replace the 5.2e version with 5.3b's version but to no avail;
it should be replaced by a version that works correctly (within the DOS
specification of 64 characters in a path (at least))
hth,
Frank
<boe...@gmail.com> schreef in bericht
news:2a0dc366-b2a6-4a52...@googlegroups.com...
boe...@gmail.com
Nov 5, 2016, 8:07:51 AM11/5/16
to
Thanks for quick reply.
I replicated the problem with dbu.exe, placing the exe in the same folder of the dbfs and for sure dbu doesn't use path to read the list of files in the folder. So Directory() is buggy (as you confirm) and maybe it's buggy in its 5.3 version. It would be interesting to ask at (x)Habour group if their version is buggy free.
Regads
Marco
I replicated the problem with dbu.exe, placing the exe in the same folder of the dbfs and for sure dbu doesn't use path to read the list of files in the folder. So Directory() is buggy (as you confirm) and maybe it's buggy in its 5.3 version. It would be interesting to ask at (x)Habour group if their version is buggy free.
Regads
Marco
dlzc
Nov 5, 2016, 11:42:17 AM11/5/16
to
Dear boe...:
On Saturday, November 5, 2016 at 5:07:51 AM UTC-7, boe...@gmail.com wrote:
> I replicated the problem with dbu.exe, placing the exe
> in the same folder of the dbfs and for sure dbu doesn't
> use path to read the list of files in the folder. So
> Directory() is buggy (as you confirm) and maybe it's
> buggy in its 5.3 version. It would be interesting to ask
> at (x)Habour group if their version is buggy free.
It is buggy free, and does not require the virtual machine, since it a Windows console executable.
David A. Smith
On Saturday, November 5, 2016 at 5:07:51 AM UTC-7, boe...@gmail.com wrote:
> I replicated the problem with dbu.exe, placing the exe
> in the same folder of the dbfs and for sure dbu doesn't
> use path to read the list of files in the folder. So
> Directory() is buggy (as you confirm) and maybe it's
> buggy in its 5.3 version. It would be interesting to ask
> at (x)Habour group if their version is buggy free.
David A. Smith
boe...@gmail.com
Nov 5, 2016, 12:19:42 PM11/5/16
to
Thanks David,
so Harbour and xHarbour have fixed the bugs in directory().
I know that Harbour exes doesnt' need VM but just for curiosity (I don't use it so I'm not able to) can you test directory with Harbour in a VM accessing a shared folder in the host machine?
Regards,
Marco
dlzc
Nov 5, 2016, 4:12:00 PM11/5/16
to
Dear boe...:
On Saturday, November 5, 2016 at 9:19:42 AM UTC-7, boe...@gmail.com wrote:
> so Harbour and xHarbour have fixed the bugs in directory().
>
> I know that Harbour exes doesnt' need VM but just for
> curiosity (I don't use it so I'm not able to) can you test
> directory with Harbour in a VM accessing a shared folder in
> the host machine?
No I cannot, since I don't have any virtual machines. I use xHarbour in network shared directories, to generate a list of movies.
David A. Smith
On Saturday, November 5, 2016 at 9:19:42 AM UTC-7, boe...@gmail.com wrote:
> so Harbour and xHarbour have fixed the bugs in directory().
>
> I know that Harbour exes doesnt' need VM but just for
> curiosity (I don't use it so I'm not able to) can you test
> directory with Harbour in a VM accessing a shared folder in
> the host machine?
David A. Smith
boe...@gmail.com
Nov 5, 2016, 7:17:40 PM11/5/16
to
Ok, no problem. I think that the bug raises only in VM with shared folders (at least it happens to me), so the only way to determine if it's only a personal problem or a general one is to have the same environment.
Regards,
Marco
Regards,
Marco
dlzc
Nov 5, 2016, 9:55:56 PM11/5/16
to
Dear boe...:
On Saturday, November 5, 2016 at 4:17:40 PM UTC-7, boe...@gmail.com wrote:
Like the joke where the man says "Doctor, it hurts when I do this." Doctor says, "Well, don't do that!"
You don't need a virtual machine with a Windows program. It runs in Windows, and uses Windows resource.
David A. Smith
On Saturday, November 5, 2016 at 4:17:40 PM UTC-7, boe...@gmail.com wrote:
Like the joke where the man says "Doctor, it hurts when I do this." Doctor says, "Well, don't do that!"
You don't need a virtual machine with a Windows program. It runs in Windows, and uses Windows resource.
David A. Smith
boe...@gmail.com
Nov 6, 2016, 7:38:45 AM11/6/16
to
I was talking of a Clipper exe, not Harbour's one. I know that Harbour builds exes that doesn't need a VM but I was using Clipper and the problem is Clipper related. Said that, I think that in the future I will recompile all my sources with Harbour but I need to solve this problem as soon as possible, because I've several apps running in VMs. The easiest way is to move the shared folder content directly in the VM hard disk, but some months ago one of my customers left the whole VM because of a nightly (unrequested) upgrade from Win7 to Win10.
Regards,
Marco
Regards,
Marco
dlzc
Nov 6, 2016, 1:04:55 PM11/6/16
to
Dear boe...:
On Sunday, November 6, 2016 at 5:38:45 AM UTC-7, boe...@gmail.com wrote:
> I was talking of a Clipper exe, not Harbour's one.
OK. T^he only help I can offer, is to keep the path names under 64 characters, as previously stated.
Depending on what VM you use, some variant of "net use" might be able to assign drive letters to longer path names...
David A. Smith
On Sunday, November 6, 2016 at 5:38:45 AM UTC-7, boe...@gmail.com wrote:
> I was talking of a Clipper exe, not Harbour's one.
Depending on what VM you use, some variant of "net use" might be able to assign drive letters to longer path names...
David A. Smith
_o_ceans
Nov 6, 2016, 1:15:00 PM11/6/16
to
Hi,
What guest OS are you using in the VM?
If it's an OS (such as DOS) that doesn't recognize NTFS well, mind that DOS
<= 6.x only supports FAT16 (maximum 2Gb partitions) and DOS 7+ only FAT32
(maximum 32Gb partitions)
There are NTFS drivers for DOS, but none are working properly; the only way
to access host OS NTFS partitions would be to setup a network share from the
guest OS (even if the Host OS' partitions could be made available to the
guest OS, such as VMWare Workstation allows; in the latter case, you can do
so (for DOS 7+) when the Host OS' partition is a FAT32 partition (no bigger
than 32Gb as said))
hth
news:ca4fa37a-9ad4-45c6...@googlegroups.com...
What guest OS are you using in the VM?
If it's an OS (such as DOS) that doesn't recognize NTFS well, mind that DOS
<= 6.x only supports FAT16 (maximum 2Gb partitions) and DOS 7+ only FAT32
(maximum 32Gb partitions)
There are NTFS drivers for DOS, but none are working properly; the only way
to access host OS NTFS partitions would be to setup a network share from the
guest OS (even if the Host OS' partitions could be made available to the
guest OS, such as VMWare Workstation allows; in the latter case, you can do
so (for DOS 7+) when the Host OS' partition is a FAT32 partition (no bigger
than 32Gb as said))
hth
news:ca4fa37a-9ad4-45c6...@googlegroups.com...
boe...@gmail.com
Nov 6, 2016, 2:38:41 PM11/6/16
to
Hi,
I'm using XP sp3 Home as guest and Win10 ad Host. As I said the problem is only (as far as I know now) with directory() function that doesn't detected more than 8 files per mask (*.dbf *.ntx ....). When I use IO functions like DBUseArea(...) or other I don't have any problem: the files are opened and updated, the records deleted, inserted, etc. So I guess it's a problem with the directory() function and Oracle VirtualBox, not in the shared folder itself, nor in the path lenght. I was asking if someone using a VM under VirtualBox could reproduce the problem.
Regards,
Marco
I'm using XP sp3 Home as guest and Win10 ad Host. As I said the problem is only (as far as I know now) with directory() function that doesn't detected more than 8 files per mask (*.dbf *.ntx ....). When I use IO functions like DBUseArea(...) or other I don't have any problem: the files are opened and updated, the records deleted, inserted, etc. So I guess it's a problem with the directory() function and Oracle VirtualBox, not in the shared folder itself, nor in the path lenght. I was asking if someone using a VM under VirtualBox could reproduce the problem.
Regards,
Marco
boe...@gmail.com
Nov 6, 2016, 2:42:13 PM11/6/16
to
Hi,
I tried with short path (under the root) and the problem is the same. I guess that is a conflict (or anything similar) between Oracle VirtualBox and directory() function.
Regards,
Marco
I tried with short path (under the root) and the problem is the same. I guess that is a conflict (or anything similar) between Oracle VirtualBox and directory() function.
Regards,
Marco
_o_ceans
Nov 6, 2016, 2:49:24 PM11/6/16
to
Hi again,
If you are using dbu to sort out the cause (instead of just switching to
LF_DIRECTORY() in your sources), the next link might be relevant .oO just
eliminating misunderstandings
http://www.tek-tips.com/viewthread.cfm?qid=1733627
It contains a patch to CA-Clipper 5.2e dbu sources; afair, specificly for
dbu there was a need to compensate the total of files that can be read
(array cannot be >4096 elements), but that patch relies on LF_DIRECTORY()
What exactly do you expect? DIRECTORY() _is_ buggy, whereas LF_DIRECTORY()
is all you need to replace it!
news:f129826f-2f80-4ed8...@googlegroups.com...
If you are using dbu to sort out the cause (instead of just switching to
LF_DIRECTORY() in your sources), the next link might be relevant .oO just
eliminating misunderstandings
http://www.tek-tips.com/viewthread.cfm?qid=1733627
It contains a patch to CA-Clipper 5.2e dbu sources; afair, specificly for
dbu there was a need to compensate the total of files that can be read
(array cannot be >4096 elements), but that patch relies on LF_DIRECTORY()
What exactly do you expect? DIRECTORY() _is_ buggy, whereas LF_DIRECTORY()
is all you need to replace it!
news:f129826f-2f80-4ed8...@googlegroups.com...
_o_ceans
Nov 6, 2016, 3:00:46 PM11/6/16
to
Sorry, I cannot test such setup - VirtualBox continuously improves with each
version, perhaps it might get solved if reported with them
I suppose your guest os has its config.nt FILES= setting high enough (not
sure whether this applies to the issue at hand)
news:f129826f-2f80-4ed8...@googlegroups.com...
version, perhaps it might get solved if reported with them
I suppose your guest os has its config.nt FILES= setting high enough (not
sure whether this applies to the issue at hand)
news:f129826f-2f80-4ed8...@googlegroups.com...
boe...@gmail.com
Nov 6, 2016, 3:52:11 PM11/6/16
to
Hi,
first of all, thank you David and Frank for your time.
I managed to create a new VM under WMWare. I exported the VirtualBox XP VM, updated VMWare Tools and started my new VM under WMWare. I'm not very familiar with WmWare and I prefer VirtualBox (I don't recall but I've had troubles in the past). So after a long configuration and the creation of 2 shared folders, using VMWare configuration settings, I tested my exe (and dbu): the problem with directory() using WMWare disappears !
So the bug it's not in directory() function (that is buggy in other fields) but in the VirtualBox management of shared folders.
Regards,
Marco
first of all, thank you David and Frank for your time.
I managed to create a new VM under WMWare. I exported the VirtualBox XP VM, updated VMWare Tools and started my new VM under WMWare. I'm not very familiar with WmWare and I prefer VirtualBox (I don't recall but I've had troubles in the past). So after a long configuration and the creation of 2 shared folders, using VMWare configuration settings, I tested my exe (and dbu): the problem with directory() using WMWare disappears !
So the bug it's not in directory() function (that is buggy in other fields) but in the VirtualBox management of shared folders.
Regards,
Marco
_o_ceans
Nov 6, 2016, 3:57:47 PM11/6/16
to
Glad you discerned the circumstances where it leads to a fault (reporting it
might be cumbersome, but the VirtualBox project has a forum for that, as you
pbly know)
Best regards,
news:d38eae11-47f5-4f10...@googlegroups.com...
might be cumbersome, but the VirtualBox project has a forum for that, as you
pbly know)
Best regards,
news:d38eae11-47f5-4f10...@googlegroups.com...
0 new messages