12 replies to this topic

[draisp]

Hi,

I searched the subforum and I didn't find a clear answer or at least confirming my problem, so I have to ask clearly:

are the junctions to RAMDisks resources impossible or are Windows OS version dependent?

I use the Sysinternals Junction utility to manage junctions (I tried yours too, just to try, Olof, with the same result) and I'm unable to create a junction point to a RAMDisk (root) or a folder in a RAMDisk.

For advanced users, is this a normal behavior for symbolic links to be unable to create junctions pointing to RAMDisks resources?

I get an error (in my language, sorry if I don't post) like the data in the buffers aren't valid to reanalysis.

I'm under Windows 2000 and I don't know if it is a lack of this Windows version for this kind of junctions support (no problem with normal junctions), that's why I ask it too.

Thanks for the replies
Regards.

[Wonko the Sane]

Sorry, but I am missing how these junctions you are trying to make are "different" from "normal" junction point?

 

Can you try detailing what you are attempting to do? (provide an example, including drive letters, folder name(s), exact command issued, exact feedback or errors received, etc.).

 

Wonko

[draisp]

By normal and not normal I only mean that junctions to physical drive paths don't give problems. Just that, don't make fantasy guesses ;P

And I think I explained it quite clear. But lets see two examples.

junction desired_name_junction X:\physical_drive_path <<-- works without problems

junction desired_name_junction X:\RAMDisk_drive_path <<-- doesn't work

I think it is quite clear. Replace X:\ for your RAMDisk drive letter and replace the drive path for whatever you want, from "\" (root) to "\whatever" (existing folder inside RAMDisk).

About the error, as you are italian, maybe you can understand the error, but won't help others (Z, of course, is the drive letter for the RAMDisk, just if you are in doubt):
 

/>junction xxx z:\

Junction v1.06 - Windows junction creator and reparse point viewer
Copyright © 2000-2010 Mark Russinovich
Sysinternals - www.sysinternals.com

Error setting junction for xxx:
Los datos presentes en el búfer de puntos de reanálisis no son válidos.

I haven't found the translation to english so, guess it if you can, as I did in my first post.


But, please, where are going away of the question. Is possible (are you able) to make junctions to RAMDisks, or not, and if not is a normal behavior? Or, if possible, is OS dependent and it is not possible under Windows 2000? (I haven't found information about it)

Regards.

Edited by draisp, 22 June 2013 - 04:04 PM.

[Wonko the Sane]

Well, first thing it was not clear and it is still not made very clear.

 

I was asking you to post (as opposed to generical "examples") the EXACT, SAME, commands (including drive letters, names and everything) that you actually tried (and that caused the error) and a brief description of your environment.

 

Here is an example of the kind of info that I would have liked to have:

Environment:

C:\ <- boot/system drive, OS windows 2000 Sp4 - formatted with NTFS system

X:\ <- Ramdisk created IMDISK with this command line: imdisk -a -s 512M -m X: -p "/fs:ntfs /q /y"  (or describe the settings you checked in control panel) - formatted with NTFS system

 

Command run (syntax is junction [newjunction] [Target]):

md X:\mynewjunction

junction X:\mynewjunction C:\myexistingfolder X:\myexistingfolder C:\mynewjunction

or:

md C:\mynewjunction

junction  C:\mynewjunction X:\myexistingfolder

 

I am GUESSING that you are using IMDISK because you posted in the Imdisk forum, but you never specified that.

 

Most probably you are facing this problem not because of Windows 2000, but rather because a ramdisk volume created with IMDISK does not interact with MountManager (i.e. you cannot see it if you run MOUNTVOL.EXE and you cannot see it in Disk Manager).

See also:

http://support.micro...kb/205524/en-us

 

The actual English error should be:

 

 

 

Error setting junction for <mynewjunction>:
The data present in the reparse point buffer is invalid.

 

You might want to try a Ramdisk that interfaces at a "lower level" in Windows.

 

Firadisk is the first one that comes to my mind, WinVblock and Gavotte's might also do, though cannot remember  if they all work in Windows 2000 .

A list is here:

http://reboot.pro/fo...s-firadisk-etc/

http://reboot.pro/to...ledisk-drivers/

 

There is also the Virtualdisk driver by Primoz Beltram, if I recall correctly it was fully functional on 2K (and started having issues with XP SP2 ).

 

Wonko

[draisp]

Well, first thing it was not clear and it is still not made very clear.
 
I was asking you to post (as opposed to generical "examples") the EXACT, SAME, commands (including drive letters, names and everything) that you actually tried (and that caused the error) and a brief description of your environment.

the kind of info that I would have liked to have:
Environment:
C:\ <- boot/system drive, OS windows 2000 Sp4 - formatted with NTFS system
X:\ <- Ramdisk created IMDISK with this command line: imdisk -a -s 512M -m X: -p "/fs:ntfs /q /y"  (or describe the settings you checked in control panel) - formatted with NTFS system

Sorry, but I'm not going to post my environment. It is not necessary for the purpose of the explanation and for the request for information: if it is possible to create junctions pointing to RAMDisks.

Trust me that I have lots of junctions and I know how to use the command, how to create, delete and show junctions; and the ones pointing to RAMDdisks are the only ones that can't be done.

An example as above is enough. Indeed beyond the prompt symbols and the no named real paths, it is exactly the same command as the RAMDisk is in Z: (error quoted).

The example is still valid:

junction nameofjunction pathtoramdisk.

Maybe you need to know that it has a drive letter. Yes, of course, it has. The command to create the RAMDisk.

imdisk -a -t vm -m Z: -s 100M -p "/fs:ntfs /a:8192 /q"

 

Command run (syntax is junction [newjunction] [Target]):
md X:\mynewjunction
junction X:\mynewjunction C:\myexistingfolder X:\myexistingfolder C:\mynewjunction
[b]or:[/b]
md C:\mynewjunction
junction  C:\mynewjunction X:\myexistingfolder

You are not being serious with that example, right? Because that is not possible...

A junction with a name of an existing path? When was that possible?
 

I am GUESSING that you are using IMDISK because you posted in the Imdisk forum, but you never specified that.

If not, why asking here? Come on...

You may be finding my posts quite... pedantic, but, errr... you are making some questions quite out of topic... from my point of view, of course.

Most probably you are facing this problem not because of Windows 2000, but rather because a ramdisk volume created with IMDISK does not interact with MountManager (i.e. you cannot see it if you run MOUNTVOL.EXE and you cannot see it in Disk Manager).
See also:
http://support.micro...kb/205524/en-us

 

YES!!! a real answer. I'll read that and test what can I do with those Resource Kit utilities.

 

Yes, the RAMDisks aren't shown in Disk Management console. But I find normal, thinking they aren't real volumes.

 

I'll check that.

 

Do you see the volumes in the Disk Management console?

 

 

 
You might want to try a Ramdisk that interfaces at a "lower level" in Windows.
 
Firadisk is the first one that comes to my mind, WinVblock and Gavotte's might also do, though cannot remember  if they all work in Windows 2000 .
A list is here:
http://reboot.pro/fo...s-firadisk-etc/
http://reboot.pro/to...ledisk-drivers/
 
There is also the Virtualdisk driver by Primoz Beltram, if I recall correctly it was fully functional on 2K (and started having issues with XP SP2 ).
 

Wonko

Oh, another real answer. Thank you!

I'll check the Resource Kit tools and try those advices.

Again, sorry (to everyone) if the messages looked pedantic, but, from my point of view, the answers where going out of the question, except for the last part of your last reply.

Indeed, with a yes or no replay, or pointing me for the right documents would be enough.

 

I just want to know if there is some problem with imdisk RAMdisks or it is a Win2k behavior or whatever.

Thanks for your last help.

Regards.

Edited by draisp, 22 June 2013 - 09:09 PM.

[draisp]

Command run (syntax is junction [newjunction] [Target]):
md X:\mynewjunctionjunction X:\mynewjunction C:\myexistingfolder X:\myexistingfolder C:\mynewjunction
[b]or:[/b]
md C:\mynewjunctionjunction  C:\mynewjunction X:\myexistingfolder

I hadn't time all the night until now, and I read the Microsoft page so I understand now the above, but I use the Junction utility by Sysinternals which simplifies this a lot.

But, anyway, the problem is... how do I mount the way Microsoft explains, if I don't know/don't have a volume ID for the RAMDisks?

I used mountvol.exe and the RAMDisks aren't listed.

(As a said note, the virutal CD created by tools like Daemon Tools report the ID without problems, maybe a lack of imdisk driver?)

When I use "mountvol Z: /l" to see its ID, mountvol just reports the error: "Incorrect Function". So I guess can't access to its ID, if it has, or there is a missing function in Win2k.

I think that the problem is the same as why the they aren't in the Disk Management Console.

Any ideas if this is a lack of Windows 2000 or a lack of imdisk?

Just to discard and forget to try to make junctions targeting the RAMDisks resources.

Thanks, regards.

Edited by draisp, 22 June 2013 - 11:53 PM.

[Wonko the Sane]

You see, if you provide the data that I ask for, maybe I can understand the issue, rest assured that I ask for things that I would like to know in order to try and help you, and not because I want to somehow bother/harass you.

Maybe if I understand what you are doing (or attempting to do) I can give you a proper answer.

 

You were not being pedantic, you were being uncommonly stubborn in NOT providing the EXACT command lines that you used.

This way it is impossible to attempt to replicate on another system and find out for sure if the issue is the OS, the Imdisk driver, the actual commands that you use or your particular OS install.

 

This is the "standard" approach, JFYI:

http://homepage.ntlw...ard-litany.html

 

 

On your original post it was not at all clear (rest assured it wasn't - at least for me) if you were attempting to create a junction ON a Imdisk Ramdisk or TO a Imdisk Ramdisk.

 

But you got anyway your answer, through a couple (educated) guesses: the issue is caused by Imdisk which connects to the Windows NT subsystem at a "higher level" than the one needed to use mountpoints/junctions (the Mount manager).

 

This is not necessarily a "lack" of IMDISK, it is simply the way that it has been programmed/designed.

 

 

Wonko

[draisp]

For me, as imdisk is my first RAMDisk program used regularly (but chosen by its simplicity and low system footprint), and reading others can do junctions to RAMDisks (I never needed or pretended to use junctions before, until now), could be considered as a lack of imdisk, if other programs can do.

But is what I searched for the beginning, to know if it was an OS version problem (unable to do with any RAMDisk utility) or an imdisk lack. Obviously I focused on imdisk because I'm not anymore one person that tests loads of utilities. Nowadays I prefer to keep clean the system.

I understand that the topic subject could seem generic, but if I'm in the imdisk subforum, I assumed everyone could understand I'm talking about imdisk. My fault.

I confirmed that the lack is part of imdisk this morning because a friend with XP hadn't a problem to test it on his computer (usually people in my environment don't do that), and had the same problem.

I know lack can sound quite strict, but I expected, reading very briefly over other people could make junctions to RAMdisks, it was possible with every RAMDisks utilities out there.
 
But maybe I had to imagine it before because a low level driver needs (usually, if I'm not wrong) a reboot, and imdisk doesn't. I just didn't think about it.
 

Aside this problem, or doubt, that is solved, what you said about my first post, that you didn't know what I was trying to do, I just quote myself remarking it:
 

are the junctions to RAMDisks resources impossible or are Windows OS version dependent?

Wasn't really clear I was trying to make junctions to RAMDisks?

English is not my first language, but "to", means "to", not "from" (what I already tested, BTW, but I find useless to junction from RAMDisk to a physical drive).

That is the reason I looked stubborn. I think I was clear enough with that clause. No one before recommended me that kind of links (I read recommending to others) and I'm using software newsgroups/forums since about a decade. I learned since the beginning to RTFM before ask.

I expected you would understand me, my fault, but you assumed I was making something wrong before anything.

I don't think these technical questions are made by newbies, too.

Anyway, I'm more humble than what you've seen here, so, if it was my fault, hey, I accept without problems. Apologizes to everyone! Sorry to make you bear with this thread.

Thanks for your help,
regards.
 
 
Note: in all my posts I wrote intentionally imdisk without capitalization to avoid confusion on reading to new people.

[Olof Lagerkvist]

I have sort of missed this discussion until now, but I just wanted to share a few thoughts (and facts).

 

• Junctions should be perfectly possible to ImDisk virtual disks. Either by using junction.exe from SysInternals or my own junc.exe, it should be possible to join an existing, empty, NTFS directory to some place on an ImDisk virtual disk.
• It will not work with mountvol.exe however. This is because ImDisk drives do not have a volume Id, because they do not interact with Volume Mount Manager.
• There is a more simple way to do the things you can do with junction.exe, junc.exe or similar. You could specify an existing, empty, NTFS directory to the -m switch on ImDisk command line. This way, imdisk.exe do all this for you. You will not get a drive letter this way, which means that you cannot format a filesystem on the virtual disk drive. But that could on the other hand be solved with an existing image file with a filesystem already on it. This could be a small filesystem image, that could later be enlarged with imdisk -e -s command line.
• All mentioned above work, in my experience, perfectly on Windows XP, Server 2003, Server 2003 R2, Vista, Server 2008, 7, Server 2008 R2, 8 and Server 2012. On Windows 2000 however, there are occasionally problems with getting Windows to accept junction reparse metadata. This is what I think could be the root problem in this particular discussion. There are similar issues with creating hard links in some scenarios. Generally, this is something that people experience with backup software (in restore operation). So, in most cases information about this issue is to be found in discussion groups and support forums about backup software of various kinds.

 

@draisp: Hope you find a solution!

 

[Wonko the Sane]

I don't think these technical questions are made by newbies, too.

Ah well, you have no idea of which questions can come out from newbies.

 

Anyway, I'm more humble than what you've seen here, so, if it was my fault, hey, I accept without problems. Apologizes to everyone! Sorry to make you bear with this thread.

No need to apologize , we managed anyway to understand each other. (maybe , see below)

 

 

Thanks for your help,
regards.
 

You are welcome .

 

It seems to me like anyway I understood something completely different from what Olof did.

 

This is what I got from the OP:

It is possible to create ON a Imdisk volume a NTFS junction TO a folder residing on  a "real" disk.

It is not possible (seemingly) to create ON a "real disk" a NTFS junction TO a folder residing on a Imdisk volume.

 

This is why providing EXACT examples is important.

On my machine:

C: = "real" disk partition (NTFS formatted)

T: = "imdisk" volume (in RAM)

C:\myrealdir = "real" directory

T:\anotherrealdir = "real" directory

 

I can run (Windows XP SP2):

junction T:\myniceRAMjunction C:\myrealdir

I can also run:

junction C:\myniceREALjunction T:\anotherrealdir

alright, but I seem to remember having similar issues with the latter under Windows 2000 .

 

If the junction point is a "replacement" for a drive letter, i.e. a "mountpoint",  then the "mountvol" issue applies AFAIK on "any" Windows NT based system.

 

Wonko

[draisp]

/> I have sort of missed this discussion until now, but I just wanted to share a few thoughts (and facts).

• Junctions should be perfectly possible to ImDisk virtual disks. Either by using junction.exe from SysInternals or my own junc.exe, it should be possible to join an existing, empty, NTFS directory to some place on an ImDisk virtual disk.
  
• It will not work with mountvol.exe however. This is because ImDisk drives do not have a volume Id, because they do not interact with Volume Mount Manager.
  
• There is a more simple way to do the things you can do with junction.exe, junc.exe or similar. You could specify an existing, empty, NTFS directory to the -m switch on ImDisk command line. This way, imdisk.exe do all this for you. You will not get a drive letter this way, which means that you cannot format a filesystem on the virtual disk drive. But that could on the other hand be solved with an existing image file with a filesystem already on it. This could be a small filesystem image, that could later be enlarged with imdisk -e -s command line.
  
• All mentioned above work, in my experience, perfectly on Windows XP[...]

 
@draisp: Hope you find a solution!

Ok, thanks for your help, Olof.

The part were you say that the above works... even on XP happened the same. Indeed, your junc.exe utility reports as: "Invalid target path: 'z:\'" or "Invalid target path: '\??\z:\'" or any other combinations following the examples of the command line help. The only one that works is when you target to \??\z: (without the last bar), that creates the junction name but does nothing as it doesn't point to Z:.

(Z:\ is a mounted imdisk virtual drive created with example above).

I tested your explanation with the -m parameter but without success. And I think I give up :S

http://reboot.pro/to...-a-mount-point/
Following these examples, does nothing. I'll try again, but I can't make it to work. For today, I give up. I have to sleep.


Should work, but doesn't work. It's the only thing I can tell That's the reason I wanted to know if was impossible or is OS dependent.

And I think I have that answer, so, I don't know if I'll bother too much. Before the next weekend I won't have much time.

Thanks Olof.

Edited by draisp, 23 June 2013 - 09:38 PM.

[joakim]

There are similar issues with creating hard links in some scenarios. Generally, this is something that people experience with backup software (in restore operation). So, in most cases information about this issue is to be found in discussion groups and support forums about backup software of various kinds.

 

Apparently that has to do with the presence of $EA attribute on NTFS, however it is not at all common to find. I have never verified the exact behaviour/issue though.

[Olof Lagerkvist]

Apparently that has to do with the presence of $EA attribute on NTFS, however it is not at all common to find. I have never verified the exact behaviour/issue though.

 

I have only seen it on Windows 2000 (and Windows NT 4.0 with the hard link problem). Which leads me to think that the problem that this thread discuss could have some different cause. Anyway, the problem I mentioned seemed to disappear completely on Windows XP and Server 2003. I had a few reports about similar problems when users restored data with my "strarc" tool, but these reports have also only been with pre-Windows XP versions of Windows.

 

The strange thing was that the problem was some kind of intermittent. It could suddenly show up in a particular subdirectory but not in another subdirectory on the same volume. It could show up and disappear following some Windows Update or other hotfixes or Service Packs. I solved some of this, but not all, by changing the code that restores hard link metadata to direct calls to native FsSetInformationFile (instead of Backup API or CreateHardLink).

 

But I should also mention that it was more than 7 years ago since I last time tried to investigate problems similar to this. So I may miss out some things I have forgot since that time.