Hey folks,

Is there a way to get the file system format type from a UNC path? We have
an app that's using alternate data streams for storing thumbnails, and we'd
like to be able to check in advance for non-NTFS file systems (which don't
support ADS). "DriveInfo" has a "DriveFormat" property, but DriveInfo seems
to be limited to letter-mapped drives.

Thanks,
Bill

Well, on second look, getting the drive format may not matter. I mapped a
drive letter to a Samba file share UNC address on a Solaris box.
DriveInfo.DriveFormat on the mapped letter returned "NTFS", but it appears
that the volume still does not support alternate data streams. (In theory,
is an NTFS volume actually required to support ADS streams, or is that an
optional feature... or is this a Samba bug?)

Thanks.


"linearred" <nospam@nospam.nospam> wrote in message
news:eD9mrS35IHA.2544@TK2MSFTNGP04.phx.gbl...
> Hey folks,
>
> Is there a way to get the file system format type from a UNC path? We
> have an app that's using alternate data streams for storing thumbnails,
> and we'd like to be able to check in advance for non-NTFS file systems
> (which don't support ADS). "DriveInfo" has a "DriveFormat" property, but
> DriveInfo seems to be limited to letter-mapped drives.
>
> Thanks,
> Bill
>

On Wed, 16 Jul 2008 12:55:49 -0700, linearred <nospam@nospam.nospam> wrote:

> Well, on second look, getting the drive format may not matter. I mapped
> a
> drive letter to a Samba file share UNC address on a Solaris box.
> DriveInfo.DriveFormat on the mapped letter returned "NTFS", but it
> appears
> that the volume still does not support alternate data streams. (In
> theory,
> is an NTFS volume actually required to support ADS streams, or is that an
> optional feature... or is this a Samba bug?)

Frankly, I think you're asking in the wrong newsgroup. I understand that
you're using .NET, but the expertise here is probably not focused on these
kinds of issues. You'll probably have better luck asking a .NET-neutral
question that's specifically about accessing the ADS on an NTFS volume
over a network connection on a forum that is more specifically about file
systems and/or Windows networking.

You might even trying the Samba community over at http://www.samba.org/.
They've got a mailing list, with archives, and an IRC channel there. Of
course, Samba is open-source, so if all else fails, you could always look
at the source code to see if there's anything in there that should be
supported ADS.

My own guess is that you can't depend on a networked volume supporting
NTFS-specific features over that connection, and in fact it may be that
it's simply something that's completely unsupported on Windows networking,
never mind Samba. I'm not even sure that using native Windows-to-Windows
SMB networking, it would be supported (but then again, I'm not the expert
you're looking for, so... :) ).

Pete

Thanks for the tips, Pete.

FYI, alternate data streams do work on at least one other enterprise level
Windows network share I've tested in our network, so it doesn't seem to be a
Windows networking issue per se.

>
> My own guess is that you can't depend on a networked volume supporting
> NTFS-specific features over that connection, and in fact it may be that
> it's simply something that's completely unsupported on Windows networking,
> never mind Samba. I'm not even sure that using native Windows-to-Windows
> SMB networking, it would be supported (but then again, I'm not the expert
> you're looking for, so... :) ).
>
> Pete

On Wed, 16 Jul 2008 13:55:51 -0700, linearred <nospam@nospam.nospam> wrote:

> Thanks for the tips, Pete.
>
> FYI, alternate data streams do work on at least one other enterprise
> level
> Windows network share I've tested in our network, so it doesn't seem to
> be a
> Windows networking issue per se.

Not that I would have any particular insight in this respect, but...when
you write "enterprise level Windows network share", is that actually using
SMB? Or perhaps some other file sharing implementation that supports
ADS? If it's just using SMB (i.e. the built-in Windows networking) why do
you describe it as "enterprise level"?

Pete

Just to distinguish it from a desktop share. I don't kow what the company's
Windows file server farms are actually running on, or what the underlying
network connection actually is.

> Not that I would have any particular insight in this respect, but...when
> you write "enterprise level Windows network share", is that actually using
> SMB? Or perhaps some other file sharing implementation that supports
> ADS? If it's just using SMB (i.e. the built-in Windows networking) why do
> you describe it as "enterprise level"?
>
> Pete