Re: file names, symbolic links
From: finecats (finecats_at_noemail.noemail)
Date: 06/03/04
- Next message: Hary: "Re: INPUT FILES"
- Previous message: Scott Barr: "COM Port problems with Windows XP Professional"
- In reply to: Mark Roddy: "Re: file names, symbolic links"
- Next in thread: Bart Bartel [MSFT]: "Re: file names, symbolic links"
- Reply: Bart Bartel [MSFT]: "Re: file names, symbolic links"
- Messages sorted by: [ date ] [ thread ]
Date: Thu, 3 Jun 2004 11:06:04 -0700
Mark
I'm afraid your answer went over my head. How would a user mode parser be any smarter about determining the symbolic links than in kernel mode? As for volumes not having letter names, don't they have drive names that the user is more used to? And in most cases those names are stable? Those names are what I'm after - i.e. something the user understands.
I hope I'm not creating a can of worms for myself, If the user opened a file on a drive User_X (where User_X is a symbolic link to a bunch of storage called "The_Real_X" ) then I'd like to get a hold of the name User_X somehow.
Thanks
Finecats
----- Mark Roddy wrote: -----
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: Hary: "Re: INPUT FILES"
- Previous message: Scott Barr: "COM Port problems with Windows XP Professional"
- In reply to: Mark Roddy: "Re: file names, symbolic links"
- Next in thread: Bart Bartel [MSFT]: "Re: file names, symbolic links"
- Reply: Bart Bartel [MSFT]: "Re: file names, symbolic links"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|