KISS

S

Sietse Fliege

Susan said:
On the "kids" XP OS I believe it *will* browse to a folder. I've heard
no report of differences in behavior since they switched from WIN98 to
WIN XP (on a new computer). . .

They might have FAT32. . . I'm fairly sure they're *not* using the
My Pictures folder for most images. . . I don't think the drive is
partioned. . . will check when I have a chance and report back (if
others don't report in on their XP systems first).


Oh, yes, I forgot to mention that I do have a Fat32 partition.
There it does show subfolders.
I have no pictures on that partition (It's for restoring the machine.)

A small FAT32 experiment:
I created three folders and put a jpg in each:
Test_A read-only
Test_B, no attributes set, with a subfolder Test_B_Sub, read-only

It didn't see the two read-only folders (I could not select them).
But when I selected Test_B it showed me not only the picture in it,
but also the picture in its read-only subfolder.

Could be that this is the same on your machine also:
that you cannot see or select a read-only folder,
but that you can see pictures in a read-only folder provided you select
a parent folder that has no attributes set.

It looks like the only problem is with NTFS, not WinXP,
and that the "only" problem with NTFS is that you cannot select a root
folder, so you have to let it scan the whole drive.
Thanks much for helping to sort this out Sietse. :)

No prob. Glad if I can be of help.
 
S

Susan Bugher

Sietse said:
Susan Bugher wrote:

Program: Iomega Photo Printer
Oh, yes, I forgot to mention that I do have a Fat32 partition.
There it does show subfolders.
I have no pictures on that partition (It's for restoring the machine.)

A small FAT32 experiment:
I created three folders and put a jpg in each:
Test_A read-only
Test_B, no attributes set, with a subfolder Test_B_Sub, read-only

It didn't see the two read-only folders (I could not select them).
But when I selected Test_B it showed me not only the picture in it,
but also the picture in its read-only subfolder.

Could be that this is the same on your machine also:
that you cannot see or select a read-only folder,
but that you can see pictures in a read-only folder provided you select
a parent folder that has no attributes set.

The answer to your question is yes. I do see the photos in a WIN98
read-only subfolder when I chose its parent folder that has no
attributes set.

I *always* see the photos in the subfolders too. I didn't know that!
This feature is sometimes requested in ACF. Very few apps have that
capability. FotoAlbum is one, now we have another.

I did a few tests a while ago to see which thumbnail browser could open
the *most* images before it choked. The Iomega app beat IrfanView,
XnView and SlowView by a large margin. (FotoAlbum could open more but it
*caches* thumbnails.)

*anyway*. . . the point is that browsing a folder with several thousand
images is not the best way to discover that images from subfolders are
also displayed. . . I've learned many new things about this app. ;)
It looks like the only problem is with NTFS, not WinXP,
and that the "only" problem with NTFS is that you cannot select a root
folder, so you have to let it scan the whole drive.

It's *very* nice to have the answers. :) :) :)

Susan
 
O

omega

MLC said:
_omega_, giovedì 16/dic/2004:


AFAIR they weren't seen.
I can't check again because I uninstalled the app, but I'm pretty sure.
On the first run I clicked the Browser button and I was frightened to not
see the directory tree to my Images folder.

That is an alarming feeling.
Then I looked for Programmi and I couldn't find it.

Thanks for looking into it. Calling in the special operatives (ie Sietse
Fliege) and learn now that the program was blind not only to +S folders,
but also to +H and +R (system, hidden, read-only attribs). On both file
systems. That's behavior I've never seen, and had not expected. And then
there is the additional matter: re the note from Sietse that on NTFS,
it will initially look like all your root folders have been wiped off
the earth.
 
O

omega

Susan Bugher said:
Nope - I just checked and I *can't* do that. In WIN98 the app can't see:

system folders
read-only folders
hidden folders

I did get around to running it myself. Same results as you and Sietse
describe. Folders with any of those attribs cannot be seen and cannot
be chosen in its browse/inventory dialog.

It is certainly a bug. As Sietse mentioned, perhaps side-effect related
to API for folder listing. (I notice that Filemon shows a succession of
"invalidfunc" lines, but don't know if/how that relates. I notice too that
the ioready.dll has specific queries for "ishidden," "issystem", etc,
also that this library looks consumed with thinking about iomega disks
over regular fat32 drives, but again don't know if/how that relates.)

For its actual thumbnails listings, say when selecting a full drive, I
note the result that you have. It doesn't care, then, about the nature
of the respective parent folders that might be involved. And for attribs
on individual files, the only ones it ignores are those with +h (hidden)
attrib.
 
O

omega

Sietse Fliege said:
[...]
So I got curious and installed the program (normally I wouldn't do that
with programs that have trouble with the XP filesystem). Just for this
once, because it has 'omega' in its name! hah, hah!

Thank you, Sietse! You could tell I'd got pretty curious on this, started
ringing pager for professional service.

If you send me a bill, well, check's in the mail, yknow.
Now there is something that I believe I have never seen yet.
It may be the same as what Maria and others saw:
When I click the browse button. then what appears to be a completely
normal Folder dialog box pops up, listing the various partitions and
removable drives.
But when I then click the plus button next to the c: drive, the
root folder does not unfold, it shows me no subfolders!

This reminds me a little of GoldenFrog's Shortcutter, which couldn't
understand root folders on NTFS, viewing them as "zero byte files."
What I can do is select e.g. the c: drive and then it begins to
recursively fetch all the images on the complete c: drive, including the
My pictures folder (no problem there).

Yes, now that I've run it, I note the result that you and Susan have:
it will not see various folders, yet will nevertheless precede to list
their image file contents in the thumbnails view.
I'm really puzzled with this.
AFIAK, programs that are not written for XP or for the NTFS file system
most times run perfectly well if they use the Windows APIs and use them
properly, e.g. to access files and folders. Windows does provide support
for that.
To me it looks like Photo Printer does just use the Windows API for the
folder dialog, but then the dialog does not work correctly. As if, when
I click the plus button, this is not handled by Windows but (in an
incorrect way) by Photo Printer.

That makes sense to me, that it was a failure on their part to use proper
API calls. Especially when you consider the additional limitation, the one
on both file systems, of the blindness to +S +R & +H folders, that which
is hard to imagine as deliberate design, especially given that the images
files under such parents are displayed regardless.
How can that happen? Baffles me. Maybe that a programmer if reading
this, can explain.

The invalidfunc lines in Filemon results looked sorts funky in my eyes,
but don't know how to relate that. And there is dependency on its library
ioready.dll, which seems to be 100% focussed on iomega media, and who knows,
maybe the way they wanted to converse with that, made some difference. But
all this kind of thing is quite beyond me. I am completely content with the
meaningful answers you've provided. That is: your descriptions of which
behaviors in the program will result in which specific circumstances....
 
S

Susan Bugher

omega said:
"Sietse Fliege" <[email protected]>:

That makes sense to me, that it was a failure on their part to use proper
API calls. Especially when you consider the additional limitation, the one
on both file systems, of the blindness to +S +R & +H folders, that which
is hard to imagine as deliberate design, especially given that the images
files under such parents are displayed regardless.
The invalidfunc lines in Filemon results looked sorts funky in my eyes,
but don't know how to relate that. And there is dependency on its library
ioready.dll, which seems to be 100% focussed on iomega media, and who knows,
maybe the way they wanted to converse with that, made some difference. But
all this kind of thing is quite beyond me. I am completely content with the
meaningful answers you've provided. That is: your descriptions of which
behaviors in the program will result in which specific circumstances....

Thanks for the additional input Karen. I too am very content with the
meaningful answers we now have. I really hate saying "I dunno, it works
okay for some people". ;)

Susan
 
S

Sietse Fliege

omega wrote:

[..]
Where I did get stumbled up not that long ago, however, it
was in a slightly different situation. An S-R program that I use:
"Simple Search-Replace" by RJL Software. I spent about an hour one
day, in trying to figure out what was wrong, after one replace
operation repeatedly failed. Only at the end realizing that the
problem involved the target directory having an S attrib.

"What's that terrible noise?" "Nothing really, just me falling with my
forehead on the keyboard, a couple of times."
By the way, in the case of my recent stumbling, the one with the prog
SSR, there was an extra complication. It can "see" those directories
that have the "S" attrib, and it can even process them -- if they or
their children are given as the search path. It's when I give it a
higher level folder for it to process that it then goes blind to any
subdirectories within which have the S attrib.

Funny, this is about the oppposite of what Photo Printer does.
In theory, I ought request the developer of SSR to do a fix. Or at
least make it optional toggle if they imagine there could ever be a
case where it would be wanted behavior.

Optional toggle sounds alright, should be used far more often, IMO.

I guess that disabling operations (file operations, s & r, and so on) in
'system' folders in fact does make sense. more than I said in the other
post. I can also imagine that authors don't want the abuse of users when
something goes wrong.

The thing is that the 'S' attribute should not be used for folders with
a custom icon.
But that is the way it works, on W9X, I believe since about 5 or 6
years, when Active Desktop was introduced with Internet Explorer 4.01 (I
believe), and it is yet another Redmond blunder.
When Explorer needs to display folders, in the tree or in the right-hand
pane, it checks the 'S' flagged folders for the existence of desktop.ini
and then reads them for icon - or other customization.
But why the 'S' attribute?
In WinXP icon-customization now is built-in, on the properties page, and
it sets the read-only attribute.
But you can still also use the 'S' atribute. In fact, I customized the
icons with a tool that came with nice icons and was just a bit handier,
but it does set the 'S' attribute.
I have been thinking about changing them, but decided not to, because it
provides me with a warning system that a program might be older or
sloppier than I thought.
 
O

omega

Sietse Fliege said:
I guess that disabling operations (file operations, s & r, and so on) in
'system' folders in fact does make sense. more than I said in the other
post. I can also imagine that authors don't want the abuse of users when
something goes wrong.

Except in programs with that blindness, it is usually not deliberate, is it?
It impressed me to be buggy side-effect, not design, in the case of both the
programs in this thread. Unfortunately, to bring up other examples, my memory
is failing me. But that's partly due to tendency to quickly toss out, like
you do, programs with hard limitation in this area.

I do note it is occasionally something thought over more carefully. Example
I'm thinking about is were the XXCopy author took time to consider what to
do in this situation. He ended by choosing to mirror XCopy behavior defaults,
when no special switches are given, since it was what we would expect, being
used to the other program.
The thing is that the 'S' attribute should not be used for folders with
a custom icon.
But that is the way it works, on W9X, I believe since about 5 or 6
years, when Active Desktop was introduced with Internet Explorer 4.01 (I
believe), and it is yet another Redmond blunder.
When Explorer needs to display folders, in the tree or in the right-hand
pane, it checks the 'S' flagged folders for the existence of desktop.ini
and then reads them for icon - or other customization.
But why the 'S' attribute?
In WinXP icon-customization now is built-in, on the properties page, and
it sets the read-only attribute.

As well: It strikes me that it would have been more consistent had W9X
used the +R instead of the +S attrib. Where I mean is the case of custom
..htt files within folders. For one of those to get honored for a folder,
when activating webview, it is the +R flag for such a folder that is then
needed/used.

Hey, one thing I am glad of at least. It's that this is one small moment
where they didn't go their usual route, and make the workings here entirely
a matter of registry mechanics. Notice that for custom icons for -drives-,
there it is implemented via a registry key for each one. (I'm assuming the
2K/XP story is same as 9X's on this point.) I'd find it a total mess, lots
of orphan debris left during moves etc, if the individual folder
customizations likewise each time meant extra registry keys.
But you can still also use the 'S' atribute. In fact, I customized the
icons with a tool that came with nice icons and was just a bit handier,
but it does set the 'S' attribute.

My long habit has been simple use of pmdevigne's "Change Icon," invoking
from sendto. Had you found a new toy you might recommend giving a spin?
I have been thinking about changing them, but decided not to, because it
provides me with a warning system that a program might be older or
sloppier than I thought.

Agree with that line of thought. For some of the older graphics/file viewer
type of programs, I'd become aware of the problem right away, since my
top-level folder for images has an +S attrib to support its custom icon
display.

Subtler problems, like the one I had with Simple Search-Replace, that's
a bit harder. There I might bang my head a while first... (In that case
I was initially sure it was some typo of mine in play, which I was being
blind to -- since that is a more usual type of cause for a number of my
initial stumbles.)
 
B

Bob Adkins

"What's that terrible noise?" "Nothing really, just me falling with my
forehead on the keyboard, a couple of times."

Have you considered taking the easy way out and using another program? :)

-- Bob
 
M

marcos.moroni

Does anyone know about a free alternative to Nero Burning? Or has a
link to an old free version of Nero?



Tks in advance!
 
S

Sietse Fliege

omega wrote:
[...]
I do note it is occasionally something thought over more carefully.
Example I'm thinking about is were the XXCopy author took time to
consider what to do in this situation. He ended by choosing to mirror
XCopy behavior defaults, when no special switches are given, since it
was what we would expect, being used to the other program.

Yes, Kan Yabumoto really knows his stuff and is extremely careful.
Hey, one thing I am glad of at least. It's that this is one small
moment where they didn't go their usual route, and make the workings
here entirely a matter of registry mechanics. Notice that for custom
icons for -drives-, there it is implemented via a registry key for
each one. (I'm assuming the 2K/XP story is same as 9X's on this
point.) I'd find it a total mess, lots of orphan debris left during
moves etc, if the individual folder customizations likewise each time
meant extra registry keys.

On my Windows 95 box I did not use the registry route, did not know
about one.
I had a file Autorun.inf in each drive root folder, containing only a
section [autorun] with the entry icon=pathto\driveX.ico,0

On XP it is a matter of registry keys. On my system extremely messy!
Normally it suffices to follow these instructions:
http://www.tweakxp.com/tweak2005.aspx Seems to work for most people.
Didn't work for me so I undid the changes I had made.
Then I tried another route, involving this registry key:
HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\MountPoints2
In there were already keys for each drive, called 'C', 'D', etc.
I was supposed to create 'DefaultIcon' keys in there. Didn't work.
Then I tried downloading tools that might do it for me.
None of them worked.
Then I used Regmon and saw that the MountPoints2 key was involved,
indeed. but different keys in there, consisting of numbers. Trying that
out it turned out that I had to create 'DefaultIcon' keys in there *and*
also redo the keys from tweakxp.com mentioned above. Both sets of keys
were needed. Phew!
Do not ever mention XP drive icons again, please! :)
My long habit has been simple use of pmdevigne's "Change Icon,"
invoking from sendto. Had you found a new toy you might recommend
giving a spin?

No, alas. :-( One of the tools I mentioned above was a shareware, that
came with nice icons.
I uninstalled it after the trial was over, but kept the icons. 8-O
(You would not want it as it also installs a shell extension dll.)

What I used to do was: extract the proper folder icon from shell32.dll
and use a Paint program and an Icon editor together to create colorized
icons, each with the proper multiple images. I liked to do that myself,
but you can of course also just download them from various places.
 
S

Sietse Fliege

Susan said:
Program: Iomega Photo Printer

I *always* see the photos in the subfolders too. I didn't know that!
This feature is sometimes requested in ACF. Very few apps have that
capability. FotoAlbum is one, now we have another.

I did a few tests a while ago to see which thumbnail browser could
open the *most* images before it choked. The Iomega app beat
IrfanView, XnView and SlowView by a large margin. (FotoAlbum could
open more but it *caches* thumbnails.)

I just want to add: if you like Iomega Photo Printer for its features
or you want to try it out, but you have WinXP with NTFS, then there is
an easy work-around for Photo Printer's problem with NTFS.

You only need to have something like MountVD (see below) installed.
This lets you very easily mount one or more folders as (a) virtual
drive(s), so Photo Printer will then only fetch the pictures in the
folder(s) (and sub folders) instead of the whole drive.

Suppose you have all your pictures in the My Pictures folder or its sub
folders. With MountVD installed, you can (in Explorer) just right-click
the My Pictures folder, select 'Mount Virtual Drive', and choose a drive
letter (say H:).
You then fire up Iomega Photo Printer and select the H: drive.
Now it will fetch all the pictures in the My Picture (sub)folder(s).
When you're done and have exited the Photo Printer app, you select the
H: drive in explorer, right-click and select 'Unmount Virtual Drive'.
This is all very easy and MountVD also lets you very easily mount
multiple drives (a list of previous mounts will be displayed, remount
with right mouse click.)

I have tried this out with Photo Printer. The My Pictures folder
(although it has the read-only attribute set) when mounted as a virtual
drive, is now easily accessable.


MountVD http://www.lando.co.za/walkerbrothers/mountvd.htm

"MountVD is a virtual drive mounter. Once installed - using Windows
Explorer (or such like browser) right-click on any folder and select
'Mount Virtual Drive'. Choose a drive letter and the folder will then be
mounted as a drive. To unmount right-click on the drive letter and
select 'Unmount Virtual Drive'.
A list of previous mounts will be displayed, clear the list or remount
with right mouse click.
Mount from Win startup: Set a list of folders to mount, along with their
drive letters - and the next time windows boots they will be
automaticaly mounted."
 
S

Susan Bugher

I just want to add: if you like Iomega Photo Printer for its features
or you want to try it out, but you have WinXP with NTFS, then there is
an easy work-around for Photo Printer's problem with NTFS.
I have tried this out with Photo Printer. The My Pictures folder
(although it has the read-only attribute set) when mounted as a virtual
drive, is now easily accessable.

MountVD http://www.lando.co.za/walkerbrothers/mountvd.htm

"MountVD is a virtual drive mounter. Once installed - using Windows
Explorer (or such like browser) right-click on any folder and select
'Mount Virtual Drive'. Choose a drive letter and the folder will then be
mounted as a drive. To unmount right-click on the drive letter and
select 'Unmount Virtual Drive'.
A list of previous mounts will be displayed, clear the list or remount
with right mouse click.
Mount from Win startup: Set a list of folders to mount, along with their
drive letters - and the next time windows boots they will be
automaticaly mounted."

What an *elegant* solution. You are a genius!!! MountVD should be useful
on FAT32 sytems as well (especially WinXP) to show the system, hidden
and read-only folders.

The download link (a redirect) didn't work properly for me. Info below
for others who may have the same problem.

v 3.0 build 25 - date 2004-07-28 - direct download:
http://www.lando.co.za/walkerbrothers/mountvd/software/mvdsetup.exe
(1388 KB)

Thank you Sietse. :) :) :)

Susan
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Top