How to lock out a file or path from within a Delphi app?

what about a different approach :


encrypt and decrpyt that file ....    effect is comparable as the access controll

Lock and Unlock is good but I concur with Bdlm, Since you can lock the folder and its on the server, somebody else can unlock it too.

Decrypt the file when you need it especially if its not a larger file

That's a possible solution, but a messy one. For one thing, this fix has to apply to a wide variety of clients, who may be using many different kinds of servers: Windows, Unix, Linux, etc... so any encrypt/decrypt has to provide a solution that is cross-platform. I'm not a heavtweight programmer, so I'd like to avoid this kind of solution.

On the other hand, the client's servers have no problem permitting access to just the machine in question, so using the lock/unlock strategy, I can accomplish the objective from 'my' side of the project alone, which is better, from the client standpoint.

You can lock the file with button1 and and unlock it with button2

unit Unit1;

interface

uses
  Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,
  Dialogs, StdCtrls;

type
  TForm1 = class(TForm)
    Button1: TButton;
    Button2: TButton;
    Memo1: TMemo;
    procedure Button1Click(Sender: TObject);
    procedure Button2Click(Sender: TObject);
  private
    { Private declarations }
  public
    { Public declarations }
  end;

var
  Form1: TForm1;
  fs : TFileStream;

implementation

{$R *.dfm}

procedure TForm1.Button1Click(Sender: TObject);
begin                  // Here to lock the file
  fs := TFileStream.Create('YourFilePath' , fmOpenWrite or fmShareExclusive);
end;
                      // Here to unlock the file
procedure TForm1.Button2Click(Sender: TObject);
begin
fs.free;
end;

end.

Select allOpen in new window

try this;
rename the folder you want to test to;
from:
New Folder1
to:
New Folder1.{ED7BA470-8E54-465E-825C-99712043E01C}

So, when your Delphi program rans?, it rename back to New Folder1

rename file code;
lock folder;
renamefile(New Folder1, New Folder1.{ED7BA470-8E54-465E-825C-99712043E01C});
and back
unlock folder;
renamefile(New Folder1.{ED7BA470-8E54-465E-825C-99712043E01C}, New Folder1 );

Mahdi78:

Ahhhh... this is what I was looking for... I think.

My only question: option 'fmShareExclusive' is defined, in Delphi help, as "Other applications can not open the file for any reason."

This is fine... but does it mean that, if I use this to 'lock' the file, it will also be unavailable for ordinary Windows tasks like 'copy'? Does it absolutely prevent a user, even the Administrator, from accessing the file?

An update for Onclick button1 event

if fs <> nil then showmessage('The file is early locked!')
else fs := TFileStream.Create('YourFilePath' , fmOpenWrite or fmShareExclusive);

The advantage of the procedure like any other mentioned;
Even if your Delphi program is NOT running, it's totally locked.
You don't need a timer, or an event for it.

Unless there are System Experts hacking your system to really get it.

systan and mahdi

OK, I'm a little confused. mahdi78, I like your code snippet, except that I can't use it, because it seems to refer to a file ,rather than a filepath; the file I need to access is an Excel file, using a 3rd party Excel component, and it already handles opening and closing the file. Can a similar approach be taken to lock or unlock a filepath, instead of a file?

systan, your approach sounds good, except: what's the significance of the "ED7BA470-8E54-465E-825C-99712043E01C" part? That looks like stuff I've seen in the Registry, but I searched the registry for it, and don't find it... can you explain?

if the administrator doesn't have access to it ...
how do you suppose he/she does hardware renewal ?

>> This is fine... but does it mean that, if I use this to 'lock' the file, it will also be unavailable for ordinary Windows tasks like 'copy'? Does it absolutely prevent a user, even the Administrator, from accessing the file?

This method deny the other process to read, write, copy, cut, rename and delete the file, and the administrator account couldn't the file too

a file is a just information

use a specific user in your program, with encryption to ask information to a webserver
that webserver can look for a specific file, read whatever it needs and give you a response with some content of the file

> no user has access to the file
> only the webserver on the hosted application, if you login with the correct user and pass and encryption
> this solution allows updating the hardware too

>>>This method deny the other process to read, write, copy, cut, rename and delete the file, and the administrator account couldn't the file too

Thanks... unfortunately, it still presents a problem. I can't use TFileStream, because the Excel component which I'll be using does that. I need a solution which locks the path, not the file itself, I think.

Can you think of any way to lock the path?

You can hide it then

I think you need a commercial version, there's no way here we can provide that kind of solution, if there is?, there will be a massive commercial software like that, because the code is always on the fly.

You can not use file system protection to lock the system administrator out. It is possible but the Administrator will always have the sufficient privileges to revers it and access your file.

If all your problem is protecting an Excel file, then there are simple options you can use:

I:
Just protect your file with a password for opening from within MS Excel so no one can open it without the password, even the admin.

II:
Compress the file with password, so to decompress you need the password.

Always protect the content rather than the container.
If it must be done by code then I suggest Encryption/Decryption.

>>>>You can not use file system protection to lock the system administrator out. It is possible but the Administrator will always have the sufficient privileges to revers it and access your file.<<<<

-------------------

I don't need to lock the Administrator out... just a user.

-------------------
>>>>>>>I:
Just protect your file with a password for opening from within MS Excel so no one can open it without the password, even the admin.
II:
Compress the file with password, so to decompress you need the password<<<<<<<.

-------------------

This doesn't help. First, my code doesn't actually use MS Excel, itself.... it uses nExcel, a commercial Delphi component, to read and write Excel files. Secondly, I don't want to have to download the entire file; it's really lengthy, and will be updated several times per day, so I really need to just be able to access it directly from the server, for brief periods, just to find a specific record.

You are not trying to use the Excel file as a database I hope!

You do not have to use MS Excel itself. Although I do not use nExcel (I think you refer to Native Excel package), I am sure all the required options are available in nExcel, such as, set protection to an Excel file, open a protected Excel file with password, read/write/save without any problem even if it's several times, for brief periods, or to find a specific record.

>   "I don't want to have to download the entire file"
Who said you are going to download anything? You are not going to download it, you will connect to it by it's path from within your application.

I understand you did not like this method but to me it sounds a practical method. However, it's your call.

>>>>You do not have to use MS Excel itself. Although I do not use nExcel (I think you refer to Native Excel package), I am sure all the required options are available in nExcel, such as, set protection to an Excel file, open a protected Excel file with password, read/write/save without any problem even if it's several times, for brief periods, or to find a specific record.<<<<<

Yes, I am using Native Excel. Unfortunately, it doesn't support the encryption feature of Excel... and 'protection' is no good, because it doesn't prohibit prying eyes from copying the file.

I did, however, find a file/path locking utility which has command line / console accessibility, and is available in an unlimited license OEM version, for very reasonable money, which looks like it will do the trick. I can lock the path on installation, and only unlock it briefly when I need to make an access. It's not perfect, because the file wil lbe very briefly (for perhaps a few hundred milliseconds) be exposed to the user, but I don't think that is much of a risk.... the file does NOT contain nuclear launch codes :)

There are libraries, such as TPLockbox on sourceforge.net, that will facilitate encrypting and decrypting files and filestreams.

Thanks for everyone's comments. The most plausible path is to use a commercial file/path locking utility. I found one which is available as an OEM (royalty free) package, acccessible from within Delphi via a cmd line interface.

have you ever considered using a database ? >> mysql is free

a lot of people find using a database approach much simpler and easier for maintaining and in multi user environments
especially after having umpteen copies of a certain excel and not knowing which one is the good one anymore

I think i answered to the half of answer, about how to lock file here http:#35318853

@Geert_Gruwez

>> how do you suppose he/she does hardware renewal ?

What you mean please.

if you lock out the administrator and the server needs to be renewed
everything is copied from the old server to the new

except off course if the administrator is not allowed to copy a file
but that's not really a problem, the file is just lost, that's all :)

as there has been a long discussion , i suggest 3) Accept one or more Expert posts as the answer

TideTracker,
people take time to read your question, please also take the time to assign points to the ones who helped get you to your solution

>>if you lock out the administrator and the server needs to be renewed
>>everything is copied from the old server to the new

I thought you mean that lock of file and folder hurt the hard disk :)

To the administrator,

I'm sorry if I have had difficulty with understanding how the exchange works, the awarding of points, etc... but the system is confusing to me. Quite frankly, none of the comments really answered my question; it seems that most of them failed to understand the constraints that I described. However, if I was compelled to 'select' an answer, I'd say that mahdi78's came closest (although his answer didn't seem to respect the fact that I couldn't use his approach because the Native Excel control I'm using precludes it).

Since I've already found a better answer, on my own, than any that have been suggested, I'd like to finally close this entire thing, and if there's some sort of rule about the awarding of points that needs to be done, I'll be happy to do that... just point out how.

Thanks,

TideTracker

>> (although his answer didn't seem to respect the fact that I couldn't use his approach because the Native Excel control I'm using precludes it).

I'm here in EE to learn and looking for points :)
If i don't deserve the points, then i deserve to learn which problem you met with my method
Does my method not lock the file?
Does my method not lock the Excel file?

Let me learn :p

OK, fair enough.

Mahdi78, I already explained why your solution doesn't work for me, but to reiterate: your solution calls for the use of TStream to lock the file or path... but the NativeExcel code that I must use already incorporates that call, so I don't see how I can use that method. I am not reading or writing to/from the Excel file directly, but am using the NativeExcel calls to do so (I certainly don't want to have to write code to deal with an .xls file directly). From the very beginning, I was looking for a means of file/path locking that was independent of the access of the file itself, and I thought I made that clear.

I will acknowledge that your solution was closer than any of the others, though, and I appreciate it.

As to my 'better' solution: I found a commercial file/path locking utility which, by virtue of its command line interface, will permit me to lock and unlock a path from within my own Delphi application. The utility is available in an OEM version, royalty free, for a modest price. The only 'better' solution would be some freeware, or a simple path locking code snippet, which is what I was hoping to get here, but which I didn't get.

As for the issue of awarding points, I'l lbe happy to award them to mahdi78 for coming closest, even though his solution will not work for me. I'm not looking to 'cheat' anyone out of the effort they expended in helping me find a solution.

Does this explain it all?

>> but the NativeExcel code that I must use already incorporates that call.

You are using other process to access to .xls file, ofcourse you can not access to file locked from other process, then you should hide the file or path, but if anyone has the path of hidden file or path he can access to them

>> As for the issue of awarding points, I'l lbe happy to award them to mahdi78 for coming closest, even though his solution will not work for me. I'm not looking to 'cheat' anyone out of the effort they expended in helping me find a solution.

I am not the only one who does give solution to how lock file and path, the @systan answered to the other part of question #35318898

Now i could say mine and systan answers together gave the answer to your question written above, but do not give the answer to what are you looking for.

I asked systan for an explanation of his suggestion, but he never replied, and I don't understand it. I asked the following:

>>>systan, your approach sounds good, except: what's the significance of the "ED7BA470-8E54-465E-825C-99712043E01C" part? That looks like stuff I've seen in the Registry, but I searched the registry for it, and don't find it... can you explain?<<<<

If I could get an answer to that, perhaps his solution would be useful.

{ED7BA470-8E54-465E-825C-99712043E01C} is one of several special names that the Windows systems recognize and treat in different ways.  For instance, the control panel 'folder' has a special icon and there are some things you are not allowed to do with the folder or its contents.  I think this particular folder identification was introduced in Win7.  Many writers have named it the "God" folder.

============
Your original question for this thread dealt with file locking.  The solution you have chosen is file hiding which is, although related, a different question.  If you require your users to run on NTFS partitions, you have another way of hiding files.

============
I don't think you have an optimal solution.  However, you seem to have locked yourself into an application configuration that limits your security choices.  Personally, I think you should encrypt the contents of the workbook and then decrypt the contents once you've read them with your Excel component.  Better yet...don't use Excel as a data store.

============
I'll return in a few hours and comment as a zone advisor.

>>>{ED7BA470-8E54-465E-825C-99712043E01C} is one of several special names that the Windows systems recognize and treat in different ways.  For instance, the control panel 'folder' has a special icon and there are some things you are not allowed to do with the folder or its contents.  I think this particular folder identification was introduced in Win7.  Many writers have named it the "God" folder.<<<<

This appears to be applicable only to Windows 7.  My application has to run in Windows XP (the vast majority of users)

>>>>I don't think you have an optimal solution.<<<<

I agree.

>>>>  However, you seem to have locked yourself into an application configuration that limits your security choices.<<<<

I'm sure you're right... but you have to understand the context. I'm NOT a software professional... my specialty is hardware design, but in my tiny startup company, we all do what we have to. My programming skills are limited, so I have to work with what I've got. Despite my limitations, I manage to turn out Windows applications which satisfy the customer, which is the objective.  

>>>>Personally, I think you should encrypt the contents of the workbook and then decrypt the contents once you've read them with your Excel component.<<<<<

As I've already explained multiple times, the client does NOT want the entire file downloaded to the target machine, from the host... regardless of encryption.

>>>>Better yet...don't use Excel as a data store.<<<<

I'm sure you're right about that, but I simply don't have the skills required... I'm not familiar with database concepts, and don't have the time to learn them right now. The file is a very simple 7 column spreadsheet... in most applications, it's small, but for one particular client, it is large (130,000 lines).

------

I think the problem here is that I came to this forum, and PAID for the privelege, because I NEED help... I'm not in much of a position to PROVIDE any, and was hoping that the experts here could tailor their responses down to my level of understanding, rather than castigating me for not beling knowledgable. I'm going to have to rethink my membership, it seems.

@Tidetracker

I don't believe the experts are castigating you. People have varied strong opinions on various issues. I understand your position but you do have to agree that your requirement though driven by your client is quite unusual.

Its just out of experience that we do discourage the use of Excel for data storage. If two client applications try to open the excel file, one of them will most likely fail.

But if you find a solution that satisfies your needs then by all means go for it. We can only try to point out the potential errors or disadvantages you may come across.

Otherwise there is a lot to be learnt from EE
Cheers

The author comment http:#35407678 answer to other question (hide files).

I advise to accept the right answers about (lock file/path) without awarding points (with 0 points).

>>>>>I don't believe the experts are castigating you. People have varied strong opinions on various issues. I understand your position but you do have to agree that your requirement though driven by your client is quite unusual.<<<<<

I apologize if I've offended anyone by my sensitivity. I don't view the requirement as 'unusual', per se.... I've been a consulting engineer for 36+ years now, and if you think THIS requirement is unusual, trust me, it's nothing.... I've had to deal with MUCH worse.

>>>>Its just out of experience that we do discourage the use of Excel for data storage. If two client applications try to open the excel file, one of them will most likely fail.<<<<

That has already been anticipated. The file in question will be updated no more than once per day, in the middle of the night, when my application most assuredly won't be used. I've set up to detect any collisions during the course of the day, when several copies of my applications will be in use.

>>>>And you have received many comments from very experience people who volunteer their participation FOR FREE.  Seven of the top 20 Delphi experts (points for the year) have commented in this thread.<<<<<

And I appreciate that. Perhaps the fault is mine for not making it clear that I'm NOT one of those Delphi experts (even though I've been a Delphi user ever since Delphi 3, and Borland Turbo Pascal before that), but my programming has all been 'pragmatic', primarily consisting of small lab applications not sold commercially. I am well aware that I'm 'out of my depth', relative to all the other guys here, but one thing I've learned in decades of professional engineering is that pragmatic solutions don't need to be elegant to be useful.  

>>>>>In the future, you should include your Delphi/programming experience level and the constraints on your solution.  If you had done that with this question, we would likely be working on encryption/decryption of data and display of the data into your TGrid component.  In fact, we might have convinced you to use an encryptable database.<<<<<

Actually, I'm reconsidering encryption. If Native Excel had implemented that Excel feature, it would have been easy... but alas, protection is one function they left out of their product. The client is highly reticent about being required to use any third party software on their end of the system (don't ask why... I've asked, and have not gotten a satisfactory answer), so that becomes a problem. Incidentally, I'm not merely displaying the data in a Tgrid component.

I'll wait and see what additional responses come back... but if no one objects, I'll take the advice of Mahdi78 and close the thread... and will probably pop back in for some additional questions on a different topic... but next time, I'll try to be more explicit about my level of expertise, the constraints I'm under, etc.

I mentioned TPLockbox.  It is an open source library.  There are several source code libraries and units that you might use without depending on a vendor or having to consider licensing issues.

>>>>I mentioned TPLockbox.  It is an open source library.  There are several source code libraries and units that you might use without depending on a vendor or having to consider licensing issues.<<<<

It looks like the latest versions are designed for Delphi 2007 and Delphi 2010... I'm still using Delphi 5. However, I did a bit of gooling, and I've located numerous string encryption and decryption code snippets. This app doesn't require super security.... just enough to keep the casual peepers at bay... I'll see if the client will buy this approach.