John Shotsky wrote:

Only now, I can’t get it to work at all,
but I have been using the more full blown clip since 2017, and I
KNOW it was working, because I typed in the date I tested it

Not unsurprisingly it works fine here. NT hasn't changed in years. What
does keep changing and breaking is Windows. I can only guess here and
couldn't test on anything above version 8 even I wanted to.

What I consider most probabable is paths. The paths you are shown and
believe to be using need not have anything to do with the real paths any
more. NT uses real paths, not the ones you are shown and see. You may no
longer be allowed to create a directory right in the root. So your
"C:\work\" may really point to C-users-shotsky-work or something along
those lines. (Over here you would be shown German directory names like
"Anwenderdaten" for what really are the standard English ones.)

Forget Windows Explorer and anything like it. You might have a chance with
e.g. Totalcommander.

--
/¯\ No | Dipl.-Ing. F. Axel Berger Tel: +49/ 221/ 7771 8067
\ / HTML | Roald-Amundsen-Straße 2a Fax: +49/ 221/ 7771 8069
 X in | D-50829 Köln-Ossendorf http://berger-odenthal.de
/ \ Mail | -- No unannounced, large, binary attachments, please! --

Op 23/11/2019 om 10:37 schreef Axel Berger:

What I consider most probabable is paths. The paths you are shown and
believe to be using need not have anything to do with the real paths any
more. NT uses real paths, not the ones you are shown and see. You may no

MS' OneDrive enabled? Attention then, it changes something about "Documents". Here it has destroyed my "Paperport"! Immediately I left OneDrive (I don't dare to delete in order not to cause more damage).

a.

On 23/11/2019 06:48, Adrien Verlee wrote:

Op 23/11/2019 om 10:37 schreef Axel Berger:

What I consider most probabable is paths. The paths you are shown and
believe to be using need not have anything to do with the real paths any
more. NT uses real paths, not the ones you are shown and see. You may no

MS' OneDrive enabled? Attention then, it changes something about
"Documents". Here it has destroyed my "Paperport"! Immediately I left
OneDrive (I don't dare to delete in order not to cause more damage).

To elaborate on this and on Axel Berger's message...

1.  Since Windows Vista, Microsoft added the ability to Windows Explorer
of showing a different name than the "real one" that's used on disk.

Its main intended use is for localization: previous Windows versions
used localized names for folders such as "Program Files", which
sometimes created problems. For instance, in Portuguese that folder was
called "Arquivos de Programas" -- but some (badly-written) software
expected it to be called "Program Files", which caused a few issues.
Since Vista, the folder is always called by its English name "Program
Files", but it's _presented to the user_ as being named "Arquivos de
Programas."

It's not hard to see the true pathname, however. Just clicking on the
address bar as if you were going to edit it changes the display from the
"breadcrumbs" mode to "real pathname" mode -- which shows the real path.
Command prompt (CMD, PowerShell) and some alternative file manager
software may also show always the real folder names.

2. Vista and its successors also make an intense use of disk redirects
-- NTFS hardlinks, junctions and such. The idea being, if you attempt to
access something in the deprecated way (like "Arquivos de Programas"
mentioned above) it will redirect you to the correct folder. Except...
it's not perfect; there are a few modes in which this redirection fails.

3. In some circumstances, if you try doing changes to a folder you don't
have write privileges to (basically anything in the Windows, Program
Files, Program Files (x86) and Program Data trees if you are not an
administrator nor can elevate to admin), Vista and its successors will
"fake" it, letting you save in a special folder in your user profile
that is presented to you as merged with the real folder.  I don't see it
happening much nowadays, since most programs do not even try doing that.
But it can happen, and confuse the issue of what is the actual pathname
of the file you are trying to access. It shouldn't affect anything in
user folders, however.

4. Vista and its successors restrict somewhat access to the disk root
folder. What this usually mean is that only admins can put *files* in
the root folder, but creating subfolders is fine.

5. It's not OneDrive _per se_ that moves stuff around. However, recent
versions of Windows 10 are pretty insistent on pushing a ramsonware
protection feature, which you might have activated. What this feature
does, essentially, is to move a few user folders -- Desktop, Documents,
Pictures, Music and such -- inside OneDrive, so if you suffer a
ransomware attack, your content is safe in the cloud. Not a bad idea by
itself, but it moves stuff from the usual places and, depending on how
much stuff you have, may easily run into OneDrive storage limits.


--
MCBastos

This message has been protected with the 2ROT13 algorithm. Unauthorized use will be prosecuted under the DMCA.

No, nothing like that. Has nothing to do with paths. I don't use any Microsoft folders to start with, and besides, I used C:\work which is about the simplest folder structure you can come up with. 
The command no longer works. Tests with the absolutely most simple case don't work.  Using admin privileges didn't help. Rebooting didn't help. That command has just stopped working.
Try it. That's why I provided the test case - so YOU can tell me if it works for you.

I was a little worried because I use the IfFileExist command myself but I tested it with several folders and do not see any problems.
If it helps you, here is a clip I wrote to help check.
It will look for all the files in a path you set and count them as well as count the number of files IfFileExists finds. They SHOULD match.
Joy

John Shotsky wrote:

so YOU can tell me if it works for you.

Axel Berger wrote:

Not unsurprisingly it works fine here. NT hasn't changed in years.

--
/¯\ No | Dipl.-Ing. F. Axel Berger Tel: +49/ 221/ 7771 8067
\ / HTML | Roald-Amundsen-Straße 2a Fax: +49/ 221/ 7771 8069
 X in | D-50829 Köln-Ossendorf http://berger-odenthal.de
/ \ Mail | -- No unannounced, large, binary attachments, please! --

I will ask this question another way, since it is unclear how/why it is not working now.
The task is to compare photo callouts in a doc with actual photos on disk, and remove the photo callout if the photo is not found on disk.
The callouts are always formed as follows:
<img src="00000.jpg">
The files are always formed as:
00000.jpg
The document is in the same folder as the photos.
There can be hundreds of callouts in one doc. Users often use a browser in thumbnail mode to bulk erase photos, but that leaves the callouts for them remaining in the doc. This clip is meant to remove the callouts when a photo isn't found.
The outline for my existing clip section is as follows:
Get the path and name of the document and store those in variables. (So, we know the path, which is named %BasePath%.
Jump 1
Find a photo callout.
Use ^$GetReSubstrings$ to get the photo name %PhotoName% and %PhotoTag%.(minus the path)
At this point, the photo tag is known, and the photo name is known. The path is known. The command I've been trying to use, which did work before, is IfFileExist.
Supposedly, if the file does exist, it should jump to a label. But it doesn't. It has worked in the past, and nothing was changed. One day it just stopped working. I am running Win10 with all updates. When I say it stopped working, I mean it removes ALL callouts, regardless of whether the photos are on disk or not. I've used debug, to verify it is looking in the right places and for the right files.
So, I'm looking for an alternative way to approach this without using IfFileExist. Or, maybe someone can come up with a way to use it that works for me (and my users)
Any ideas?
Thanks,
John

John Shotsky wrote:

So, I'm looking for an alternative way to approach this without using
IfFileExist. Or, maybe someone can come up with a way to use it that
works for me (and my users)

Can you make another small but complete test case for me to try out unter
Windows 8.1? That's the highest I can offer.

Have you tried Joy's test clip?

--
/¯\ No | Dipl.-Ing. F. Axel Berger Tel: +49/ 221/ 7771 8067
\ / HTML | Roald-Amundsen-Straße 2a Fax: +49/ 221/ 7771 8069
 X in | D-50829 Köln-Ossendorf http://berger-odenthal.de
/ \ Mail | -- No unannounced, large, binary attachments, please! --

Solved this problem - and I feel a bit foolish. The disk files were named .jpeg, while the callouts were named .jpg. So, it wasn't finding ANY photos with the correct name....
Other than feeling dumb, all is well, and it works as it used to. I just happened to try it on a document whose photos were all jpegs...Usually, I rename those on disk FIRST, but this was an occasion where I didn't run that part first. Now I know that I must do the renaming as part of the command to search for them.

Regards,
John

On Wed, Dec 4, 2019 at 10:30 AM, John Shotsky wrote:

I'm looking for an alternative way to approach this without using IfFileExist.

What did you learn with the clip I posted?

If your system is working correctly, did you check for corrupted file names? Just because it looks like 12345.jpg doesn't mean it really is (although, yes, it should be). Try going to an actual file such as 12345.jpg and rename it zzz.jpg then rename it manually back to 12345.jpg

If you really need to try another method, how about
^!Set %FN1%=C:\Users\qiuh2\Utils\readme.txt
^!If ^$GetFileSize(^%FN1%)$ =-1 FILE_DOES_NOT_EXIST

My test shows -1 for a file not found. Case does not matter. Quotes around the filename did not matter as ^$GetFileSize(C:\Users\qiuh2\Utils\read me.txt)$ worked correctly without quotes even thought there is a space in the name. The help file doesn't specify quotes. Beware.

Joy

John Shotsky wrote:

The disk files were named .jpeg, while the callouts were named .jpg.

Ah well. I'm not going to tell you about the silly blunders I made, suffice
it to say there were quite a few.

--
/¯\ No | Dipl.-Ing. F. Axel Berger Tel: +49/ 221/ 7771 8067
\ / HTML | Roald-Amundsen-Straße 2a Fax: +49/ 221/ 7771 8069
 X in | D-50829 Köln-Ossendorf http://berger-odenthal.de
/ \ Mail | -- No unannounced, large, binary attachments, please! --

John Shotsky wrote:

Ah well. I'm not going to tell you about the silly blunders I made, suffice it to say there were quite a few.

That's funny. I was suspecting this was going to be a "smack your head" issue but didn't want to say it. Sleep is important! Won't be the first time, won't be the last.

Joy

Joy, I found the problem - it was that the files were named .jpeg, while my code was looking for .jpg. Simple error, but it took me a long time to spot it. Like when I use 'd' in a clip without the \d...then can't spot the missing backslash for hours...
Regards,
John