Backup Files order different from original

dsperber said:

albertkao said:

My original files order on C:\Romans is as follows.
I copied the files to USB flash drive G by drag and drop.
The backup files order on drive G is different from C drive.
e.g. Romans14.mp3 becomes the first file listed on drive G.

I'm still thinking about this issue...

After my post above that at least explains the difference between FAT16/FAT32 directories and NTFS directories, and why this results in different directory display sequences whether using DOS ("DIR" or "DIR /on") vs. Windows Explorer, I still had a question about the source folder going into the copy process.

I thought you'd simply used a DOS "COPY", and then were looking at the results with a DOS "DIR", and I assumed that the source directory was equally out-of-order alphabetically. But now looking again at your original two directories I see that it's not. The source directory on C is in sequence alphabetically.

Also, your C-drive is NTFS, so it would have to be alphabetical.

Now I see you say that you used drag/drop to do the copy from C to G (your FAT32 USB drive). Did you select all files together from C, and then drag/drop/copy them onto G together? Or did you do it in two steps... first 14-16, and then 1-13 in a second drag/drop/copy?

I still am 100% positive that a DOS "DIR" command is purely in physical directory order, which means date/time order of when the files were actually created. So in order for 14-16 to appear first in your DIR of the target G version of the directory, that would imply that 14-16 had been created first (in time), and then 1-13 had been created subsequently.

So... do you recall the order in which or how you did the original copy? Was it all 16 at once in one drag/drop/copy, and somehow Windows scrambled which files got created first on G? Or did you actually do 14-16 first, and then 1-13 second?

Have you tried just doing a DOS COPY, to see (or confirm) that the output directory on G will look EXACTLY like the input directory on C? I would think that has to happen, since the DOS COPY is a loop of individual copies, retrieving an input file from the input directory via GETNEXT and copying it, and then retrieving the next input file from the input directory via GETNEXT and copying it, etc. You'd think that this would produce an exact duplicate in sequence of the files on the ouput, matching the input files... per the DOS DIR sequence.


Again, I know that the DOS DIR command works the way it does. That's why they added an "/on" opeand, to allow you to request an alphabetcial display instead of the date/time sequence which is what DIR just does on FAT16/FAT32.

So I'm still unhappy, until we can explain how/why files 14-16 got created first on G, and 1-13 second.

I can certainly try this myself (which I probably will). I will use both Windows Explorer and Free Commander (an Explorer equivalent) for the drag/drop of all 16 files at once, to see how it comes out. And I will also try a DOS COPY.

Using DOS "COPY" (c:\Romans>copy * g:\) solve the problem!
Looking at the results with a DOS "DIR" confirm that the files on G: are listed alphabetcially.
Thanks:).

albertkao said:

Using DOS "COPY" (c:\Romans>copy * g:\) solve the problem!
Looking at the results with a DOS "DIR" confirm that the files on G: are listed alphabetcially.
Thanks:).

AHA!!!

Excellent. Glad to help.

logicearth said:

Curious....Why does then even matter?

The DOS "DIR" command retrieves and displays directory entries using a GETNEXT mechanism. Whatever the order delivered by GETNEXT, that's what "DIR" shows.

In contrast, "DIR /on" sorts the all entries retrieved into alphabetical sequence first and then presents them. The list from "DIR /on" will therefore always be "ordered by name", i.e. alphabetical.

For FAT16/FA32 directories, the directory entries presented by GETNEXT are from a directory chain, which has new elements for new files always added to the end (no matter what the alphabetical filename is). So a FAT16/FAT32 direct entry chain is always in date/time sequence, chronologically increasing by the date/time when that filename's entry was added to the end of the chain at that time. GETNEXT delivers entries in physical chain sequence, which means date/time by when the item was created.

In contrast, NTFS directories are maintained sorted alphabetically, and new items are inserted wherever they belong... to keep the alphabetical order of the directory entries. So GETNEXT for NTFS always delivers entries in alphabetical sequence, since that's the inherent structure of the directory.

Now DOS "COPY" is just a loop of GETNEXT-from-input/write-to-output. So the physical sequence of additions to the output will exactly match the order of directory entries delivered from the input as presented by GETNEXT.

Since his input is on NTFS, the GETNEXT loop against that directory will present entries in alphabetical sequence. As each one is retrieved, and written to the output which is on FAT32, a new directory entry is added to the end of the FAT32 directory chain. The output chain will thus be sequenced exactly identical to the GETNEXT sequence from the input directory.

And since the GETNEXT from NTFS input is always alphabetical, each new entry added on the FAT32 output directory chain will be added to the end, thus producing a FAT32 chain which is therefore being built in alphabetical sequence.

So when the finished FAT32 is displayed using DIR, i.e. retrieved in GETNEXT sequence by retrieving sequentially linked items from its FAT32 directory chain (actually in date/time sequence by when it was created), each entry retrieved will therefore also be in alphabetical sequence as well.


Still unanswered is how he got what he got originally using drag/drop via Windows Explorer rather than DOS "COPY". If he selected the entire group and copied it, you'd think the whole group would be copied in the order in which Windows Explorer saw it (which is actually always alphabetical no matter what type of file system).

So it seems like the only way he could have ended up with 14-16 and then 1-13 as "physical sequential chain sequence, by date/time of addition" is if he'd copied 14-16 first, and then did a second copy of 1-13.

Anyway, DOS "COPY" from NTFS to any output file system is guaranteed to produce alphabetical sequence on the output, because NTFS directories are always maintained alphabetically.

logicearth said:

Right...but why would it even matter?
Stuff like this screams OCD to me. AKA. waste of time.

Why would the sorting of files matter for a backup?
Shouldn't the existence of the files be enough for a backup?

I see what you're getting at now... and, to be honest, I agree with you.

Who cares??

dsperber said:

logicearth said:

Right...but why would it even matter?
Stuff like this screams OCD to me. AKA. waste of time.

Why would the sorting of files matter for a backup?
Shouldn't the existence of the files be enough for a backup?

I see what you're getting at now... and, to be honest, I agree with you.

Who cares??

The sorting of files matter for a backup because I use the backup USB flash drive and insert it to a mp3/CD player to play the mp3 files on it.
The order of the mp3 files on the backup USB flash drive is important because they corresponds to the tracks of a ripped CD.
Maybe "backup" is a bad choice of word to describe the USB flash drive.
How about "portable"?
i.e. the portable USB flash drive is used to store the mp3 files.
Therefore it is not OCD .

albertkao said:

The sorting of files matter for a backup because I use the backup USB flash drive and insert it to a mp3/CD player to play the mp3 files on it.

The order of the mp3 files on the backup USB flash drive is important because they corresponds to the tracks of a ripped CD.

Just a comment on this...

With my Cowon J3 player, if you play an individual "album" folder (based on a browse of the tags database, developed by examining the tags in each music file), the order of play is actually TRACK NUMBER SEQUENCE, based on the internal track number field in the tag. In other words, typically you would start the tags-based browse by Artist, and then seeing all of the albums under that artist you would select a single "album" folder to play. All of this is really based on the tag field values, not the external physical folder/file names. And internal "track number" from the tag is the play sequence for this type of browse.

On the other hand, if you browse by "folder" (exactly like a Windows Explorer navigation, i.e. in alphabetical sequence by folder or file name) then the presentation and play sequence is purely alphabetical.

If your particular music player and its use of external USB drives is only like the "folder" browse of my Cowon J3, then I guess I can understand why this is important to you if your file names contain the track name imbedded (e.g. the 01, 02, 03, etc., at the end of your file names) since that will determine the sequential access of the FAT32 directory by the device... i.e. the CD track sequence, but based on external file name.

No such problem for my Cowon J3, as EITHER approach is possible... (a) track number sequence based on internal tag, or (b) alphabetical external file name sequence, depending on how you initiate the "browse".