EnCase file copying and Windows Short File Names

First published May 2010

By Lee Hui Jing, EnCe

Edited by Sarah Khadijah Taylor


A couple of months ago, one of my clients, an Investigating Officer from a Law Enforcement Agency, had requested me to extract some of the files from an image copy of a hard disk. The total number of files to be copied was 1,030. Sounds easy right? This job of a few clicks turned out to be a nightmare when I found out that I was short of 2 files in my destination folder. I had selected 1,030 files to be copied, but at the end, only 1,028 files were being copied. More surprisingly, I received output from the EnCase Copy operation; ‘Status: Completed’. But where did the other 2 files go? Why had EnCase produced ‘Status: Completed’, when actually, 2 files were missing? Referring back to the image copy, I found out that most of the files had the same filename as each other.

Get The Latest DFIR News

Join the Forensic Focus newsletter for the best DFIR articles in your inbox every month.

Unsubscribe any time. We respect your privacy - read our privacy policy.

It is very common for an analyst to face evidence files which have the same filename. This circumstance exists when:

1. There are 2 files with same name, but they are put in different folders.
2. There are 2 files with same name, but with different MAC times.

A procedure to be followed before analyzing a case is to recover all files and folders. When you use recover options, the deleted files will be recovered, and sometimes these deleted files have the same file name as the existing files, but with different MAC times.

But is it possible that EnCase can fail to copy all the files under these circumstances? For those readers who are new to EnCase, you may ask, why do you need to copy the evidence file in the first place? Let me try to put it simply, in computer forensic methodology, after the analysis phase, we will present the findings to our clients. So usually what we do is to copy out the evidence files using EnCase so that our clients can access the files in their workstation, without looking at the whole hard disk image. So the real question now is how sure are you that the selected files are properly copied to your designated folder? Is it sufficient to rely on the EnCase notification window after the EnCase copying process has been executed?


EnCase basically provide two functions to copy files;

1. COPY/UNERASE function – allows analyst to copy files from different folders into one designated folder
2. COPY FOLDER function – allows all files and all subfolders to be copied into one designated folder

With every action taken in EnCase, a notification window (Figure 2) will pop up to inform analyst about his/her action. Since this article will be describing about some “misbehavior” of the copying function in EnCase when copying files with the same file name, I will first show you how they normally operates under a normal evidence condition.

For the experiments that I have conducted, I have used EnCase version running on windows XP SP3/windows 7 home premium platform.


For the COPY/UNERASE function, first tick on the files, right click and choose the COPY/UNERASE function from the menu. (Figure 1). After it is completed, a notification window will pop up to show the total numbers of files that have been copied, copying time, size and its status (Figure 2).

Figure 1: Copy/Unerase Function

Figure 2: EnCase Notification window
For this experiment, I have created a folder “test1” as my copy destination, and with COPY/UNERASE function, 6 files were being copied into test1 folder. Notice that although each file has the same name originally, numbers will be added behind each file after they were copied. (Figure 3)

Figure 3: All files were successfully copied in test1 folder


In COPY FOLDER function, after selecting the files, instead of right clicking on the selected file itself, you have to go to the root folder (image entries) and right click on it. Select COPY FOLDER function from the menu and wahla! All files together with its folder structure are copied into the designated folder, in this case “test2” folder. (Figure 4 and 5)

Figure 4: COPY FOLDER function
Notice that unlike the COPY/UNERASE function; the name of the files will not be appended with numbers behind. This is because each file will be contained within their folder. The name of the file will change if more than one file with the same name is being copied to the same folder.

Figure 5 : All folder structure are being copied together with the selected file

Figure 6: Target file that contain within the folder structure

CASE STUDY: MISBEHAVIORS ON COPYING FILES WITH SAME FILENAMESWe have seen and understood how both functions, COPY/UNERASE and COPY FOLDER behave when copying files with the same filename, so now let us take a look at some of the misbehaviors.

Experiment 1: COPY/UNERASE function missed out files with different filename

Two files were selected, “INCORP~1 final copy.dot” and “INCORP~1.dot”. Both files used different filenames. They were being COPY/UNERASE to “test3” folder. (Figure 7)

EnCase notification windows showed that both files have been successfully copied to ‘test3’. (Figure 8)

Figure 7: Two files were COPY/UNERASE to folder “test3”

Figure 8: EnCase notification window showed ‘Status: Completed’ window..
When I checked on the “test3” folder, only one file was being copied ‘INCORP~1 final copy.dot’

EnCase didn’t notify the user on the file which went missing. (Figure 9)

Figure 9: Only one file was being exported out to test3 folder.
On the other hand, when I copied files with the same filename, Encase had no problem appending the numbers behind the files. (Figure 10& 11)

Figure 10: Six files with same name are COPY/UNERASE to a “test4” folder.

Figure 11: Six files successfully being copied from EnCase with number append behind each filename.
Question to ask: Why did the COPY/UNERASE function not working for files with different filenames?

Experiment 2: File being overwritten by COPY/UNERASE function

When files being COPY/UNERASE one at a time, file with the same name are being overwritten, without being notified by EnCase on whether to perform overwritten, or renaming the file with a different file name.

For this experiment, I have hashed both files that I wish to copy one at a time. Both were of different hash values. This was to ensure that both files were different. After the first COPY/UNERASE, the first “Annual return 2006.doc” was found in the test4 folder.

Figure 12: COPY/UNERASE “Annual Return 2006.doc” into “test4” folder.

Next, the second “Annual Return 2006.doc” was copied into the ‘test4’ folder. Notice that although there was another file exists in the folder, no prompt was done by EnCase to notify the user that the EnCase was overwriting the file inside the ‘test4’ folder.

Figure 13: COPY/UNERASE second “Annual Return 2006.doc” into “test4” folder.
As you can see here, in the “test4” folder, the previous copy of the document has been overwritten by the second document. This can be noticed by looking at the different file size of the document from the original one and also the hash value.

Figure 14: The first copied file was overwritten by the second copied file.
Few more experiments showed that the COPY FOLDER function also produced the same misbehaviors. But what cause this to happen?


The result from the experiment is, when you copy 2 files with same filename to a destination folder, all the files will appear in that folder. (Please refer to figure 11)

But if you copy 2 files; one with 8.3 characters filename + tilde (~), and the other with similar first 6 characters, EnCase will overwrite the file. (Please refer to figure 7, 8 and 9)

Based on the characteristics of the missing file, it can only point to one clue, that is the 8.3 file name format or a.k.a Short Filename (SFN) .


SFN generally contain maximum eight characters file name, followed by a period (.) and end with a maximum three characters extension. Windows support Long File Name (LFN) format, but in order to maintain backward compatibility with legacy programs (MS-DOS based or 16-bit Windows-based programs), Windows will also generate SFN for these program to access the files.

So in order to generate SFN from LFN, windows will have to follow certain rules: 1 2

1. If LFN is 8.3 uppercase, it will straight away be stored as SFN. No LFN will be stored in hard disk.
2. If LFN is 8.3 mixed cases, LFN will be store as 8.3 mixed cases while the SFN will be store as 8.3 uppercase.
3. Invalid characters (. “/ \ [ ]:; = ,) and space will be deleted from LFN.
4. L FN will be truncated to maximum 6 characters followed by tilde (~) and a digit.
5. Extension of the file will be truncated to maximum 3 characters.
6. All characters will then be converted to uppercase.
7. Beginning with Windows 2000, if at least 4 files or folders already exist with the same initial 6 characters in their short names, the stripped LFN is instead truncated to the first 2 letters of the basename (or 1 if the basename has only 1 letter), followed by 4 hexadecimal digits derived from an undocumented hash of the filename, followed by a tilde, followed by a single digit, followed by a period “.”, followed by the first 3 characters of the extension.

Example: Long File Name(LFN) Short File Name (SFN) This is a very long file name.123.docx THIS~1.DOC (RULES NO. 3-6)

TE021F~1.TXT (RULES NO. 7)


This hypothesis is made based on the Windows filename format, there may be some differences in term of the actual LFN or SFN generated by EnCase due to different coding, but since EnCase was written in Windows platform, it is being assumed that EnCasewill follow the same file naming rules as in the Windows. As long as Windows recognized that both files are different, EnCase will also use the same rules , thus, no two files with the same name will be overwritten with each other.

So back to our problem, when EnCase copies file “INCORP~1.dot” and “INCORP~1 final copy.dot” (As shown in Experiment 1), EnCase recognizes them as two different files. However when they are saved to the designated folder in Windows, the Windows will treat “INCORP~1.dot” as the short file name of “INCORP~1 final copy.dot”. Hence, Windows will only save the INCORP~1 final copy.dot file. Long File Name Short File Name No LFN will be stored in hard disk (RULE No. 1) INCORP~1.DOT

INCORP~1 final copy.dot
When EnCase COPY/UNERASE all the six files with the same INCORP~1.DOT, Windows is able to recognize each individual file, by its LFN. EnCase which operates under the same file naming rules, will also be able to differentiate those files and append numbers behind each filename as their LFN. The Windows LFN are not used in this case. Long File Name (Windows) Long File Name (EnCase) Short File Name IN1233~1. DOC (RULE No. 7) INCORP~1. DOT INCORP~1. DOT
IN1233~2.DOC (RULE No. 7)
IN1233~4. DOC (RULE No. 7)
INCORP~1. DOT IN1233~5. DOC (Rule No. 7) INCORP~14. DOT INCORP~1. DOT
IN1233~5. DOC (Rule No. 7)


From these experiments, I discovered that the only solution to overcome the misbehaviors as mentioned above is to disable the SFN support in Windows. How do we do that?

1. Edit the registry to disable the NtfsDisable8dot3NameCreation
2. Change the value from 2 to 1.
3. Restart your workstation,

Now you can export any file with the same SFN because your Windows now can support filename of up to 256 characters(Figure 15). However if you have difficulties accessing files from some legacy programs, you can always change back the registry setting. I have thus submitted these technical problems to Guidance Software and they are now looking into it to come up with a solution. Hopefully they can come up with a new patch to solve it.

Figure 15: Changing the value in registry setting


1 Wikipedia-8.3 filename http://en.wikipedia.org/wiki/8.3_filename#cite_note-3
2 Microsoft Developer Network (MSDN)

2 thoughts on “EnCase file copying and Windows Short File Names”

Leave a Comment

Latest Articles