Hi,

I am about to upgrade to version 4.35 (currently on 4.34). We are experiencing an issue regarding file permissions (not using Client Server option - ie. no dbisam server running). Upon creating a new table (file) whilst running the application as an administrator, windows seems to place a LOCK icon on the file (due to NTFS permissions not being inherited from the parent folder - this tick box remains unticked in advanced security tab). When accessing the files over, say, a mapped drive, the permission inherit correctly.

Are you aware of this problem - I did not see any release notes in 4.35 relating to this.

Many thanks!
Danie

Hendrik

DBISAM does not change any file permissions in both cases (F/S or C/S).

My tip is about review Windows security permissions on that folder.
You can try a FULL ACCESS to check if the problem is gone and if so, then
the problem is related with windows permissions.

Eduardo

Danie,

<< I am about to upgrade to version 4.35 (currently on 4.34). We are
experiencing an issue regarding file permissions (not using Client Server
option - ie. no dbisam server running). Upon creating a new table (file)
whilst running the application as an administrator, windows seems to place a
LOCK icon on the file (due to NTFS permissions not being inherited from the
parent folder - this tick box remains unticked in advanced security tab).
When accessing the files over, say, a mapped drive, the permission inherit
correctly.

Are you aware of this problem - I did not see any release notes in 4.35
relating to this. >>

DBISAM doesn't alter any permissions or security settings for any files that
it creates, so they will receive the default permissions for the user/parent
directory.  Are you sure that you aren't altering the table at all ?
Altering a table can run into issues with permissions, as described below:

http://www.elevatesoft.com/bulletins?action=view&category=dbisam&bulletin=windows_xp_file_sharing

If you have any other questions, please let me know.

Tim Young
Elevate Software
www.elevatesoft.com

Hi Tim,

reading your link now. Will check the details.

I am not altering the table thought. I delete the table for testing purposes and then recreate it (CreateTable).
On version 4.34 this results in the table no inheriting permissions from the parent folder. I have upgraded to 4.35 and the problem now seems to be gone.

Our official software releases are still running on 4.29 - which also has no problems.

I will fine-comb the code to see that we are not altering anything in the table structures and will check the session temp folder permissions as well. If you do find any reasons for the above, please let me know.

Kindest Regards
Danie

Danie,

<< I am not altering the table thought. I delete the table for testing
purposes and then recreate it (CreateTable). On version 4.34 this results in
the table no inheriting permissions from the parent folder. I have upgraded
to 4.35 and the problem now seems to be gone. >>

Hmm, I'm not aware of any changes to any of the releases since 4.29 that
would affect this, so I'm not sure what is going on.

Tim Young
Elevate Software
www.elevatesoft.com

Not sure if this is related, but I've been using EWB and DBISAM recently on a
Windows 2008 server, and have had similar issues. Files I create while logged on as
admin on the server have some sort of access control set. I cannot write to them
from the share. If I delete them, then I can create them okay. This is not just
DBISAM but html and other files too. I've not bothered to work it out - I just do
it all on the share now.

/Matthew Jones/

Matthew,

<< Not sure if this is related, but I've been using EWB and DBISAM recently
on a Windows 2008 server, and have had similar issues. Files I create while
logged on as admin on the server have some sort of access control set. I
cannot write to them from the share. If I delete them, then I can create
them okay. This is not just DBISAM but html and other files too. I've not
bothered to work it out - I just do it all on the share now. >>

I'm wondering if Windows is now setting extended security attributes based
upon the source of the creation.  I'll have to look into this further.

Thanks,

Tim Young
Elevate Software
www.elevatesoft.com

Hi Guys,

did you guys ever have a chance to look into this again. I got a small scare this morning with a client on 4.35 of DBISAM (new installation - first upgrade of their data to 4.35 from 4.29). I don't want to jump to conclusions so figured I'd ask whether there was any new news on this issue.

Kindest Regards
Danie

Danie,

<< did you guys ever have a chance to look into this again. I got a small
scare this morning with a client on 4.35 of DBISAM (new installation - first
upgrade of their data to 4.35 from 4.29). I don't want to jump to
conclusions so figured I'd ask whether there was any new news on this issue.
>>

No, I haven't had a chance to look at it yet.  Just so you know, there's not
much that I can do about it, even if it does turn out that Windows is doing
something funky with the permissions.  DBISAM cannot just change file
permissions/ownership whenever it feels like it - that's up to the OS/system
admin/user to manage.

Tim Young
Elevate Software
www.elevatesoft.com

Fully understood.

Thanks for the reply.
Danie

"Tim Young [Elevate Software]" wrote:

Danie,

<< did you guys ever have a chance to look into this again. I got a small
scare this morning with a client on 4.35 of DBISAM (new installation - first
upgrade of their data to 4.35 from 4.29). I don't want to jump to
conclusions so figured I'd ask whether there was any new news on this issue.
>>

No, I haven't had a chance to look at it yet.  Just so you know, there's not
much that I can do about it, even if it does turn out that Windows is doing
something funky with the permissions.  DBISAM cannot just change file
permissions/ownership whenever it feels like it - that's up to the OS/system
admin/user to manage.

Tim Young
Elevate Software
www.elevatesoft.com