Icon View Thread

The following is the text of the current message along with any replies.
Messages 1 to 8 of 8 total
Thread Reusing temporary directory?
Sat, Apr 20 2019 6:23 PMPermanent Link

Blake

I'm looking at some code someone wrote to set the private session directory.

(A) There's a block for creating a temporary directory in the executable path.

(B) There's a block for if the program's being run remotely, where a standard GetTempPath call is made, which is done if the program isn't being run locally.

But I can't figure out why you'd ever do (A). Is DBISAM able to reuse the same temporary path over and over again in some kind of efficiency? I mean, sure you'd have to make the directory every time you ran it, but...?
Tue, Apr 23 2019 1:09 PMPermanent Link

Tim Young [Elevate Software]

Elevate Software, Inc.

Avatar

Email timyoung@elevatesoft.com

Blake,

<< I'm looking at some code someone wrote to set the private session directory.

(A) There's a block for creating a temporary directory in the executable path.

(B) There's a block for if the program's being run remotely, where a standard GetTempPath call is made, which is done if the program isn't being run locally.

But I can't figure out why you'd ever do (A). Is DBISAM able to reuse the same temporary path over and over again in some kind of efficiency? I mean, sure you'd have to make the directory every time you ran it, but...? >>

A) is probably a hold-over from the pre-"Program Files" restrictions, ala XP and older.  From Vista on, you would probably never want to create a temporary path relative to the executable, because the executable will most likely be placed in the "Program Files" folder somewhere that will have restrictions on writes to files within that folder.

I'm not sure what you mean by "running remotely" vs. "running locally" - do you mean a remote session vs. a local session ?  With remote sessions, you don't really use local, temporary paths at all (everything is handled by the DBISAM Database Server).

Tim Young
Elevate Software
www.elevatesoft.com
Tue, Apr 23 2019 9:09 PMPermanent Link

Blake

Tim Young [Elevate Software] wrote:

>>A) is probably a hold-over from the pre-"Program Files" restrictions, ala XP and older.  From Vista on, you would probably never want to create a temporary path relative to the executable, because the executable will most likely be placed in the "Program Files" folder somewhere that will have restrictions on writes to files within that folder.<<

OK, that makes sense.

>>I'm not sure what you mean by "running remotely" vs. "running locally" - do you mean a remote session vs. a local session ?  With remote sessions, you don't really use local, temporary paths at all (everything is handled by the DBISAM Database Server).<<

No, it's all "local" in that sense. It's just that sometimes the executable is sitting on a network drive and everyone is running the same executable but mapped as "Y:\whatever". And the existing code is, "If you're running on the C-drive, use the executable's directory, but if you're NOT running on the C-drive use the temp dir that Windows is giving you."

And I'm sitting here wrestling with 11010s or 11013s. :-/
Wed, Apr 24 2019 6:45 PMPermanent Link

Raul

Globestar Systems

Team Elevate Team Elevate

On 4/23/2019 9:09 PM, Blake wrote:
> No, it's all "local" in that sense. It's just that sometimes the executable is sitting on a network drive and everyone is running the same executable but mapped as "Y:\whatever". And the existing code is, "If you're running on the C-drive, use the executable's directory, but if you're NOT running on the C-drive use the temp dir that Windows is giving you."

You can just replace it all with the temp dir version - of course make
sure it's actually a proper temp dir one can use and read/write to.


> And I'm sitting here wrestling with 11010s or 11013s. :-/

11010 means that table was not found and should be easy to eliminate -
is this error for temp tables or actual tables you have ?

11013 is the access denied one and again what is the context for this ?

Are these happening all the time or occasionally ? Any pattern ?


File shares are PITA to work with in general and in additional to
permissions etc you need to worry about things like idle connections
(windows disconnects any idle mapped drives after 15 min of inactivity etc)

Raul







Thu, Apr 25 2019 8:36 PMPermanent Link

Blake

Raul wrote:

>>You can just replace it all with the temp dir version - of course make
sure it's actually a proper temp dir one can use and read/write to.<<

Well, I'm using the Windows call, so I think I should be okay.

>>11010 means that table was not found and should be easy to eliminate -
is this error for temp tables or actual tables you have ?

11013 is the access denied one and again what is the context for this ?

Are these happening all the time or occasionally ? Any pattern ?<<

Unfortunately the pattern is "Happening to other people." I'm going to a physical location to see if I can figure it out from there.

>>File shares are PITA to work with in general and in additional to
permissions etc you need to worry about things like idle connections
(windows disconnects any idle mapped drives after 15 min of inactivity etc)<<

I'd like to get rid of it. It'd definitely be a good step, but I'm not sure how.
Fri, Apr 26 2019 4:51 PMPermanent Link

Blake

So, now I'm in the actual office and it's working fine on my actual machine.

These guys are running Windows 7 Pro, and I'm running a very stale Windows 10 personal.
Fri, Apr 26 2019 9:55 PMPermanent Link

Blake

I think it's AV. :-/
Mon, Apr 29 2019 4:17 PMPermanent Link

Tim Young [Elevate Software]

Elevate Software, Inc.

Avatar

Email timyoung@elevatesoft.com

Blake,

<< I think it's AV. :-/ >>

It's usually the case.  AV software will delete newly-created files, prevent access to files, and just, in general, wreak havoc on direct file management.  Of course, it all depends upon *where* the files are being created/deleted, just to make it a little more crazy...

Tim Young
Elevate Software
www.elevatesoft.com
Image