1. RE: DOS undocumented feature
- Posted by rforno at tutopia.com
Jul 21, 2002
Yes, it is a good idea.
I have another one: store the attributes, set them to no-system, no-hidden,
read the files, and afterwards restore the original attributes. It is a bit
dangerous, however.
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?
----- Original Message -----
From: Kat <gertie at PELL.NET>
Subject: 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
>
>
>
>
2. RE: DOS undocumented feature
- Posted by rforno at tutopia.com
Jul 24, 2002
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.
----- Original Message -----
From: Juergen Luethje <jluethje at gmx.de>
To: EUforum <EUforum at topica.com>
Sent: Wednesday, July 24, 2002 9:01 AM
Subject: 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
>
>
>
>
