What does it mean to get a Set File Information IRP/FileBasicInformation
where all the fields in the FILE_BASIC_INFORMATION structure are zero?
An application doing a backupread on a directory causes this to happen.
Ken
It’s a no-op as far as I can tell from FastFat source. Strange.
Ken Galipeau wrote:
What does it mean to get a Set File Information IRP/FileBasicInformation
where all the fields in the FILE_BASIC_INFORMATION structure are zero?An application doing a backupread on a directory causes this to happen.
Ken
–
Nick Ryan
(Microsoft Windows MVP for DDK)
> What does it mean to get a Set File Information IRP/FileBasicInformation
where all the fields in the FILE_BASIC_INFORMATION structure are zero?
A little off-topic, but:
I found an interesting thing when I called IRP_MJ_GET_INFORMATION.
I received STATUS_SUCCESS as the result, but the returned length
(in IO_STATUS_BLOCK) has been zero.
Does anyone know something about this ?
I was the file NTUSER.DAT on the network, the problem occured
then an user logged off and his roaming profile has been
copied to the network.
L.
If the FileAttributes field is zero it means the attributes are not being
set. If any of the time fields are -1 it means that time field is not being
set.
So for example Win32 SetFileAttributes boils down to FileBasicInformation
with all of the time fields set to -1, and Win32 SetFileTime boils down to
FileBasicInformation with the attributes set to zero, and the ChangeTime set
to -1 (?), and the other time fields derived from the parameter values.
I would have assumed all fields zero means dont change the attributes and
set the file times to the start of 1601 in the absence of other information.
However in the fastfat sources time fields of -1 are replaced with time
fields of zero and later the if value for a time field is zero that field is
ignored. So in the case of fastfat it means that time field values of zero
and -1 are equivalent. It also means in the case of fastfat you cannot set
the file times to the start of year 1601 but that doesnt seem so
unreasonable.
The result as Nick says is that in fastfat its a no-op … except … maybe
somewhere are checks that the caller is allowed to set the attributes and
maybe the caller is testing whether it passes those checks without wating to
in fact change the attributes or file times … or … does this side effect
a modification of the ChangeTime in some file systems? Just some thoughts.
“Nick Ryan” wrote in message news:xxxxx@ntfsd…
> It’s a no-op as far as I can tell from FastFat source. Strange.
>
> Ken Galipeau wrote:
>
> > What does it mean to get a Set File Information IRP/FileBasicInformation
> > where all the fields in the FILE_BASIC_INFORMATION structure are zero?
> >
> > An application doing a backupread on a directory causes this to happen.
> >
> > Ken
>
> –
> Nick Ryan
> (Microsoft Windows MVP for DDK)
>
The value of -1 in any time stamp field means that the underlying FSD should
not update that field when the file is closed. For example:
Open file for read
Set LastAccessed to -1
Close file —> Last access with NOT be updated.
In the past, trying to reset LastAccessed time would result in ChangeTime
being set by NTFS! If you really don’t want any time stamps to change, set
them all to -1 after you open the file.
The value of 0 means “do not set at this time”. It does not affect the
normal FSD handling of updating these fields.
A side note: An attribute value of 0 will NEVER be returned by an FSD.
FILE_ATTRIBUTE_NORMAL is used to clear other attributes.
/ted
-----Original Message-----
From: Lyndon J Clarke [mailto:xxxxx@neverfailgroup.com]
Sent: Tuesday, January 20, 2004 2:15 PM
To: Windows File Systems Devs Interest List
Subject: Re:[ntfsd] FILE_BASIC_INFORMATION
If the FileAttributes field is zero it means the attributes are not being
set. If any of the time fields are -1 it means that time field is not being
set.
So for example Win32 SetFileAttributes boils down to FileBasicInformation
with all of the time fields set to -1, and Win32 SetFileTime boils down to
FileBasicInformation with the attributes set to zero, and the ChangeTime set
to -1 (?), and the other time fields derived from the parameter values.
I would have assumed all fields zero means dont change the attributes and
set the file times to the start of 1601 in the absence of other information.
However in the fastfat sources time fields of -1 are replaced with time
fields of zero and later the if value for a time field is zero that field is
ignored. So in the case of fastfat it means that time field values of zero
and -1 are equivalent. It also means in the case of fastfat you cannot set
the file times to the start of year 1601 but that doesnt seem so
unreasonable.
The result as Nick says is that in fastfat its a no-op … except … maybe
somewhere are checks that the caller is allowed to set the attributes and
maybe the caller is testing whether it passes those checks without wating to
in fact change the attributes or file times … or … does this side effect
a modification of the ChangeTime in some file systems? Just some thoughts.
“Nick Ryan” wrote in message news:xxxxx@ntfsd…
> It’s a no-op as far as I can tell from FastFat source. Strange.
>
> Ken Galipeau wrote:
>
> > What does it mean to get a Set File Information
> > IRP/FileBasicInformation where all the fields in the
> > FILE_BASIC_INFORMATION structure are zero?
> >
> > An application doing a backupread on a directory causes this to
> > happen.
> >
> > Ken
>
> –
> Nick Ryan
> (Microsoft Windows MVP for DDK)
>
—
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: xxxxx@livevault.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
I’ve seen cmd’s dir command show now time for files. I think they were
copied from a CD, perhaps by a non admin. I thought it was wierd. I
forget what my Win32 showed for the files.
Sure you can get the year 1601, just use the value 1?
But FAT actually doesn’t have many bits on disk, right? It’s limited to
two second increments since 1980, right?
- Jay