🚀 go-pugleaf

"Ian Boyd" <ian.borlandnews010@avatopia.com> wrote in message 
news:488632ef$1@newsgroups.borland.com...

> How to duplicate the described behaviour of iexplore (killing
> my process also deletes a file i had open)

Does calling the Win32 API CreateFile() function with the 
FILE_ATTRIBUTE_TEMPORARY and FILE_FLAG_DELETE_ON_CLOSE flags do what you 
need?


Gambit

>> How to duplicate the described behaviour of iexplore (killing
>> my process also deletes a file i had open)
>
> Does calling the Win32 API CreateFile() function with the 
> FILE_ATTRIBUTE_TEMPORARY and FILE_FLAG_DELETE_ON_CLOSE flags do what you 
> need?

Thank you. Yes it does do what i need, but not really.

i never noticed the DeleteOnClose flag before. i can create the file, and it 
goes away when i kill my process:

    var
         fs: TStream;
         hFile: THandle;
    begin
         hFile := CreateFile(
           'c:\tempFile.bmp',
           GENERIC_WRITE,
           FILE_SHARE_READ,
           nil,
             CREATE_ALWAYS,
           FILE_ATTRIBUTE_TEMPORARY or FILE_FLAG_DELETE_ON_CLOSE,
             0);
         if hFile = INVALID_HANDLE_VALUE then
              RaiseLastWin32Error;

         fs := THandleStream.Create(hFile);
         Image1.Picture.Graphic.SaveToStream(fs);
         fs.Free;
        //leave handle open
    end;

Unfortunatly i don't seem to be able to open the file in another process, 
nor can (most) other programs. The documentation seems to be quite clear - 
nobody is allowed to open the file unless FILE_SHARE_DELETE is used, but i 
can't open it even with FILE_SHARE_DELETE specified:

   "FILE_FLAG_DELETE_ON_CLOSE
    Indicates that the operating system is to delete the file immediately 
after all of its handles have been closed, not just the handle for which you 
specified FILE_FLAG_DELETE_ON_CLOSE.
    Subsequent open requests for the file will fail, unless 
FILE_SHARE_DELETE is used. "


And my opening code:
    var
         fs: TStream;
         hFile: THandle;
    begin
         hFile := CreateFile('c:\tempfile.bmp',
               GENERIC_READ,
               FILE_SHARE_DELETE,
               nil,
               OPEN_EXISTING,
               0,
               0);
         if hFile = INVALID_HANDLE_VALUE then
              RaiseLastWin32Error;

         fs := THandleStream.Create(hFile);
         Image1.Picture.Bitmap.LoadFromStream(fs);
         fs.Free;

         CloseHandle(hFile);

"The process cannot access the file because it is being used by another 
process"


But at the same time: the thumbnailer of Explorer in Windows XP is able to 
show me a preview of the file.


Any idea of the trickery going on in Explorer that it can open a file 
designated only openable with DELETE access? i hope it's actually a change 
to the code that creates the file - i cannot modify Word or Excel to use 
SHARE_DENY_WRITE. And without Word, Excel, Internet Explorer being able to 
view a "Delete On Close" 

After Process Explorering explorer, i discovered that it's calling 
CreateFile with all 3 sharing flags. It then worked if i did the same:

     hFile := CreateFile('c:\tempfile.bmp',
       GENERIC_READ,
       FILE_SHARE_READ or FILE_SHARE_WRITE or FILE_SHARE_DELETE,
       nil,
       OPEN_EXISTING,
       0,
       0);


i always mis-understood the CreateFile API.  e.g.  "Subsequent open 
operations on the object will succeed only if read access is requested. "


But that still means that Excel, Word, etc are not specifying all 3 sharing 
flags - and so will never be able open a temporary file that i place on the 
hard drive. Oh well, that idea's scrapped.

But thanks for the heads up in the FILE_FLAG_DELETE_ON_CLOSE flag. Now i 
could write my own YouTube video stealer. 

"Ian Boyd" <ian.borlandnews010@avatopia.com> wrote in message 
news:48864b9f$1@newsgroups.borland.com...

> Unfortunatly i don't seem to be able to open the file in another
> process nor can (most) other programs.

Because you are not specifying access rights to allow that correctly.

> i can't open it even with  FILE_SHARE_DELETE specified

The code you are using to create the file is not granting FILE_SHARE_DELETE 
rights, and the code that is trying to open the file is not requesting 
DELETE rights:

    hFile := CreateFile(
                    'c:\tempFile.bmp',
                    GENERIC_WRITE,
                    FILE_SHARE_READ or FILE_SHARE_DELETE, // <-- HERE
                    nil,
                    CREATE_ALWAYS,
                    FILE_ATTRIBUTE_TEMPORARY or FILE_FLAG_DELETE_ON_CLOSE,
                    0);

    hFile := CreateFile('c:\tempfile.bmp',
                    GENERIC_READ,
                    FILE_SHARE_READ or FILE_SHARE_DELETE, // <-- HERE
                    nil,
                    OPEN_EXISTING,
                    0,
                    0);


Gambit 

> But thanks for the heads up in the FILE_FLAG_DELETE_ON_CLOSE flag. Now i 
> could write my own YouTube video stealer.

You're hitting it wrong if you want to steal youtube videos :)

Locking files aside, stealing videos is better achieved by network (like so 
many programs do it). Also, there are less painful ways of doing that, like 
setting up a ramdrive or similar temporary drive and formatting it to FAT. 
That should help with the nasty NTFS additions. OTOH, NTFS is your friend 
since you can allow creation and deny deletion of files on the folder - thus 
the file can't be deleted.

And last but not least, FAT is very easy to track for deleted files and they 
can be recovered as long as it's not destroyed.

I have to admit though there are not programming solutions if you want to 
write a stealer. But all the other stealers work via dumping TCP - many are 
open source for your enjoyment.

Oh and just for the fun of it, I believe that it's not "stealing" as they 
are open for anyone, free.

--
Ndi 

> Because you are not specifying access rights to allow that correctly.

> The code you are using to create the file is not granting 
> FILE_SHARE_DELETE rights, and the code that is trying to open the file is 
> not requesting DELETE rights:
>
>    hFile := CreateFile(
>                    'c:\tempFile.bmp',
>                    GENERIC_WRITE,
>                    FILE_SHARE_READ or FILE_SHARE_DELETE, // <-- HERE
>                    nil,
>                    CREATE_ALWAYS,
>                    FILE_ATTRIBUTE_TEMPORARY or FILE_FLAG_DELETE_ON_CLOSE,
>                    0);
>
>    hFile := CreateFile('c:\tempfile.bmp',
>                    GENERIC_READ,
>                    FILE_SHARE_READ or FILE_SHARE_DELETE, // <-- HERE
>                    nil,
>                    OPEN_EXISTING,
>                    0,
>                    0);

i had a whole long response written, but Process Monitor's kernel mode 
driver BSOD's my machine, so i'll summarize.

What you have doesn't work either. i tried every combination of share flags, 
and here are the valid cases (valid is that they allow a file to be opened, 
not that it does what i want):

Created with GENERIC_WRITE
========================
CreatedWith    OpenWith
READ    WRITE|DELETE, READ|WRITE|DELETE
WRITE    none
READ|WRITE    WRITE|DELETE, READ|WRITE|DELETE
DELETE    none
READ|DELETE    WRITE|DELETE, READ|WRITE|DELETE
WRITE|DELETE    none
READ|WRITE|DELETE    WRITE|DELETE, READ|WRITE|DELETE

Created with GENERIC_READ|GENERIC_WRITE
========================
CreatedWith    OpenWith
READ    READ|WRITE|DELETE
WRITE    none
READ|WRITE    READ|WRITE|DELETE
DELETE    none
READ|DELETE    READ|WRITE|DELETE
WRITE|DELETE    none
READ|WRITE|DELETE    READ|WRITE|DELETE

Turning this around: 3rd party applications will try to open these files 
using READ|WRITE. What combination of share flags do i have to specify 
during creation to allow them to subsequently open the file using 
READ|WRITE? The answer is: none. There is no combination of flags that allow 
it.

So even though i cannot achieve what i want, i am curious to try to 
reconcile the SDK docs with reality - can you explain these results? i can't 
find a logical explanation for it - to aid in understanding beyond randomly 
trying combination of flags. Additionally, it contradicts a similar table on 
MSDN:
Creating and Opening Files
http://msdn.microsoft.com/en-us/library/aa363874(VS.85).aspx

The SDK (http://msdn.microsoft.com/en-us/library/aa363874(VS.85).aspx) 
claims that i should be able to use:

GENERIC_WRITE, FILE_SHARE_READ
or
GENERIC_WRITE, FILE_SHARE_READ | FILE_SHARE_WRITE
or
GENERIC_READ | GENERIC_WRITE, FILE_SHARE_READ
or
GENERIC_READ | GENERIC_WRITE, FILE_SHARE_READ | FILE_SHARE_WRITE

When creating the to file, in order to allow a subsequent:
GENERIC_READ, FILE_SHARE_READ|FILE_SHARE_WRITE
operation.

But that's simply not true. 

"Ian Boyd" <ian.borlandnews010@avatopia.com> wrote in message 
news:48875928$1@newsgroups.borland.com...

> What combination of share flags do i have to specify during
> creation to allow them to subsequently open the file using
> READ|WRITE? The answer is: none. There is no combination
> of flags that allow it.

Yes, there is.  If an app wants READ access, the file needs to have 
FILE_SHARE_READ applied.  If an app wants WRITE access, the file needs to 
have FILE_SHARE_WRITE applied.  It is as simple as that, and they can be 
combined together.


Gambit 

>> What combination of share flags do i have to specify during
>> creation to allow them to subsequently open the file using
>> READ|WRITE? The answer is: none. There is no combination
>> of flags that allow it.
>
> Yes, there is.  If an app wants READ access, the file needs to have 
> FILE_SHARE_READ applied.  If an app wants WRITE access, the file needs to 
> have FILE_SHARE_WRITE applied.  It is as simple as that, and they can be 
> combined together.

Here's the code i'm using. No matter what combination of dwSharingMode i use 
i cannot get the 2nd CreateFile to succeed. What value should i assign to 
dwSharingMode when i create the file to allow subsequent READ|WRITE 
operations? Can i see the code you're using, because i don't see it working.


procedure TForm1.Button1Click(Sender: TObject);
var
     dwSharingMode: DWORD;
     hFile: THandle;
begin
     //Sharing mode when we create the file
     dwSharingMode :=
           0
           or FILE_SHARE_READ
           or FILE_SHARE_WRITE
           or FILE_SHARE_DELETE;

     hFile := CreateFile(
            'c:\tempFile.dat',
            GENERIC_WRITE,
            dwSharingMode,
            nil,
            CREATE_ALWAYS,
            FILE_ATTRIBUTE_TEMPORARY or FILE_FLAG_DELETE_ON_CLOSE,
            0);
    Assert(hFile <> INVALID_HANDLE_VALUE, SysErrorMessage(GetLastError));
    hFile := 0; //Leave the handle open, it will get cleaned up when our app 
closes



     //Now try to open the same file. (We must use READ|WRITE to simulate 
what programs like Excel will do)
    hFile := CreateFile(
            'c:\tempFile.dat',
            GENERIC_READ,
            FILE_SHARE_READ or FILE_SHARE_WRITE,
            nil,
            OPEN_EXISTING,
            0,
            0);
    if hFile = INVALID_HANDLE_VALUE then
        raise Exception.Create('Could not open temporary file: 
'+SysErrorMessage(GetLastError));
    try
        //pretend we do stuff with the file
    finally
        CloseHandle(hFile);
    end;
end;


No matter what values for sharing i supply when i create the file the 
subsequent CreateFile always fails. i then throw the exception and it always 
says, "Could not open temporary file: The process cannot access the file 
because it is being used by another process."


i setup a test function, and call that function with all combinations of 
sharing flags.

procedure TForm1.Button5Click(Sender: TObject);
begin
     if TestSharing(0) then
          ShowMessage('Sharing worked');
     if TestSharing(FILE_SHARE_READ) then
          ShowMessage('Sharing worked');
     if TestSharing(FILE_SHARE_WRITE) then
          ShowMessage('Sharing worked');
     if TestSharing(FILE_SHARE_READ or FILE_SHARE_WRITE) then
          ShowMessage('Sharing worked');
     if TestSharing(FILE_SHARE_DELETE) then
          ShowMessage('Sharing worked');
     if TestSharing(FILE_SHARE_READ or FILE_SHARE_DELETE) then
          ShowMessage('Sharing worked');
     if TestSharing(FILE_SHARE_WRITE or FILE_SHARE_DELETE) then
          ShowMessage('Sharing worked');
     if TestSharing(FILE_SHARE_READ or FILE_SHARE_WRITE or 
FILE_SHARE_DELETE) then
          ShowMessage('Sharing worked');
end;


function TForm1.TestSharing(const dwSharingMode: DWORD): Boolean;
var
     hCreatedFile: THandle;
     hCreateFile: THandle;
     hFile: THandle;
begin
     hCreateFile := CreateFile(
           'c:\tempFile.dat',
           GENERIC_WRITE,
           dwSharingMode,
           nil,
            CREATE_ALWAYS,
           FILE_ATTRIBUTE_TEMPORARY or FILE_FLAG_DELETE_ON_CLOSE,
             0);
     Assert(hCreateFile <> INVALID_HANDLE_VALUE, 
SysErrorMessage(GetLastError));
     try
          //Now try to open the same file with READ|WRITE (like like Excel 
will do)
          hFile := CreateFile(
                'c:\tempFile.dat',
                GENERIC_READ,
                FILE_SHARE_READ or FILE_SHARE_WRITE,
                nil,
                OPEN_EXISTING,
                0,
            0);
          if hFile <> INVALID_HANDLE_VALUE then
          begin
               Result := True;
               CloseHandle(hFile);
            end
      else
           Result := False;
     finally
          CloseHandle(hCreateFile);
     end;
end;

What values of share mode are using when you call
    CreateFile(GENERIC_WRITE)
so that a subsequent
    CreateFile(GENERIC_READ, FILE_SHARE_READ or FILE_SHARE_WRITE)
succeeds?

"Ian Boyd" <ian.borlandnews010@avatopia.com> wrote in message 
news:48879614@newsgroups.borland.com...

> Here's the code i'm using. No matter what combination of
> dwSharingMode i use i cannot get the 2nd CreateFile to succeed.

The second call is not specifying FILE_SHARE_DELETE, which is required since 
the first call specified FILE_FLAG_DELETE_ON_CLOSE.


Gambit 

Andrei "Ndi" Dobrin wrote:
>> But thanks for the heads up in the FILE_FLAG_DELETE_ON_CLOSE flag. Now i 
>> could write my own YouTube video stealer.
> 
> You're hitting it wrong if you want to steal youtube videos :)
> 
> Locking files aside, stealing videos is better achieved by network (like so 
> many programs do it). Also, there are less painful ways of doing that, like 
> setting up a ramdrive or similar temporary drive and formatting it to FAT. 
> That should help with the nasty NTFS additions. OTOH, NTFS is your friend 
> since you can allow creation and deny deletion of files on the folder - thus 
> the file can't be deleted.
> 
> And last but not least, FAT is very easy to track for deleted files and they 
> can be recovered as long as it's not destroyed.
> 
> I have to admit though there are not programming solutions if you want to 
> write a stealer. But all the other stealers work via dumping TCP - many are 
> open source for your enjoyment.

It's far easier to capture Youtube videos than than. You can just send a 
HTTP request to their server for the .FLV file that the video is based 
on, if you know the ID of the video, which is included in the page's 
source. Try any "download YouTube videos" website to see.

Cheers,
Nicholas Sherlock

On Wed, 23 Jul 2008 17:03:39 -0700, Remy Lebeau (TeamB) wrote:

> The second call is not specifying FILE_SHARE_DELETE, which is required since 
> the first call specified FILE_FLAG_DELETE_ON_CLOSE.

The problem is that the second program is not under his control. For
example if he creates a temporary XLS file with
FILE_FLAG_DELETE_ON_CLOSE then Excel cannot open it.

-- 
Marc Rohloff [TeamB]
marc -at- marc rohloff -dot- com

Ian Boyd wrote:

> So here's two questions.
> 1. How to duplicate the described behaviour of iexplore (killing my
> process also deletes a file i had open) 2. Offer a solution to the
> "how to delete a temporary file when the associated launched
> application is done with it".

at #1
Does it really needs to be deleted instantly when your app is closed or
killed?

Would a delayed delete until the next reboot of the PC or restart of
your program also be an option?

Do you need it to work on Vista?

Do all the users have admin rights?


at #2
There is a way to wait for a program to finish, after that you could
delete the file. Google the groups for WinExecAndWait32V2 by Peter
Below.

http://groups.google.nl/group/borland.public.delphi.language.delphi.win32/msg/1540e2800d0eeb72?hl=en

-- 
Pieter

> at #1
> Does it really needs to be deleted instantly when your app is closed or
> killed?
No

> Would a delayed delete until the next reboot of the PC or restart of
> your program also be an option?
Yes.

> Do you need it to work on Vista?
Yes

> Do all the users have admin rights?
No.

i'd be saving files in GetTempPath, which every user has their own of, and 
can fully access - whether they're standard user on XP or standard user on 
Vista. My goal is to do one better than leaving temporary files forever.

> at #2
> There is a way to wait for a program to finish, after that you could
> delete the file. Google the groups for WinExecAndWait32V2 by Peter
> Below.
> http://groups.google.nl/group/borland.public.delphi.language.delphi.win32/msg/1540e2800d0eeb72?hl=en

That isn't the behaviour i would want. Besides, you can't actually trust 
that - there are exceptions (which are more of the rule) that make it fail. 
You can about them in a Raymond Chen blog entry: 
http://blogs.msdn.com/oldnewthing/archive/2006/05/05/590749.aspx

But the gist of it is: what if the associated application finds an already 
running instance, pokes that existing instance to handle your file, and the 
itself closes?


If you have an alternative solution under #1, i'm definetly interested. But 
the goal of my post was to hopefully leverage behaviour i saw in IE. Turns 
out that technology cannot be used here. It just cannot be done. 

On Fri, 25 Jul 2008 15:52:41 -0400, Ian Boyd wrote:

>> Would a delayed delete until the next reboot of the PC or restart of
>> your program also be an option?
> Yes.

This is something relatively easy to do. 

Another option is for your program to delete temporary files when it
is started. If someone is still using the file then it should fail to
delete and you could ignore the error, you could also only delete
files that are older than say one day every time your app starts.

Depending on how crucial a combination might work.

-- 
Marc Rohloff [TeamB]
marc -at- marc rohloff -dot- com

Ian Boyd wrote:

> > at #1
> > Does it really needs to be deleted instantly when your app is
> > closed or killed?
> No
> 
> > Would a delayed delete until the next reboot of the PC or restart of
> > your program also be an option?
> Yes.
> 
> > Do you need it to work on Vista?
> Yes
> 
> > Do all the users have admin rights?
> No.

I was thinking that you might be be able to use MoveFileEx with 
MOVEFILE_DELAY_UNTIL_REBOOT but that one requires admin rights. Adding
the need for Vista is also not helping much ;-)
I don't know if there is a similar function which can be used by normal
users.


> > WinExecAndWait32V2
> 
> But the gist of it is: what if the associated application finds an
> already running instance, pokes that existing instance to handle your
> file, and the itself closes?

Indeed that would not work in that case.
 

> i'd be saving files in GetTempPath, which every user has their own
> of, and can fully access - whether they're standard user on XP or
> standard user on Vista. My goal is to do one better than leaving
> temporary files forever.
> 
> If you have an alternative solution under #1, i'm definetly
> interested. 


Option #1
It shouldn't be to hard to keep a list in a txt file (or ini-file) of
temporary files you app created and keep that file in the same
directory.

Next make a little utility that can read that ini-file and delete the
files which are in the list. Remove the file from the list when it was
actual possible to delete the file (some will fail to delete when the
file is still in use by another application).

You could start this utility when your application is closed. That
should take care of most of the temporary files assuming that your app
is used frequently (and closed frequently).

Next thing you also might consider is to start this utility at startup
by creating an entry in the RunOnce as soon as a temporary file is
created. See...
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\RunOnce

The utility should also check and remove that entry when it succeeded
in deleting all files mentioned in the ini-file.


Option #2
You might want to switch from using the standard temporary path to a
directory in of the other user paths (CSIDL_APPDATA for instance) to
store the temporary files. Dump all temporary files in this directory
and just delete all files in it when your application closes.
You can then also again use the RunOnce key to empty the folder at
startup of windows...
  DeleteJunk REG_SZ cmd /C del /q "%APPDATA%\YourAppName\YourTemp\*.*"


> But the goal of my post was to hopefully leverage behaviour i saw in
> IE. Turns out that technology cannot be used here.

I don't know of a way to make that work with the bunch of office
applications you mentioned.

-- 
Pieter