Junction refresh not working on non-vista machine

Help & Support
#1

background:
New user of Dopus, installed version 9.1.0.1.2947.x86 for evaluation, deciding whether to purchase the product. Read the FAQs, Read the intro by Leo, intend to be a purchaser and "power user" (and perhaps plugin developer) of Dopus if I can get a few more insights on unanswered questions.

overview:
Windows XP supports the use of "junctions" (see e.g., en.wikipedia.org/wiki/NTFS_junction_point) as long as you have a program that allows you to manage them, as they are not readily available to the end user by default. Apparently Dopus 9 supports junctions natively, but searching the forums shows that people have had problems with these.

problem:
even though Dopus 9 supports junctions as far as I can see, they do not refresh automatically. Every action taken on a junction on my system requires a quick F5 to refresh the lister pane.

steps to reproduce:
-- install Dopus 9 on a Win XP machine
-- install any of the junction supporting addons (see the wikipedia article for links)
-- create a junction point to an empty directory
-- create a new file, create a new folder, rename an existing file, delete an existing file in the junction point
-- you will notice that you have to press F5 to get the changes to refresh

request:
can someone confirm that this is indeed a problem and if so send in a bug report? if it is not a problem, please suggest workarounds or fixes.

Thanks, if i can get insight on this and a few other issues, I will soon be a happy new customer of this company.

#2

What you're trying to do should work, so it's certainly worthy of a bug report. Before you send one in, though, see if any useful information is revealed by the debug mode discussed in this FAQ. If you find anything feel free to discuss it here before sending in a report. We can test whether the same thing happens on other computers, Vista, etc.

By the way, if you're using Opus then you don't need additional tools to manage junctions as they're built-in. For more details, go to the Opus Raw Commands section near the back of the manual and look up the Copy command's MAKELINK argument.

#3

first investigation with debugview
So I installed and ran the debugview as suggested in the faq per Leo's suggestion. As far as I can tell Dopus is simply not seeing the changes.

steps to reproduce
-- Install and run debugview as indicated previously
-- turn on advanced debug reporting within dopus as shown in the FAQ
-- open Dopus and navigate to c:
-- create a text file c:\this-is-new.txt
-- RESULT: Dopus correctly reports both the creation of c:\new text document.txt and the change rename to c:\this-is-new.txt
-- NEXT: create a junction c:\junction and point it at some empty directory elsewhere on your machine, then reproduce the previous steps
-- RESULT: Dopus does not seem to report the events, they do not show up in debugview.

Based on this, it is at least true that debugview shows actions on a junction are not being reported the same way as actions done in a plain old regular directory.

Unless someone chimes in with thoughts I spose I will submit a bug report with a link to this thread.

#4

What type of drives and filesystems is the junction from and to?

If you run Process Monitor how does it report the changes?

#5

I havent run any other tests using the sysinternals tools, but I just narrowed it down.

The link target is NTFS external USB mounted hard drive. The link pointer is NTFS in C Drive root.

When I create a link pointer that points to a target, and both target and pointer are on the same drive (CDrive) Dopus behaves as expected.

When I create a link pointer that points to a target, and the pointer is on CDrive, but the target is a USB-mounted external drive, Dopus exhibits the "refresh failure" behavior.

So before I dig further, is there anything in your experience that raises an AHA! for why this would happen?

Thanks much for your responses.

#6

Just out of interest, does this work as expected in Explorer?

#7

Yes as far as I have seen, windows explorer presents no noticable differences when using junction targets that are on a USB drive. The first time I ever noticed a difference was with DOpus.

#8

Apparently, this refresh problem goes away as long as you have a tab open in dopus that points to the drive letter that is assigned to the USB mounted drive.

In other words, if you have a "fake" junction directory F:/foobar that points to a "real" directory on a usb mounted R:/ ... refreshes to F:/foobar will not auto-populate unless you have a tab open in DOpus that points to R:/

Apparently, DOpus needs to "see" the real drive in a tab somewhere before it is willing to make auto-refreshes to a junction that points to that "real" drive.

#9

Thanks for the additional info, we've been able to work out what's going wrong now, and this will be fixed in the next version!

#10

Excellent, hats off to you on the find and the great response!

Many thanks,

#11

The next version was released 10 days after this was posted and does not appear to include the fix. This is not a complaint - just an observation. I assume it was just too close to the 9.1.0.3.2975 release date and is on the list for the next version?

Regards, AB

#12

Yes it did:

#13

Hmmm

I still see the symptom that a file delete from a junction structure needs a refresh (F5) whereas a file delete from a conventional drive location is immediately removed from the display. This is on XP/SP2 and the latest release of DOpus.

Regards, AB

#14

You'll need to provide more information than just "it doesn't work." :slight_smile:

Have you tried the FAQ linked above? What information does the debug mode show? Which type of junction is it? Which types of folders and filesystems is it from and to? Anything unusual about them such as not having drive letters? etc.

#15

Fair enough. Two separate junctions. One is a logical disk partition which used to be mapped to drive letter E: before I made it a junction mapped to a directory on C:. Both C: and E: were on the same physical HDD. The other junction is a 2nd internal IDE HDD, previously mapped as D:, now mapped to a directory on C:. All are NTFS. I'll try the debug stuff later and report back.

Regards, AB

#16

Using Process Monitor and filtering on the junction directory where test files are ready to be deleted, I see a lot of CreateFile operations with a result of REPARSE. Nothing different is recorded in PM when I delete a file, and the file is still displayed in DOpus. When I press F5 to refresh, the file disappears from the DOpus lister window and PM records a QueryOpen operation with a result of FAST IO DISALLOWED.

If I delete a file from the same directory in Explorer, it disappears immediately from the Explorer window and generates a sequence of five CreateFile/REPARSE records. I'll send the log in a bug report.

Regards, AB

#17

Don't forget the notify_debug stuff within Opus (explained in the FAQ). That's what tells you what Opus is/isn't seeing. The problem could be that Opus isn't seeing a change at all, or it could be seeing the change but not realising it applies to the directory.

#18

I'll send a debug log too then...

Regards, AB

#19

This is still not working properly in 9.1.0.4. I just read Zippo's posts in this thread and I think we are on to the same issue. I have updated an earlier problem report with GP Software.

Regards, AB

#20

Thanks for repoting it Aussieboykie .
I'm on a Vista machine here.

From the context menu - > Properties entry of the junction,
is there any info as to what Junction Type it is ?
On my Vista machine, I've found that the Junction Type in question is a Mounted Volume.
These junctions were created under the Control Panel Disk Management GUI.