Re: file names, symbolic links
From: Mark Roddy (markr_at_hollistech.com)
Date: 06/03/04
- Next message: Mark Roddy: "Re: MapTransfer..."
- Previous message: Alireza Dabagh [MS]: "Re: Changing the Charcterisitics for network adapter after installation"
- In reply to: Peter Wieland [MSFT]: "Re: file names, symbolic links"
- Next in thread: finecats: "Re: file names, symbolic links"
- Reply: finecats: "Re: file names, symbolic links"
- Messages sorted by: [ date ] [ thread ]
Date: Wed, 2 Jun 2004 20:46:23 -0400
Not only may volumes not have drive letters, volumes can span disks. I'd
suggest that the OP ought to log the raw data in the kernel and parse it in
luser mode in a log file post-processor and stop worrying about how to do it
in kernel mode.
-- ===================== Mark Roddy Windows 2003/XP/2000 Consulting Hollis Technology Solutions 603-321-1032 www.hollistech.com markr@hollistech.com "Peter Wieland [MSFT]" <peterwie@online.microsoft.com> wrote in message news:%23FpHIDOSEHA.3628@TK2MSFTNGP12.phx.gbl... > then i'm glad i asked. > > i've never tried using it myself, but IOCTL_MOUNTMGR_QUERY_POINTS seems like > it might be interesting - given one of: persistant symbolic-link name (ie. > drive letter or mount-point), volume unique ID or non-persistant device > name, it will give you back all the other mount points for the volume. > Perhaps you can query the volume you mount on for it's unique ID and then > call the mount manager to find a mount point for the volume to report. > > remember that volumes don't necessarily have drive letters ... if you go > through a mount-point then \device\harddiskvolume1\foo\fred.doc could easily > change to \device\hardiskvolume2\fred.doc and volume2 may not have any drive > letter. In that case you could still log the correct path for the file. > > -p > > -- > This posting is provided "AS IS" with no warranties, and confers no rights. > "finecats" <finecats@noemail.noemail> wrote in message > news:4383E8D6-3937-4C02-B1B3-19B0B8C53373@microsoft.com... > > > > It would just have been better maybe if you'd just tell me how to do > > this, rather than the old 3rd degree! BUT, > > When a user opens a file and my fs filter becomes aware of it, say he > > opens c:\fred\xyz.doc > > I'm given a name like \device\harddiskvolume1\fred.doc. Well I'd like to > > log this info, etc. And since \device\harddiskvolume1 is not understood by > > the user very well, I'd like to get my hands on "C:\" > > > > I'd be happy to find this info out when the device is 1st open, so I only > > have to do this once, but I'd settle for anything at this point. > > > > Thanks > > Finecats > > > > > > ----- Peter Wieland [MSFT] wrote: ----- > > > > why do you need the target of the symbolic link in the kernel? The > > symbolic > > links are generally there for a reason (like they provide a well-known > > name > > link to an object whose name can change each boot) so in most cases > > you're > > better off reporting or saving the symbolic link name rather than the > > actual > > object name. > > > > -p > > > > -- > > This posting is provided "AS IS" with no warranties, and confers no > > rights. > > "finecats" <finecats@noemail.noemail> wrote in message > > news:E8CF84FB-3AF3-4EA3-8687-81BFAA4FF81B@microsoft.com... > > > This API appears to be part of win32 and not part of kernel mode > > > programming? Could you please clarify that. I need an api to be > > called > > > from kernel mode. > > > Thanks > > > Finecats > > >> ----- Bart Bartel [MSFT] wrote: ----- > > >> The API QueryDosDevice(szDriveLetter, szNtDeviceName, MAX_PATH) > > takes > > > the > > > drive letter and returns the \Device\HarddiskVolumeX string in > > the > > > second > > > argument. The sample code for this is in the Base Win32 SDK in > > the > > > Samples\winbase\IO\DLEdit directory. > > >> This posting is provided "AS IS" with no warranties, and > > confers no > > > rights > > > > > > > >
- Next message: Mark Roddy: "Re: MapTransfer..."
- Previous message: Alireza Dabagh [MS]: "Re: Changing the Charcterisitics for network adapter after installation"
- In reply to: Peter Wieland [MSFT]: "Re: file names, symbolic links"
- Next in thread: finecats: "Re: file names, symbolic links"
- Reply: finecats: "Re: file names, symbolic links"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|