Hi all.
How can a device be identified as a ShadowCopy?
Is it sufficient to query its “DeviceType”, and see if it equals “FILE_DEVICE_VIRTUAL_DISK” ?
Looking forward to some help.
Regards
Ajay
Ajay,
There is a nice wrapper function in the sfilter example that is in older
DDKs. See sfilter.c, function SfIsShadowCopyVolume.
Different versions of windows required doing different things.
Regards
Ben
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@gmail.com
Sent: 08 June 2010 11:47
To: Windows File Systems Devs Interest List
Subject: [ntfsd] How to identify a device as ShadowCopy?
Hi all.
How can a device be identified as a ShadowCopy?
Is it sufficient to query its “DeviceType”, and see if it equals
“FILE_DEVICE_VIRTUAL_DISK” ?
Looking forward to some help.
Regards
Ajay
NTFSD is sponsored by OSR
For our schedule of debugging and file system seminars (including our
new fs mini-filter seminar) visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
Ben,
Thanks for the reply.
We are using the same code in our application. 
Ok, I will come to the current issue we are facing. In Vista Business, while creating shadow copies as part of System-Restore, there are cases, wherein the volumes fulfill the criteria of “DeviceType == FILE_DEVICE_VIRTUAL_DISK”, but fail the read-only criteria.
All such volumes, satisfying the first criteria, have names of type “HardDiskVolumeShadowCopyN”.
Your thoughts …?
Will be grateful for further replies.
Thanks and Regards
Ajay
Ajay,
I don’t have a Vista VM in a bootable state (!) at the moment but from
memory if you query the driver name of the storage stack device object
it should be \Driver\VolSnap, like the WindowsXP case.
This is going from memory though so don’t quote me!
Ben
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@gmail.com
Sent: 08 June 2010 12:28
To: Windows File Systems Devs Interest List
Subject: RE:[ntfsd] How to identify a device as ShadowCopy?
Ben,
Thanks for the reply.
We are using the same code in our application.
Ok, I will come to the current issue we are facing. In Vista Business,
while creating shadow copies as part of System-Restore, there are cases,
wherein the volumes fulfill the criteria of “DeviceType ==
FILE_DEVICE_VIRTUAL_DISK”, but fail the read-only criteria.
All such volumes, satisfying the first criteria, have names of type
“HardDiskVolumeShadowCopyN”.
Your thoughts …?
Will be grateful for further replies.
Thanks and Regards
Ajay
NTFSD is sponsored by OSR
For our schedule of debugging and file system seminars (including our
new fs mini-filter seminar) visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
Does the “vssadmin list shadows” command from a command prompt on XP show you something different for the shadow copy volume name compared to the other OS versions your working with? I believe you’ve found the correct device. Why it is not marked as read only is interesting. Perhaps some other component of your backup solution is interacting with the device and changing it? From experience, the default state of the shadow copy after it has been created is read only.
Not much help,
-Robert
On Jun 8, 2010, at 6:50 AM, Ben Lewis wrote:
Ajay,
I don’t have a Vista VM in a bootable state (!) at the moment but from
memory if you query the driver name of the storage stack device object
it should be \Driver\VolSnap, like the WindowsXP case.This is going from memory though so don’t quote me!
Ben
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@gmail.com
Sent: 08 June 2010 12:28
To: Windows File Systems Devs Interest List
Subject: RE:[ntfsd] How to identify a device as ShadowCopy?Ben,
Thanks for the reply.
We are using the same code in our application.Ok, I will come to the current issue we are facing. In Vista Business,
while creating shadow copies as part of System-Restore, there are cases,
wherein the volumes fulfill the criteria of “DeviceType ==
FILE_DEVICE_VIRTUAL_DISK”, but fail the read-only criteria.All such volumes, satisfying the first criteria, have names of type
“HardDiskVolumeShadowCopyN”.Your thoughts …?
Will be grateful for further replies.
Thanks and Regards
Ajay
NTFSD is sponsored by OSR
For our schedule of debugging and file system seminars (including our
new fs mini-filter seminar) visit:
http://www.osr.com/seminarsTo unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
NTFSD is sponsored by OSR
For our schedule of debugging and file system seminars
(including our new fs mini-filter seminar) visit:
http://www.osr.com/seminarsTo unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
robert, others,
what abt other providers other than vss? wht abt hardware based
snapshots do they also folow the same convention of naming, probably
not. the code in sfilter, wouldnt detect them, would they?
On 6/9/10, Robert Randall wrote:
>
> Does the “vssadmin list shadows” command from a command prompt on XP show
> you something different for the shadow copy volume name compared to the
> other OS versions your working with? I believe you’ve found the correct
> device. Why it is not marked as read only is interesting. Perhaps some
> other component of your backup solution is interacting with the device and
> changing it? From experience, the default state of the shadow copy after it
> has been created is read only.
>
> Not much help,
> -Robert
>
>
> On Jun 8, 2010, at 6:50 AM, Ben Lewis wrote:
>
>>
>> Ajay,
>>
>> I don’t have a Vista VM in a bootable state (!) at the moment but from
>> memory if you query the driver name of the storage stack device object
>> it should be \Driver\VolSnap, like the WindowsXP case.
>>
>> This is going from memory though so don’t quote me!
>>
>> Ben
>>
>> -----Original Message-----
>> From: xxxxx@lists.osr.com
>> [mailto:xxxxx@lists.osr.com] On Behalf Of
>> xxxxx@gmail.com
>> Sent: 08 June 2010 12:28
>> To: Windows File Systems Devs Interest List
>> Subject: RE:[ntfsd] How to identify a device as ShadowCopy?
>>
>> Ben,
>>
>> Thanks for the reply.
>> We are using the same code in our application.
>>
>> Ok, I will come to the current issue we are facing. In Vista Business,
>> while creating shadow copies as part of System-Restore, there are cases,
>> wherein the volumes fulfill the criteria of “DeviceType ==
>> FILE_DEVICE_VIRTUAL_DISK”, but fail the read-only criteria.
>>
>> All such volumes, satisfying the first criteria, have names of type
>> “HardDiskVolumeShadowCopyN”.
>>
>> Your thoughts …?
>>
>> Will be grateful for further replies.
>>
>>
>> Thanks and Regards
>> Ajay
>>
>> —
>> NTFSD is sponsored by OSR
>>
>> For our schedule of debugging and file system seminars (including our
>> new fs mini-filter seminar) visit:
>> http://www.osr.com/seminars
>>
>> To unsubscribe, visit the List Server section of OSR Online at
>> http://www.osronline.com/page.cfm?name=ListServer
>>
>> —
>> NTFSD is sponsored by OSR
>>
>> For our schedule of debugging and file system seminars
>> (including our new fs mini-filter seminar) visit:
>> http://www.osr.com/seminars
>>
>> To unsubscribe, visit the List Server section of OSR Online at
>> http://www.osronline.com/page.cfm?name=ListServer
>
>
> —
> NTFSD is sponsored by OSR
>
> For our schedule of debugging and file system seminars
> (including our new fs mini-filter seminar) visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
–
- amitr0
Yes, they follow the same naming convention. The names are assigned
through the VSS service and are not assigned by the hardware provider.
-Robert.
On Wed, Jun 9, 2010 at 12:10 PM, amitr0 wrote:
> robert, others,
>
> what abt other providers other than vss? wht abt hardware based
> snapshots do they also folow the same convention of naming, probably
> not. the code in sfilter, wouldnt detect them, would they?
>
> On 6/9/10, Robert Randall wrote:
>>
>> Does the “vssadmin list shadows” command from a command prompt on XP show
>> you something different for the shadow copy volume name compared to the
>> other OS versions your working with? ?I believe you’ve found the correct
>> device. ?Why it is not marked as read only is interesting. ?Perhaps some
>> other component of your backup solution is interacting with the device and
>> changing it? ?From experience, the default state of the shadow copy after it
>> has been created is read only.
>>
>> Not much help,
>> -Robert
>>
>>
>> On Jun 8, 2010, at 6:50 AM, Ben Lewis wrote:
>>
>>>
>>> Ajay,
>>>
>>> I don’t have a Vista VM in a bootable state (!) at the moment but from
>>> memory if you query the driver name of the storage stack device object
>>> it should be \Driver\VolSnap, like the WindowsXP case.
>>>
>>> This is going from memory though so don’t quote me!
>>>
>>> Ben
>>>
>>> -----Original Message-----
>>> From: xxxxx@lists.osr.com
>>> [mailto:xxxxx@lists.osr.com] On Behalf Of
>>> xxxxx@gmail.com
>>> Sent: 08 June 2010 12:28
>>> To: Windows File Systems Devs Interest List
>>> Subject: RE:[ntfsd] How to identify a device as ShadowCopy?
>>>
>>> Ben,
>>>
>>> Thanks for the reply.
>>> We are using the same code in our application.
>>>
>>> Ok, I will come to the current issue we are facing. In Vista Business,
>>> while creating shadow copies as part of System-Restore, there are cases,
>>> wherein the volumes fulfill the criteria of “DeviceType ==
>>> FILE_DEVICE_VIRTUAL_DISK”, but fail the read-only criteria.
>>>
>>> All such volumes, satisfying the first criteria, have names of type
>>> “HardDiskVolumeShadowCopyN”.
>>>
>>> Your thoughts …?
>>>
>>> Will be grateful for further replies.
>>>
>>>
>>> Thanks and Regards
>>> Ajay
>>>
>>> —
>>> NTFSD is sponsored by OSR
>>>
>>> For our schedule of debugging and file system seminars (including our
>>> new fs mini-filter seminar) visit:
>>> http://www.osr.com/seminars
>>>
>>> To unsubscribe, visit the List Server section of OSR Online at
>>> http://www.osronline.com/page.cfm?name=ListServer
>>>
>>> —
>>> NTFSD is sponsored by OSR
>>>
>>> For our schedule of debugging and file system seminars
>>> (including our new fs mini-filter seminar) visit:
>>> http://www.osr.com/seminars
>>>
>>> To unsubscribe, visit the List Server section of OSR Online at
>>> http://www.osronline.com/page.cfm?name=ListServer
>>
>>
>> —
>> NTFSD is sponsored by OSR
>>
>> For our schedule of debugging and file system seminars
>> (including our new fs mini-filter seminar) visit:
>> http://www.osr.com/seminars
>>
>> To unsubscribe, visit the List Server section of OSR Online at
>> http://www.osronline.com/page.cfm?name=ListServer
>>
>
>
> –
>
> - amitr0
>
> —
> NTFSD is sponsored by OSR
>
> For our schedule of debugging and file system seminars
> (including our new fs mini-filter seminar) visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
>
–
Robert Randall | xxxxx@gmail.com
Robert,
the volume is detected non-readonly, during the time when the shadowcopy is created. Might be the case that when the shadow-volume is being created, “something” is written onto it. Afterwards, once the volume is ready, it is set as readonly.
Any Microsoft guys listening …???
Thanks Robert anyways. Every bit of info is worth.
Regards
Ajay
The snapshot volume( created with VSS_VOLSNAP_ATTR_AUTORECOVER flag) is
created writable to enable the VSS writers to write their data on the
snapshot. Only once the writer are done, the volume is set read-only.
Thanks
On Mon, Jun 14, 2010 at 11:31 AM, wrote:
> Robert,
>
> the volume is detected non-readonly, during the time when the shadowcopy is
> created. Might be the case that when the shadow-volume is being created,
> “something” is written onto it. Afterwards, once the volume is ready, it is
> set as readonly.
>
> Any Microsoft guys listening …???
>
> Thanks Robert anyways. Every bit of info is worth.
>
>
> Regards
> Ajay
>
> —
> NTFSD is sponsored by OSR
>
> For our schedule of debugging and file system seminars
> (including our new fs mini-filter seminar) visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
Nitesh,
That was a ton-ful of information. Also,
http://msdn.microsoft.com/en-us/library/aa385012(VS.85).aspx
mentions this flag to be present from Vista onwards only, which brings a certain peace of mind, as the current issue surfaces only on Vista.
Thanks … finally some progress seems to be in light.
So, what should be the criteria for determining the shadowvolume-ness of a Vista volume (a criteria that fits in at all times … after all a file-system filter driver needs a deterministic algorithm to determine a volume as a shadow copy).
Thanks again Nitesh for the direction.
Regards
Ajay
I would have answered if I knew a good answer for that . I too have been
grappling for some days now to find a deterministic way for that from my
volume filter. The thing is, you cannot rely on the device name like
“HardDiskVolumeShadowCopyN”,
which is used only the MS default provider volsnap. Other software snapshot
providers can use a different name. In case of h/w snapshot, the snapshot
volume is created by ftdisk/volmgr with the name “HardDiskVolumeN”, similar
to any other real volume. I am not sure of the “DeviceType” for those h/w
snapshots, some implementations might give the correct thing, some might
not, I guess.
I thought of storing some “data”( unique guid maybe ) on the base volume &
on arrival of volumes(real or shadow), read the data from the volume & try
to match it against the “data” of the volume list we already have. A match
would indicate that the volume is a shadow of a device in our list. But this
method suffers from the problem that in case of h/w snapshot, there is no
guarantee that base volume would be created before snapshot volume in case
of reboot( both are exposed as LUNs by the h/w snapshot provider &
ftdisk/volmgr may not know if they are different)
Thanks
On Tue, Jun 15, 2010 at 9:55 AM, wrote:
> Nitesh,
>
> That was a ton-ful of information. Also,
> http://msdn.microsoft.com/en-us/library/aa385012(VS.85).aspx
> mentions this flag to be present from Vista onwards only, which brings a
> certain peace of mind, as the current issue surfaces only on Vista.
>
> Thanks … finally some progress seems to be in light.
>
> So, what should be the criteria for determining the shadowvolume-ness of a
> Vista volume (a criteria that fits in at all times … after all a
> file-system filter driver needs a deterministic algorithm to determine a
> volume as a shadow copy).
>
>
> Thanks again Nitesh for the direction.
>
> Regards
> Ajay
>
> —
> NTFSD is sponsored by OSR
>
> For our schedule of debugging and file system seminars
> (including our new fs mini-filter seminar) visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
If my memory serves me ok, I remember my minifilter got a reliable failure (sic) when calling FltGetVolumeGiudName(). Precautions apply: you can’t call this guy from instance setup callback, unless your customers are fine without Windows XP support.
I believe you will always get reliable volume names if you ask the VSS
service from user space. I know that would complicate things a bit by
requiring a user mode process to send the information to your driver
but I believe it is deterministic and guaranteed. Check the VSS
client API for more information.
Regards,
Robert.
On Wed, Jun 16, 2010 at 4:27 AM, wrote:
> If my memory serves me ok, I remember my minifilter got a reliable failure (sic) when calling FltGetVolumeGiudName(). Precautions apply: you can’t call this guy from instance setup callback, unless your customers are fine without Windows XP support.
>
> —
> NTFSD is sponsored by OSR
>
> For our schedule of debugging and file system seminars
> (including our new fs mini-filter seminar) visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
>
–
Robert Randall | xxxxx@gmail.com
Hi,
In Vista and later you can use FltIsVolumeSnapshot. Internally this uses IOCTL_VOLUME_GET_GPT_ATTRIBUTES looking for GPT_BASIC_DATA_ATTRIBUTE_SHADOW_COPY.
Thanks,
Scott
it looks like simple and reliable solution
this ioctl available since XP
however sfilter in WinDDK has another method for shadow copy volumes recognition
why ?
On Jun 22, 2010, at 4:53 AM, xxxxx@microsoft.com wrote:
Hi,
In Vista and later you can use FltIsVolumeSnapshot. Internally this uses IOCTL_VOLUME_GET_GPT_ATTRIBUTES looking for GPT_BASIC_DATA_ATTRIBUTE_SHADOW_COPY.
Thanks,
Scott
NTFSD is sponsored by OSR
For our schedule of debugging and file system seminars
(including our new fs mini-filter seminar) visit:
http://www.osr.com/seminarsTo unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
While the IOCTL is available on XP the GPT_BASIC_DATA_ATTRIBUTE_SHADOW_COPY attribute is not available until Vista and Win2003 SP1.
Thanks,
Scott
http://msdn.microsoft.com/en-us/library/dd627180(VS.85).aspx
is it documentation bug ?
btw code like this works fine at least at 2003 R2
NTSTATUS OnAttach(PCFLT_RELATED_OBJECTS Objs,
FLT_INSTANCE_SETUP_FLAGS,
DEVICE_TYPE DevType,
FLT_FILESYSTEM_TYPE)
{
PDEVICE_OBJECT device;
NTSTATUS stat = FltGetDiskDeviceObject(Objs->Volume, &device);
if (NT_SUCCESS(stat))
{
RefObj ro1(device);
KEVENT evnt;
KeInitializeEvent(&evnt, NotificationEvent, FALSE);
VOLUME_GET_GPT_ATTRIBUTES_INFORMATION attrs = {0};
IO_STATUS_BLOCK iosb;
PIRP irp = IoBuildDeviceIoControlRequest(IOCTL_VOLUME_GET_GPT_ATTRIBUTES,
device,
0,
0,
&attrs,
sizeof(attrs),
FALSE,
&evnt,
&iosb);
if (irp)
{
stat = IoCallDriver(device, irp);
if (STATUS_PENDING == stat)
{
KeWaitForSingleObject(&evnt, Executive, KernelMode, FALSE, 0);
stat = iosb.Status;
}
if (NT_SUCCESS(stat))
{
if (attrs.GptAttributes & GPT_BASIC_DATA_ATTRIBUTE_SHADOW_COPY)
{
bool shadow = true;
}
}
}
}
return STATUS_FLT_DO_NOT_ATTACH;
}
On Jun 22, 2010, at 8:36 PM, xxxxx@microsoft.com wrote:
While the IOCTL is available on XP the GPT_BASIC_DATA_ATTRIBUTE_SHADOW_COPY attribute is not available until Vista and Win2003 SP1.
Thanks,
Scott
NTFSD is sponsored by OSR
For our schedule of debugging and file system seminars
(including our new fs mini-filter seminar) visit:
http://www.osr.com/seminarsTo unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
Sergey,
OS Version info about GPT_BASIC_DATA_ATTRIBUTE_SHADOW_COPY is at http://msdn.microsoft.com/en-us/library/aa381621(VS.85).aspx.
Thanks,
Scott
Scott, great thanks
Still, one confusing moment - IOCTL_VOLUME_GET_GPT_ATTRIBUTES, VOLUME_GET_GPT_ATTRIBUTES_INFORMATION, GPT_BASIC_DATA_ATTRIBUTE_SHADOW_COPY.
GPT everywhere. I tried this for MBR disk and looks like everything ok - it’s working. Nothing said about MBR and GPT in ioctl documentation. So i’m not sure if this method fits mbr and gpt both.
On Jun 23, 2010, at 8:38 PM, xxxxx@microsoft.com wrote:
Sergey,
OS Version info about GPT_BASIC_DATA_ATTRIBUTE_SHADOW_COPY is at http://msdn.microsoft.com/en-us/library/aa381621(VS.85).aspx.
Thanks,
Scott
NTFSD is sponsored by OSR
For our schedule of debugging and file system seminars
(including our new fs mini-filter seminar) visit:
http://www.osr.com/seminarsTo unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer