'file not found'

[jamesrav]

this one is particularly maddening, hopefully simple. I get an open table dialog box (which I should not get of course), can navigate to the folder, choose the file, yet get the 'file not found' error message (showing the correct path) of the file I just chose. Using the command prompt I can navigate to the folder and do a dir and the file is there. So that's the crux of the problem, here's the situation:

the files are on the their network X: drive. I can move/delete files in the folder, so they are seemingly not off limits. The screenshot (if it shows here) pretty much says it all: Command prompt shows the file existing, VFP 9 says it's not there. This is Windows 10

 

[StefanFoerner]

Hi jamesrav,

maybe the size of the network drive is the cause: 644 Giga Byte

I never used such a large network drive with Visual FoxPro ...

Regards, Stefan

 

[jamesrav]

I think for now the program will be run on the network X: drive and not on each work station as I had hoped. When run on the X: drive it seems to run fine, no File Not found errors.

 

[Olaf Doschke]

If I can read correctly, the file is in a directory called x:\hidden\data\...
Does the hidden directory have the hidden attribute set?
VFP will respect that.

? ADIR(laFiles, "x:\hidden\data\*.dbf")
Should be 0
? ADIR(laFiles, "x:\hidden\data\*.dbf","H") will count them.
But USE will not find them, too. You can't hide data from users this way.

I really mean what I said in thread184-1780751.
A user interested in a copy of all data will find its location using process monitor. Hidden directories and files are an even worse solution than what you tried initially.

Bye, Olaf.

 

[Olaf Doschke]

>I think for now the program will be run on the network X: drive and not on each workstation as I had hoped.
When you start an EXE on some client, it won't matter if that EXE is local or on a network drive, it'll run on the client.
Located on a network share it will just men the EXE is not only loaded from the drive but even transferred through the network. A file share is not a remote desktop, it doesn't let a user start something on the file server, it only shares file access, any action is still done on the client.

So I wonder of which two different methods of starting a program you're talking about.

Bye, Olaf.

 

[jamesrav]

If I can read correctly, the file is in a directory called x:\hidden\data\...
Does the hidden directory have the hidden attribute set?
VFP will respect that."

the HIDDEN directory is of course hidden, the DATA folder is not (originally was set as hidden mistakenly, but now unchecked). A command prompt listing of a hidden folder should show nothing I think (and that's how I discovered he had hidden the DATA folder by mistake), whereas my dir listing did show the file. And since what I will call the 'networked' run program has no problems determining existence of the files on it's 'own drive' (X), I don't think hidden plays a role here.

"I really mean what I said in thread184-1780751: table locations of .dbc in a networked environment. A user interested in a copy of all data will find its location using process monitor."

hopefully just hiding the DATA folder will be enough, I do now see this Process Monitor utility can discover anything ... but if users are forbidden from installing programs on their workstations, perhaps Process Monitor can be prevented from ever being used.
_____________________

"When you start an EXE on some client, it won't matter if that EXE is local or on a network drive, it'll run on the client.... So I wonder of which two different methods of starting a program you're talking about"

Yes, simply as a .exe on the network drive. I had read that slightly better performance for a local OS .exe vs. one started off a networked drive is the main reason you'd put a version on each workstation, but they've been doing it the 'networked' way for many years so it's apparently not an issue for them.
___________

I can come up with no explanation for why the local OS run program gives that error - you are saying (and it makes sense) that having both the program and data on the X: drive really is no different than the program on C: and data on X: as long as the paths are consistent. Whether it's a permission issue with Windows 10, I don't know. I have it set up exactly the same way on my computer with no problems. But it's just two Win 7 computers networked, their office situation is much more complicated certainly. Whether the previous programmer ended up doing the 'networked' .exe for this reason is unknown, it was 6 years ago. Thanks for your input.

 

[Olaf Doschke]

If the data is that valuable, that you fear people will steal it, they won't just limit themselves to what they can get free or are allowed to. If you aim for safety you should go SQL Server and it's system of granting access or not, it's much more sophisticated. Besides you don't need process monitor to see a hidden folder, you can simply configure File Explorer to show them anyway. Group Policies might prevent users from making such settings. Since you need to provide full access to DBF files, all you can do is merely comparing to a padlock.

The best you could do is encryption and on-the-fly decryption only within the process, something Cryptor provides. But the vendor and company selling that product is out of business the last time we discussed this.

If data is really valuable users might also scrape it off the single screens of data they can see at runtime, that's even true for well secured database backends.

Bye, Olaf.

 

[jamesrav]

these are good things for me to save if I want to convince the owner he needs to go further than what we are currently envisioning . Blocking via simple methods to snoop for files (no installation of programs) is a start, and a registry change can forbid users from seeing hidden folders. Somebody determined will get around it of course.