Deleted files
r...@iinet.com.au
Walt
Or do you mean being able to DOS COPY the files out
of the C:\RECYCLED subdirectory?
Donald Phillipson
> Is there a way of recovering deleted files using DOS?
Yes. You need a disk utility that can go to the
file directory. Deleted files appear with FILENAM.XYZ
changed to eILENAM.XYZ. Rewriting that first char
back to the original is all you need to restore
the file (unless something else has been written
to one or more of the sectors the FAT earlier assigned
to FILENAM.XYZ.)
--
| Donald Phillipson, dphil...@trytel.com |
| Carlsbad Springs, Ottawa, Canada |
Rick Collins
"Donald Phillipson" <ad...@FreeNet.Carleton.CA> wrote in message
news:8v1i68$oqc$1...@freenet9.carleton.ca...
> (r...@iinet.com.au) writes:
>
> > Is there a way of recovering deleted files using DOS?
> > r...@iinet.com.au/
>
> Yes. You need a disk utility that can go to the
> file directory. Deleted files appear with FILENAM.XYZ
> changed to eILENAM.XYZ. Rewriting that first char
> back to the original is all you need to restore
> the file (unless something else has been written
> to one or more of the sectors the FAT earlier assigned
> to FILENAM.XYZ.)
>
certainly indicate the file no longer exists - but how would the
cluster chain in the FAT get re-used if that was _all_ that was done?
Doesn't the FAT have to be modified to show "this cluster free" as
well?
Norbert Hahn
>I have a question. Changing the first character of the filename can
>certainly indicate the file no longer exists - but how would the
>cluster chain in the FAT get re-used if that was _all_ that was done?
>Doesn't the FAT have to be modified to show "this cluster free" as
>well?
Deleting a file is more than just a rename. If I'm not mistaken
a deleted files gets its first character replaced by a question
mark.
A DOS file consists of more than the data and it's name: The directory
contains the file name, date, and similar properties, and a pointer
to a table of disk clusters (blocks) that hold the data. This table
is not erased by the delete command.
The disk itself contains a table of unallocated clusters. These
will be used when a file is written.
If a file is deleted its clusters are added to the table of free
clusters, just to make the space reusable. However, as the table
blocks allocated to the (deleted) file still exists, it can both
be reactivated by undelete and overwritten if space is needed.
Norbert
Donald Phillipson
> news:8v1i68$oqc$1...@freenet9.carleton.ca...
>> (r...@iinet.com.au) writes:
>>
>> > Is there a way of recovering deleted files using DOS?
>> > r...@iinet.com.au/
>>
>> Yes. You need a disk utility that can go to the
>> file directory. Deleted files appear with FILENAM.XYZ
>> changed to eILENAM.XYZ. Rewriting that first char
>> back to the original is all you need to restore
>> the file (unless something else has been written
>> to one or more of the sectors the FAT earlier assigned
>> to FILENAM.XYZ.)
"Rick Collins" (ab...@debbs.ndhq.dnd.ca) writes:
>
> I have a question. Changing the first character of the filename can
> certainly indicate the file no longer exists - but how would the
> cluster chain in the FAT get re-used if that was _all_ that was done?
> Doesn't the FAT have to be modified to show "this cluster free" as
> well?
I don't think so. IIRR a FAT entry has 32 bytes including
1 = filename max. 11 bytes (8 + 3) or 12 if it includes .
2 = list of sectors assigned by FAT to this filename
3 = link to a second FAT entry (for large files using
more than n sectors.
DOS Delete simply reassigns first byte of FILENAME.EXT
(which FAT always writes as upper case) to lower case
e -- here eILENAME.EXT. And the OS is so programmed in
system code as to recognize that all sectors on disk
are free for use except those associated in the FAT
with any valid filename (no initial e). (CHKDSK's
check for cross-linked files is probably an inventory
of all validly assigned sectors listed, inspecting
to see whether there are any duplicates, viz. whether
any sector is currently listed as belonging to two
or more files: and notifies the user if that is so.)
Thus DOS makes no claims about "existence" of anything
(and everything DOS recognizes is a file.) It just
assigns space as either free or belonging to a named
file: which is why we can undelete.
Rick Collins
Don't think so. Here's why:
a. - DOS marks a directory entry as "deleted" by substituting the
first character of the filname with hex E5 (lower-case sigma).
Different utilities may depict that value in different ways.
b. - There are "reserved" values for clusters in the FAT:
0 - cluster is free
FFF0 - FFF6 - "reserved"
FFF7 - "bad" cluster.
FFF8 to FFFF - last cluster in the chain
Any other value is the number of the next cluster in the chain.
All values above are for the 16-bit FAT).
c. - it takes much longer to delete a large file than a small file. If
_all_ that was done was to change the first character of the file
name, it would take as long to delete the large one as the small one.
The reason it takes longer is because DOS must set the clusters in the
chain to 0 to indicate they are "free".
d. - If what you say is correct, DOS would have to check every FAT
entry with every "valid" file in the directory to determine if it
could re-use that cluster. Obviously, DOS doesn't operate that way -
creating or extending a file would be horrendously slow.
(CHKDSK's
> check for cross-linked files is probably an inventory
> of all validly assigned sectors listed, inspecting
> to see whether there are any duplicates, viz. whether
> any sector is currently listed as belonging to two
> or more files: and notifies the user if that is so.)
CHKDSK both checks for a single cluster in two or more chains
(cross-linked files), and also a cluster that is not part of any chain
(lost clusters). In the first case no two entries can have the same
value (except for the special values shown above), something that can
be fairly quickly determined (build a table with all the "variable"
FAT values, sort it, and make sure each succesive entry is greater
than the previous. For the lost cluster case, simply follow the chain
from each valid directory entry, deleting the table entry for each
value found. Anything left in the table when all the chains have been
"walked" are "lost clusters".
> Thus DOS makes no claims about "existence" of anything
> (and everything DOS recognizes is a file.) It just
> assigns space as either free or belonging to a named
> file: which is why we can undelete.
Your thoughts now?
Franc Zabkar
<ab...@debbs.ndhq.dnd.ca> put finger to keyboard and composed:
>
>"Donald Phillipson" <ad...@FreeNet.Carleton.CA> wrote in message
>news:8v1i68$oqc$1...@freenet9.carleton.ca...
>> (r...@iinet.com.au) writes:
>>
>> > Is there a way of recovering deleted files using DOS?
>> > r...@iinet.com.au/
>>
>> Yes. You need a disk utility that can go to the
>> file directory. Deleted files appear with FILENAM.XYZ
>> changed to eILENAM.XYZ. Rewriting that first char
>> back to the original is all you need to restore
>> the file (unless something else has been written
>> to one or more of the sectors the FAT earlier assigned
>> to FILENAM.XYZ.)
>>
>I have a question. Changing the first character of the filename can
>certainly indicate the file no longer exists - but how would the
>cluster chain in the FAT get re-used if that was _all_ that was done?
>Doesn't the FAT have to be modified to show "this cluster free" as
>well?
Yes, that's correct. Not only is the leading character of the file
name changed to E5h (= lower case sigma, not "e"), but all relevant
FAT entries are zeroed out. A file's directory entry contains its
name, extension, attributes, date/time, size, and starting cluster. In
order to undelete an erased file, the OS looks at the file size and
uses this figure to compute the number of clusters. It then begins at
the starting cluster and rebuilds the file by adding the next
available free clusters. This technique is not foolproof since there
is no guarantee that the next available free cluster ever belonged to
this file, nor can one be certain that this cluster has not been
overwritten by other files.
To illustrate the structure of the FAT, let's say we have a file
consisting of three clusters. This file will have three FAT entries,
eg 40, 41, EOF, each of which point to the next cluster in the chain.
The directory entry will have 39 as the starting cluster. After
deleting this file, the starting cluster will remain 39, but each of
the FAT entries will be reset to zero.
-- Franc Zabkar
Please remove one 'e' from my address when replying by email.
Franc Zabkar
<ab...@debbs.ndhq.dnd.ca> put finger to keyboard and composed:
>d. - If what you say is correct, DOS would have to check every FAT
>entry with every "valid" file in the directory to determine if it
>could re-use that cluster. Obviously, DOS doesn't operate that way -
>creating or extending a file would be horrendously slow.
I agree with most of what you have said. However, while experimenting
with the Norton Utilities on a floppy disc file system (FAT12), I have
observed some odd behaviour.
I created three files on my hard disc containing 1, 2, and 3 sectors,
respectively, and then proceeded to copy and delete these files to and
from a newly formatted diskette, as follows:
2 3 4 5 6 cluster # (1 sector = 1 cluster)
-----------
1 x x x x copy file1
1 2 2 x x copy file2
x 2 2 x x delete file1
x x x x x delete file2
3 3 3 x x copy file3
The previous table shows the contents of clusters 2-5 as I expected
would have been reported by the FAT (x = free). However, the actual
final cluster assignment is:
2 3 4 5 6 cluster #
-----------
x x 3 3 3
For some reason Win95/DOS has ignored the first two free clusters. I
can't say exactly why this should be so, but I notice that the
diskette's root directory contains directory entries for file3 and
file2, the latter being marked as deleted:
name ext starting cluster #
----------------------------------
THREE SEC 4
eWO SEC 3
The directory entry for file1 has been overwritten by file3.
When writing file3 to the diskette, is it possible that DOS avoided
cluster #3 because it was assigned as the starting cluster for one of
the deleted files (file2)? If so, then it would appear that Win95/DOS
checks the directory as well as the FAT before allocating clusters to
new files. Furthermore, I believe DOS has also avoided cluster #2
because that would have resulted in unnecessary fragmentation.
Peter Fletcher
low level disk drivers which makes undeletion more likely to work than
it would be and evens out wear over the disk. It is also generally a
more efficient way of finding free space (especially on a nearly full
disk) than always starting at the beginning of the FAT and searching
linearly from there. In general, the low-level driver keeps track of
the last cluster written to and starts its search for free clusters
there when it is next asked to create a file. This tends to leave the
clusters freed up by a delete operation untouched for a while until
the "write area" works its way round to them. What I actually can't
explain is why file 3 started at cluster 4 - I would have expected it
to start at cluster 5, even though files 1 and 2 had been deleted.
Peter R. Fletcher <pfl...@ntlworld.com>
Home Page - http://homepage.ntlworld.com/pfletch/peter
Franc Zabkar
Fletcher) put finger to keyboard and composed:
>The behaviour you observe is part of a deliberate bit of design in the
>low level disk drivers which makes undeletion more likely to work than
>it would be and evens out wear over the disk. It is also generally a
>more efficient way of finding free space (especially on a nearly full
>disk) than always starting at the beginning of the FAT and searching
>linearly from there. In general, the low-level driver keeps track of
>the last cluster written to and starts its search for free clusters
>there when it is next asked to create a file. This tends to leave the
>clusters freed up by a delete operation untouched for a while until
>the "write area" works its way round to them. What I actually can't
>explain is why file 3 started at cluster 4 - I would have expected it
>to start at cluster 5, even though files 1 and 2 had been deleted.
As I see it, there is no data structure in the file system that keeps
track of any cluster [of a deleted file] other than the starting
cluster. Hence, there would be no way for the OS to know that it had
to avoid cluster #4 to facilitate undeletion.