1. DOS undocumented feature
- Posted by rforno at tutopia.com
Jul 21, 2002
Rob:
While trying to enhance your DUPFILE.EXW program with some additional
options, I discovered what seems to be an undocumented feature of DOS under
Windows 98 SE.
This happens only in a DOS window, not when you restart in DOS mode.
As you know, . means the current directory, and .. means the parent
directory. But ... means the parent of the parent directory, .... the parent
of the parent of the parent, and so on.
So, maybe the number of possible platforms should be increased.
By the way, do you know why some files processed by DUPFILE.EXW when run
through ex raise a "Critical error" condition?
Regards.
2. Re: DOS undocumented feature
Ricardo Forno writes:
> While trying to enhance your DUPFILE.EXW program
> with some additional options, I discovered what seems
> to be an undocumented feature of DOS under
> Windows 98 SE. This happens only in a DOS window,
> not when you restart in DOS mode.
> As you know, . means the current directory, and .. means the parent
> directory. But ... means the parent of the parent directory,
> .... the parent of the parent of the parent, and so on.
That apparently doesn't work on XP. Only . and .. work.
> So, maybe the number of possible platforms should be increased.
I'm not sure what you mean. dupfile.exw works (more or less) on all
platforms. Only "." and ".." are reported by the system calls that dir()
uses. I guess "..." and "...." are supported artificially by the
Win 98 command-line processor.
> Do you know why some files processed by DUPFILE.EXW when run
> through ex raise a "Critical error" condition?
That's what DOS does when a DOS program tries to open a locked file.
Not very helpful. It will help if you close all your Windows apps
before scanning the whole drive with ex dupfile.exw.
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
3. Re: DOS undocumented feature
On 21 Jul 2002, at 12:15, Robert Craig wrote:
>
> Ricardo Forno writes:
> > While trying to enhance your DUPFILE.EXW program
> > with some additional options, I discovered what seems
> > to be an undocumented feature of DOS under
> > Windows 98 SE. This happens only in a DOS window,
> > not when you restart in DOS mode.
> > As you know, . means the current directory, and .. means the parent
> > directory. But ... means the parent of the parent directory,
> > .... the parent of the parent of the parent, and so on.
>
> That apparently doesn't work on XP. Only . and .. work.
>
> > So, maybe the number of possible platforms should be increased.
>
> I'm not sure what you mean. dupfile.exw works (more or less) on all
> platforms. Only "." and ".." are reported by the system calls that dir()
> uses. I guess "..." and "...." are supported artificially by the
> Win 98 command-line processor.
Which means you can write Eu code to artificially support it too, Ricardo.
Same as adding a huge long path with create_directory().
> > Do you know why some files processed by DUPFILE.EXW when run
> > through ex raise a "Critical error" condition?
>
> That's what DOS does when a DOS program tries to open a locked file.
> Not very helpful. It will help if you close all your Windows apps
> before scanning the whole drive with ex dupfile.exw.
Even less helpful, Rob. What about checking the file attributes before any
operations on them, Ricardo?
Kat
4. Re: DOS undocumented feature
Ricardo <rforno at tutopia.com> wrote:
<snip>
> Independently of attributes, in Windows there are some files that can't be
> accessed, for example the swap file. There are some others that are "in use"
> by some other program, and can't be deleted, for example, without restarting
> Windows. I found a way to treat some files that can't be deleted; they *can*
> be moved to some other directory, and then you can delete them. Strange, uh?
<snip>
I only know how this can be done by the strategy, where the application
specifies which files to process, and the system processes them when it
reboots.
(see http://support.microsoft.com/default.aspx?scid=KB;EN-US;Q140570& )
Does your method work without rebooting?
If so, it would be very interesting for me, if it works for the following
files, created by the Internet Explorer:
- Windows\Cookies\index.dat
- Windows\Temporary Internet Files\Content.IE5\index.dat
Regards,
Juergen
5. Re: DOS undocumented feature
Ricardo <rforno at tutopia.com> wrote:
> No, I tried to do that and the move fails at mid point: it creates the copy,
> but then it can't delete the original. But it works with some other files,
> for example the ones that are left in \WINDOWS\TEMP after executing or
> installing some programs. It works even performing the move within the same
> directory. Of course, booting plain DOS, you can delete the INDEX.DAT files.
> I did this once, with no ill effects afterwards. You can also modify the
> C:\MSDOS.SYS file setting BootGUI=0 and Logo=0 to boot only plain DOS, and
> then, if you want, go to Windows by typing WIN. Of course, you need to reset
> first the h, s and r attributes of the file to edit it, and restore them
> after modifying it.
> Why would be useful for you deleting INDEX.DAT files?
> Regards.
Thank you, this is a good idea, to delete the INDEX.DAT files on plain
DOS. I figured out, that during a normal Windows boot (with BootGUI=1 in
MSDOS.SYS) the autoexec.bat file is executed before Windows starts. So,
I now delete the INDEX.DAT files automatically during a normal boot by
appropriate commands in autoexec.bat.
This is much simpler than writing something into the registry etc., as
often recommended.
I want to delete the INDEX.DAT files that are created by the Internet
Explorer for privacy. Even if you delete all the files that can normally
be deleted in the Cookies, Temporary Internet Files and History folders,
the remaining INDEX.DAT files contain information about websites you have
visited, cookies you have received, etc.
See for instance
http://www.purgeie.com/indexdat.htm
http://www.swanksoft.com/historykill/cookies-dat.gif
(There may be some more detailed information about this topic somewhere
on the net.)
Regards,
Juergen
6. Re: DOS undocumented feature
On 26 Jul 2002, at 22:55, Juergen Luethje wrote:
<snip>
> I want to delete the INDEX.DAT files that are created by the Internet
> Explorer for privacy. Even if you delete all the files that can normally
> be deleted in the Cookies, Temporary Internet Files and History folders,
> the remaining INDEX.DAT files contain information about websites you have
> visited, cookies you have received, etc.
>
> See for instance
> http://www.purgeie.com/indexdat.htm
> http://www.swanksoft.com/historykill/cookies-dat.gif
> (There may be some more detailed information about this topic somewhere
> on the net.)
Web companies are getting sneakier about how to track you. Dynamic
scripting the server allows them to tag all href's with a unique id, so anything
you access from them after the first url is tracked, without setting any
cookies or looking in the index.dat file. And on the first url there are lots of
"src=" tags to advertisers, etc with those unique referrer tags. And there are
interesting non-standard header lines too, not just Cookie or ETags.
Kat
7. Re: DOS undocumented feature
Kat <gertie at PELL.NET> wrote:
> On 26 Jul 2002, at 22:55, Juergen Luethje wrote:
> <snip>
>> I want to delete the INDEX.DAT files that are created by the Internet
>> Explorer for privacy. Even if you delete all the files that can normally
>> be deleted in the Cookies, Temporary Internet Files and History folders,
>> the remaining INDEX.DAT files contain information about websites you have
>> visited, cookies you have received, etc.
>>
>> See for instance
>> http://www.purgeie.com/indexdat.htm
>> http://www.swanksoft.com/historykill/cookies-dat.gif
>> (There may be some more detailed information about this topic somewhere
>> on the net.)
> Web companies are getting sneakier about how to track you. Dynamic
> scripting the server allows them to tag all href's with a unique id, so
> anything
> you access from them after the first url is tracked, without setting any
> cookies or looking in the index.dat file. And on the first url there are lots
> of
> "src=" tags to advertisers, etc with those unique referrer tags. And there are
>
> interesting non-standard header lines too, not just Cookie or ETags.
> Kat
In contrast to the dynamic techniques that you describe, the information
in the INDEX.DAT files is stored on my hard disk. Therefore web companies
can read from there, what websites I have visited a week ago or so, is this
right?
Regards,
Juergen
8. Re: DOS undocumented feature
Juergen Luethje wrote:
> In contrast to the dynamic techniques that you describe, the information
> in the INDEX.DAT files is stored on my hard disk. Therefore web companies
> can read from there, what websites I have visited a week ago or so, is this
> right?
Not directly. However MSIE has lots of bugs, and some of them allow reading
any local files, executing code etc. Just try this:
<img src="file:///C|/con/con">
I have MSIE 5.5 + SP1 + SP2 + all patches Microsoft released and I still
cant get rid off the Blue Screen of Death...
Martin
9. Re: DOS undocumented feature
Martin <martin.stachon at worldonline.cz> wrote:
> Juergen Luethje wrote:
>> In contrast to the dynamic techniques that you describe, the information
>> in the INDEX.DAT files is stored on my hard disk. Therefore web companies
>> can read from there, what websites I have visited a week ago or so, is this
>> right?
> Not directly.
Is the information in the INDEX.DAT files not stored for such a long
time, or what do you mean? Would you think that it doesn't make sense
to delete the INDEX.DAT files for the sake of privacy?
> However MSIE has lots of bugs, and some of them allow reading
> any local files, executing code etc. Just try this:
> <img src="file:///C|/con/con">
What exactly shall I try? This is a HTML tag, isn't it? I saved your
post as HTML file. I have MSIE 5.50 + SP1. When I open this HTML file
with it, I can't detect anything special. It just shows a square with
a red cross inside, instead of <img src="file:///C|/con/con">.
> I have MSIE 5.5 + SP1 + SP2 + all patches Microsoft released and I still
> cant get rid off the Blue Screen of Death...
> Martin
Of course, those Blue Screens are very annoying. But are they related
to any lack of privacy?
Regards,
Juergen
10. Re: DOS undocumented feature
Juergen Luethje
> > Juergen Luethje wrote:
> >> In contrast to the dynamic techniques that you describe, the information
> >> in the INDEX.DAT files is stored on my hard disk. Therefore web companies
> >> can read from there, what websites I have visited a week ago or so, is this
> >> right?
>
> > Not directly.
>
> Is the information in the INDEX.DAT files not stored for such a long
> time, or what do you mean? Would you think that it doesn't make sense
> to delete the INDEX.DAT files for the sake of privacy?
Normally web pages can't just read a file or browse your hisory.
I wouldn't delete INDEX.DAT because it contains data needed for
off-line browsing (which I often use)
> > However MSIE has lots of bugs, and some of them allow reading
> > any local files, executing code etc. Just try this:
>
> > <img src="file:///C|/con/con">
>
> What exactly shall I try? This is a HTML tag, isn't it? I saved your
> post as HTML file. I have MSIE 5.50 + SP1. When I open this HTML file
> with it, I can't detect anything special. It just shows a square with
> a red cross inside, instead of <img src="file:///C|/con/con">.
This is one older bug in MSIE+Win. Reference to PRN,CON or AUX causes
system to crash. You probably have Win2000+.
> Of course, those Blue Screens are very annoying. But are they related
> to any lack of privacy?
It just shows how safe MSIE is. This search :
http://search.atomz.com/search/?sp-q=Microsoft+Internet+Explorer&sp-a=sp1001071c
gives about 187 security bugs. Some let attacker run any code on your machine
etc. But this is not the topic of EUFourm. Bugtraq would be better.
Martin
11. Re: DOS undocumented feature
Martin <martin.stachon at worldonline.cz> wrote:
> Juergen Luethje
<snip>
>> Is the information in the INDEX.DAT files not stored for such a long
>> time, or what do you mean? Would you think that it doesn't make sense
>> to delete the INDEX.DAT files for the sake of privacy?
> Normally web pages can't just read a file or browse your hisory.
When a web page tries to read a file, AFAIK the main problem is to know
the name and the location of that file. Name and location of the
INDEX.DAT files normally are known. When a web page can read cookies
(which are files), why shouldn't it be able to read INDEX.DAT files?
> I wouldn't delete INDEX.DAT because it contains data needed for
> off-line browsing (which I often use)
I see. Then the INDEX.DAT files shouldn't be deleted, of course.
<snip>
>> What exactly shall I try? This is a HTML tag, isn't it? I saved your
>> post as HTML file. I have MSIE 5.50 + SP1. When I open this HTML file
>> with it, I can't detect anything special. It just shows a square with
>> a red cross inside, instead of <img src="file:///C|/con/con">.
> This is one older bug in MSIE+Win. Reference to PRN,CON or AUX causes
> system to crash. You probably have Win2000+.
<snip>
I have Win 98, 1st edition.
Regards,
Juergen
12. Re: DOS undocumented feature
Juergen wrote:
> <snip>
> >> Is the information in the INDEX.DAT files not stored for such a long
> >> time, or what do you mean? Would you think that it doesn't make sense
> >> to delete the INDEX.DAT files for the sake of privacy?
>
> > Normally web pages can't just read a file or browse your hisory.
>
> When a web page tries to read a file, AFAIK the main problem is to know
> the name and the location of that file. Name and location of the
> INDEX.DAT files normally are known. When a web page can read cookies
> (which are files), why shouldn't it be able to read INDEX.DAT files?
But cookies aren't accessed directly. AFAIK they're accessed via
JavaScript/VBScript functions. But...everything has holes. You may try this
to read your c:\test.txt
<IFRAME NAME="I1" SRC="file://c:/test.txt"></IFRAME>
<SCRIPT>
function f()
{
window.external.NavigateAndFind("javascript:alert(document.body.innerText);","ll","I1");
}
setTimeout("f()",2000);
</SCRIPT>
Martin
