In comp.sys.ibm.pc.hardware.storage micky <
NONONO...@bigfoot.com> wrote:
> (Please remember that this is a hobby for me, and I myself know an
> easier likely way to get to the final result here, but it won't
> involve a question that has intrigued me for years.)
> The question is: Is there a way to move a file to a specific place on
> the disk or partition, like the start?
> Without writing code in Assember. This question has botthered me for
> years. Once in a while there is a practical application.
It depends on the filesystem. With classical FAT, create a
new FAT filesystem and put the files on it. It will fill up
from the start. It may also be possible to use some defraggers
to the same effect. Other placement can then be achived by
filling up to the start where the files should go iwth other
data, writing the data and then remove the other files.
Other than that, you will need to programm. For a modern
filesystem like ext2/3 or NTFS, this will be hugely
complicated.
> I tthink if the partition were full to overflowing, and I coudl find
> out the name of a file that Old was the first in the partition that
> was as big as File F, the file I wanted at the start, I could delete
> Old, and copy F to the partition, and it would go in the spot that Old
> had used.
Ah, that is easier: Overwrite the old file with the new one
(not cp, file open and then write the data over it from the
beginning). Still requires coding and will not work everywhere,
but is pretty simple to do.
> But what if the partition has loads of empty space? What do MS-DOS
> and PC-DOS and various versions of windows do? Lets assume either an
> NTFS or FAT32 partition. Does it make a difference?
Very much. For FAT, new writes typically go into the first
empty space on disk. That is also why it fragments so badly.
For NTFS, I would guess that it works kind of like ext2/3
and has several pints on the disk that it groups files
around (very rough approximation).
> Will it move it to
> 1) the next available space (next after the last file moved),
> 2) the first available space (which is almost the very start of the
> parition.) . There is either enough empty space at the start of the
> partition for this file to be stored in one piece, or there is loads
> of empty space.
Here is the kicker: The decision is made _without_ knowing the
file size! The problem is that on file creation you do not
pass a parameter saying "and, hey, this is going to be this large".
You just do file creation and start writing.
> 3) Or will it try to move the file to be near other files in the same
> sub-sub-directory in which this new file will reside,, or at least the
> same sub-directory, or at least the same highest level directory?
I think a bit of that is going on in ext2/3, bit it is not
strictly directory orientated.
> Option 3 seems to violate all the rules I've heard of, but I can't
> help thinking that's what will happen.
> Option 2 is what I want. Is it likely I'll get it?
With FAT, maybe. Otherwise no.
Typically you do not want it today though.
Arno
--
Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email:
ar...@wagner.name
GnuPG: ID: 1E25338F FP: 0C30 5782 9D93 F785 E79C 0296 797F 6B50 1E25 338F
----
Cuddly UI's are the manifestation of wishful thinking. -- Dylan Evans