Does anyone know if Windows actually works right with hardlinks to files? I used DOpus to create a hardlink to a .avi file. (Copy MAKELINK=hardlink) When I double-click on the hardlink, Media Player opens, but complains that it doesn't know how to play to file. Double-clicking on the original the file plays just fine. When I use a standard shortcut, double-clicking plays the file also.
I also notice when I pull up properties for the hardlink, the summary screen says summary is unavailable. The same screen on the actual file shows info about the .avi.
If hardlinks are supposed to be nothing but directory entries to the same file, using the original or the hardlink should behave exactly the same.
I'm using DOpus 9.1.0.3.2975.x86 under Win XP patched to the latest and greatest. The partitions in question are all NTFS.
One thing that may be causing an issue is that both of the directories in question are actually part of junctions to different partitions. The source file is on F:, the destination directory is on G:, but both are being accessed via their junctions to E:. I hope that makes sense.
I think that's exactly what's causing the issue. You can't hardlink between different devices, even through a junction. Think about what a hardlink actually is - effectively a duplicate directory record pointing to a specific block on the current disk. Block X on one disk isn't the same as block X on another disk, which is what you're trying to do.
If you're using Vista then a softlink will do what you want, as this is resolved at the file system level rather than at the block level. If you're on XP or 2000 then the only way would be a shell link (shortcut.)
I can buy that for the hardlink, but not for the junction. One of the major points of junctions is to be able to mask from the end user the actual physical layout of disks and partitions. Every article I've read mentions the case of adding more disk space and wanting to seamlessly merge it into the existing directory structure, which is exactly what I'm trying to do.
I'm wondering now if my problems are stemming from the use of junctions or if it's a file protection issue. No matter what I do, everything is showing up as "read only". Even though I'm the owner of all the folders/files in question, I went so far as to explicitly give myself full control of the entire drive. DOpus is still showing everything as "read only".
Junctions won't magically make it possible to hardlink between drives.
Junctions are implemented as "reparse points". The file system parses the supplied path one level at a time. When it hits a "reparse point" it starts again from the new location and continues parsing the remainder of the path up to the end. The problem is that the hardlink at the end of your path refers to a block on another physical volume.
For example, say you have a folder C:\Foo, and in there is a junction Bar which points to D:\Baz.
Take the path C:\Foo\Bar\file.txt. The file system parses this path as follows:
Internally, the file system is dealing with D:\Baz\file.txt. Now if file.txt happens to be a hardlink to a block on C:, a physically different drive, this will obviously fail.
Remember that there really is no such thing as a "hardlink" as such - a hardlink and a normal file are the same thing. If you have a normal file, you have one directory entry pointing to a chunk of data. If you have a normal file + a hardlink to that file, you just have two directory entries pointing to the same chunk of data. There is no way to tell the two apart - no concept of which is the "original" and which is the "link". As I said, this is implemented at the block level - a lower level than the path-based implementation of junctions and soft links.
In the above example, the file system doesn't "know" that file.txt is a hard link. It just sees it as a file entry, pointing to a block of data that DOESN'T EXIST. There is no "back-link" through the junction to the other disk.
To answer your original question, yes, hardlinks work fine - when you use them properly. I think the only real problem is that you were able to create a hardlink to a file on a different disk - this should not be allowed, for the simple reason that it doesn't work.
Thanks for the excellent discussion Patch and Jon !
@Jon
Junctions are not properly refreshing in DOpus 9.1.0.3 .
I noticed it several days ago and had been reading Nudel's FAQ on this.
After reading your discussion on this thread I looked into it more.
It turns out all works well with 9.1.0.1 and 9.0.0.2, but not in 9.1.0.3 .
This applies to any junction I create.
I have been using junctions on Vista32 to map flash card reader drive letters.
After the junction is created, I remove the reference to the original drive letter.
For now at least, I simply use a shortcut in the startup folder to a batch file .
The batch file just does an ancient Subst command to the folder that contains the junctions.
Yes, it's NOT a good solution.
DOpus flash export will fail on this for instance, but it does eliminate all those Bad drive letters .
I have three partitions E:, F:, and G: that all reside on different physical volumes. E:\A\B\ is a junction that points to F:\B. E:\A\C\ is a junction that points to G:\C. There exists a file E:\A\B\file.txt. Is it legal to create a hardlink E:\A\C\another-file.txt that points to E:\A\B\file.txt?
As I said, you probably shouldn't be allowed to create that. Opus just calls the underlying system API to create hardlinks, which obviously isn't checking the validity of the link. I'm quite surprised it allows it actually, I would say this is a bug in Windows.
I've discovered a couple things, one of which partly explains my confusion and one that appears to be a bug.
The confusion part is that the situation is in reality a bit more complicated than in my examples. I actually have several directories in each of F: and G: that are mapped via junctions to different places on E:. It happens that some of the hardlinks I was trying to create were from and to the same underlying volume, but some crossed volumes. IOW, some worked and some didn't.
As for the possible bug, if I click the button I've assigned "Copy MAKELINK=auto" with the intent of creating a hardlink that would cross volumes, DOpus creates what, from the size, appears to be a shortcut, but the icon looks like a hardlink. I'm guessing it's some kind of hybrid object that Media Player doesn't know what to do with. Media Player works fine with proper hardlinks and with proper shortcuts, but doesn't know what to do with this object.
If I click the button I assigned to "Copy MAKELINK", DOpus creates a shortcut in the destination to the selected file in the source. This shortcut file is exactly the same size as the one created by "Copy MAKELINK=auto", though this one displays with the shortcut icon.
If I click the button I assigned to "Copy MAKELINK=hardlink" in the same scenario, DOpus gives me an error message and refuses to create the hardlink.
Incidently, I installed a hardlink shell extension that's supposed to make Explorer behave itself with hardlinks. When I tried to use it to create the same hardlink it just silently did nothing.
Thanks for the additional info, I understand what is going on now.
Hardlinks were never involved. I have confirmed that Windows won't let you create a hardlink across devices, even if it's through a junction. On both XP and Vista this gives an error 17 (can't move file across devices.)
There is a bug in the current version of the MAKELINK=auto command - if this command ends up creating a shortcut as opposed to a hard/softlink or junction, it does not properly build the name of the shortcut. So instead of "Shortcut to XXX.lnk", you end up with a shortcut called "XXX". Because this doesn't have the .lnk suffix it is not recognised as a valid shortcut, which is the root cause of your problems.
We will fix this in the next version, in the meantime you can either use MAKELINK=shortcut to specifically make a shortcut, or just rename the shortcuts created by MAKELINK=auto to give them the needed .lnk suffix.
No, it occurs if a junction points to a drive.
I knew there was a problem and had isolated it to 9.1.0.3.
At the time I thought it may have been part of what Patch was seeing.
Sorry about confusing the thread.
My junctions were made using Vista Disk Management in the Control Panel.
I have a folder on my C: drive that contains junctions to the drives of my internal card reader/writer .
It does not matter at all if the drive has a letter assigned to it.
The result is the same in either case, changes to folders within the junction are not being detected without an additional manual refresh.
It also does not matter that the drive is a card reader.
A junction pointing to another hard drive partition even on the same physical hard drive results in the same.
My use of a Dos Subst command does not seem to have anything to do with it.
I have a shortcut in my startup folder pointing to a batch file that executes Subst O: C:\Flash .
In this case C:\Flash is a folder that contains junctions to the card reader drives and this folder will also be available as the drive letter O:\ .
Removing the shortcut from the startup folder and restarting the computer does NOT fix the problem even if the junction points to a drive with a letter.
My part of this thread, off topic ( sorry ),
is still broken in 9.1.0.4.
No matter, the new version is a great update !
Thanks!
I'll start a new thread on this after some more work.
As of tonight I'm thinking on some workaround ideas.
Hence the motivation for a new thread.
Does your problem case work okay in Explorer? Maybe junctions to (some) memory card readers don't work well in general?
AFAIK this issue hasn't been reported to GPSoftware, BTW. I've had it on my list of things to look at/confirm but haven't got around to trying it myself so I haven't reported it myself.
I think I'm confusing the real problem here.
Not only was I off topic in this thread,
but my ideas aren't thought out well enough.
The problem is NOT specific to card readers or drives without Letters.
The problem is,
changes to folders within junctions to drives in general ( any drive ),
are not being detected without an additional manual refresh.
This worked in 9.1.0.2 and has been broken since 9.1.0.3.
Reinstalling 9.1.0.2 over 9.1.0.3 or 9.1.0.4 fixes the problem.
It would be better to start a new thread on this.
We could also extend the discussion to Softlinks.
Is there any possibility of moving some my posts in this thread into a new thread ?
My posts here are beginning to obscure the intent of Patch's posts.
I have since found that the problem has something to do with Junctions and SoftLinks that point to Volumes,
rather than pointing to a Drive Letter path.
If I create the Junction in Disk Management it mounts the volume to a folder,
and the junction points to the Mounted Volume.
Auto refresh does not work.
If I create the junction at the command line using the MS mklink commamd,
pointing the junction to a drive letter,
auto refresh works properly.