Think of an old system that would have data in blocks and records. It
doesn’t store the actual extent of the file. Therefore, to get the
actual length you have to walk the entire file, which could be several
gigabytes, or even terabytes. Takes a bit of time to do that.
I own the filesystem which is the redirector, so I’m trying to figure
out some way I could hint that the filesize is a guess. I don’t think
mapping from this old filesystem to an NT type filesystem is going to
work perfectly, unfortunately for me.
As you said, I couldn’t think of a way a filter driver could tell the
difference between a file that needs padding and a bad copy. Unless I
tried to use some magic in the high part of the filesize, but that’s
just gross, and not guaranteed to work anyway.
-Jeff
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Dejan Maksimovic
Sent: Thursday, June 15, 2006 3:52 PM
To: Windows File Systems Devs Interest List
Subject: Re: [ntfsd] File copy, when size unknown until full read
You cannot change cmd/explorer’s behavior without a filter around.
Still, a
filter cannot tell if the file actually needs padding or is a result of
such a …
copy operation.
But, I’m sure all want to know - what can be so time consuming in
determining a
file size? Unless it’s a DAT type of a bad storage algorithm.
xxxxx@emc.com wrote:
Hi,
The problem I am looking at is during a copy operation out of
a
file system, into NTFS, using the cmd.exe copy command. What happens
is
during a IRP_MJ_QUERY_INFORMATION for FileStandardInformation, a guess
as to the file size is returned. The reason for this is that the file
system is actually a virtual files system/network redirector, and
retrieves the file information from a remote machine, which does not
know the exact file size. Retrieving the exact file size is
prohibitively expensive, and therefore really isn’t an option. The
size
returned is guaranteed to be larger than the actual file size in
bytes.
Enter stage left: cmd.exe. Cmd.exe retrieves the size of the
file (the guess), and then creates a new file (lets call it Foo.txt)
and
sets that Foo.txt’s file size to the guess. Cmd.exe proceeds to copy
data from the first file to the copy, until EOF is reached. The file
system now knows the real EndOfFile, and sets the file sizes properly
in
the FCB and CacheMgr. Cmd.exe gets notified of the end of file, and
all
seems well. Until you look at Foo.txt’s size, which is the guess.
Foo.txt gets padded with nulls to the size of the guess file size.
Anybody know a way around this that DOESN’T include retrieving
the correct file size up front? Really any conversation around this
issue would be enlightening…
Thanks!
-Jeff
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: unknown lmsubst tag
argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com
–
Kind regards, Dejan M.
http://www.alfasp.com E-mail: xxxxx@alfasp.com
Alfa Transparent File Encryptor - Transparent file encryption services.
Alfa File Protector - File protection and hiding library for Win32
developers.
Alfa File Monitor - File monitoring library for Win32 developers.
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: xxxxx@emc.com
To unsubscribe send a blank email to xxxxx@lists.osr.com