Win2k -- FC: cannot open [FILENAME] - No such file or folder
Tom Del Rosso
I found a few usenet archives of threads on this problem, but found no
useful analysis there. I first saw it turn up with this batch line:
fc /lb0 /b "%%g" "%%f" | find /i "no differences" >nul
which loops through 2 folders and compares them.
Certain files (about 1 in 500) would produce the following error every time.
The same files trigger it after a reboot and chkdsk.
FC: cannot open PATHNAME - No such file or folder
The same happens at the command line with explicit file names, so the
context of the batch file is not the issue.
It only happens with 8.3 files with names in all caps (so SFN and LFN are
the same I would think). It does not happen without the quotes, but they
have to be in the batch for some files.
It is always triggered by the first file on the FC line. If they are
reversed, the same pair produces no error, but if that's done in the batch
file then errors are produced for files in the other folder.
It happens at the command line with other commands, like:
debug
list (DOS program)
It does not happen at the command line with:
notepad
attrib
find (as in find /i "the" PATHNAME)
So it looks like an issue with DOS programs (not 16 bit programs because
notepad is 16 bit). The file description for fc.exe says "DOS 5 File
Compare Utility" (not even DOS 6!!!) although the other fc.exe properties
look like a 16 bit windows exe. The properties of debug.exe are the same
format as any DOS exe program.
Since it always happens with the first file parameter, I guess it has to do
with the format of the "Program Segment Prefix" (took me a minute to
remember what it was called) where parameters are passed to the program.
So maybe the only solution is to get a replacement for FC. But maybe not,
because it doesn't happen with all files. One poster of a year ago said it
correlated with the archive attribute, but that's not true here - all the
archive bits are cleared. It doesn't happen without the quotes on the 8.3
files, but there are many other 8.3 files with names in all caps that don't
trigger the error.
There must be something different about those files, but I don't know
exactly what.
--
Reply in group, but if emailing add another
zero, and remove the last word.
billious
"Tom Del Rosso" <td...@att.net.invalid> wrote in message
news:487966e1$0$5025$607e...@cv.net...
Noticed the same phenomenon myself, and commented here with no response.
From what I recall, I found that once the system had decided that a file did
not exist, nothing could persuade it otherwise beyond a reboot. It appeared
that it occurred with mapped network drives, and I would have been using
short unquoted filenames exclusively. I'd confirm the dissociation from the
archive bit - I found that you could execute the SAME line that is
FC file1 file2 works fine
FC file1 file3 can't find file
FC file1 file2 can't find file
but I can't recall whether it was always file1 or file2, although I suspect
that
FC file2 file1
repeated the error.
Never did get a solution.
Liviu
news:487966e1$0$5025$607e...@cv.net...
>
> useful analysis there. I first saw it turn up with this batch line:
>
> fc /lb0 /b "%%g" "%%f" | find /i "no differences" >nul
With /b (binary compare) I don't think that /lb0 is needed (or, in fact,
that it does anything).
> Certain files (about 1 in 500) would produce the following error
>
> FC: cannot open PATHNAME - No such file or folder
>
> There must be something different about those files, but I don't know
> exactly what.
This sounds eerily familiar, could well be the same issue as this
http://groups.google.com/group/microsoft.public.win32.programmer.kernel/browse_frm/thread/7d3d631c746ff672/41c9596e1c9b7bb6
(or google the newsgroup archives for "ntfs comp, fc miss some files
without archive bit").
In short, one reason which can cause this to happen is files with no
attribute set (including the ntfs attributes - compressed, encrypted,
indexed etc). This was confirmed to be an fc bug back in 2003, and I see
it's still allive and well under today's xp.sp3.
--------
C:\etc>attrib
C:\etc\dummy.txt
C:\etc>fc /b dummy.txt dummy.txt
FC: cannot open DUMMY.TXT - No such file or folder
C:\etc>attrib dummy.txt +a
C:\etc>attrib
A C:\etc\dummy.txt
C:\etc>fc /b dummy.txt dummy.txt
Comparing files dummy.txt and DUMMY.TXT
FC: no differences encountered
--------
001.d...@gmail.com
> "Tom Del Rosso" <td...@att.net.invalid> wrote in messagenews:487966e1$0$5025$607e...@cv.net...
@echo off
for %%i in (folder1\*.txt) do (
for %%j (folder2\*txt) do fc "%%i" "%%j" 1>nul && echo no diff: %%i
- %%j || diff: %%i %%j
)
Todd Vargo
"Tom Del Rosso" <td...@att.net.invalid> wrote in message
news:487966e1$0$5025$607e...@cv.net...
>
> useful analysis there. I first saw it turn up with this batch line:
>
> fc /lb0 /b "%%g" "%%f" | find /i "no differences" >nul
/lb0 is invalid. Use /lb1 instead.
==== Screen capture ====
C:\WINDOWS\TEMP>fc /lb0 c:\autoexec.bat nul
Comparing files c:\AUTOEXEC.BAT and nul
FC: no differences encountered
C:\WINDOWS\TEMP>fc /lb1 c:\autoexec.bat nul
Comparing files c:\AUTOEXEC.BAT and nul
Resync failed. Files are too different
****** c:\AUTOEXEC.BAT
@ECHO OFF
****** nul
******
Note the first output used /lb0 and it returned "no differences" when
clearly there are. As far as your file not found issue goes, try placing an
ECHO in front of the line in your batch to see what is really being passed
in "%%g" and "%%f". We can not see your input to the FOR command but you may
need to insert a tilde in each variable to prevent quote doubling.
Change "%%g" "%%f" to "%%~g" "%%~f"
--
Todd Vargo
(Post questions to group only. Remove "z" to email personal messages)
foxidrive
>In short, one reason which can cause this to happen is files with no
>attribute set (including the ntfs attributes - compressed, encrypted,
>indexed etc). This was confirmed to be an fc bug back in 2003, and I see
>it's still allive and well under today's xp.sp3.
>
>--------
>C:\etc>attrib
> C:\etc\dummy.txt
>
>C:\etc>fc /b dummy.txt dummy.txt
>FC: cannot open DUMMY.TXT - No such file or folder
>
>C:\etc>attrib dummy.txt +a
>
>C:\etc>attrib
>A C:\etc\dummy.txt
>
>C:\etc>fc /b dummy.txt dummy.txt
>Comparing files dummy.txt and DUMMY.TXT
>FC: no differences encountered
>--------
It's not happening here in XP Pro SP3
======================================
M:\>attrib dummy.txt
M:\dummy.txt
M:\>fc dummy.txt dummy.txt
Comparing files dummy.txt and DUMMY.TXT
FC: no differences encountered
M:\>dir dummy.txt
Volume in drive M is RAMDISK
Volume Serial Number is 7FFF-FFFF
Directory of M:\
14/07/2008 00:05 5 dummy.txt
1 File(s) 5 bytes
0 Dir(s) 52,277,248 bytes free
======================================
That was a FAT32 drive and here is an NTFS drive
======================================
D:\a>attrib dummy.txt
D:\a\dummy.txt
D:\a>fc dummy.txt dummy.txt
Comparing files dummy.txt and DUMMY.TXT
FC: no differences encountered
======================================
billious
> On 13 июл, 07:01, "billious" <billious_1...@hotmail.com> wrote:
>> "Tom Del Rosso" <td...@att.net.invalid> wrote in
>> messagenews:487966e1$0$5025$607e...@cv.net...
>>
>>
And your point is?
From the prompt, the system response to the command-sequence
FC file1 file2
FC file1 file3
FC file1 file2
Was :
* a correct report for the first command
* Can't find file for the second (although both files existed)
* Can't find file for the third (although both files existed - and this is
simply a repeat of the first command, which produced a correct report)
Liviu
"foxidrive" <got...@woohoo.invalid> wrote in message
news:ou2k74dufu70fuafe...@4ax.com...
> On Sat, 12 Jul 2008 22:43:31 -0500, "Liviu" <lab...@gmail.c0m> wrote:
>
>>In short, one reason which can cause this to happen is files with no
>>attribute set (including the ntfs attributes - compressed, encrypted,
>>indexed etc). This was confirmed to be an fc bug back in 2003, and I
>>see it's still allive and well under today's xp.sp3.
>
> That was a FAT32 drive [...]
Don't know (and don't think) that it happens on FAT32.
> [...] and here is an NTFS drive
You cannot see or set the NTFS extended attributes from attrib. Instead,
open the file properties in explorer, including the "advanced" box, and
make sure none of these are checked (or turn them off if they are):
- read only
- hidden
- file is ready for archiving
- for fast searching allow indexing service to index this file
- compress contents to save disk space
- encrypt contents to secure data.
For files with no attributes set (including none of the extended NTFS
attributes) fc fails every time.
foxidrive
>>>In short, one reason which can cause this to happen is files with no
>>>attribute set (including the ntfs attributes - compressed, encrypted,
>>>indexed etc). This was confirmed to be an fc bug back in 2003, and I
>>>see it's still allive and well under today's xp.sp3.
>
>You cannot see or set the NTFS extended attributes from attrib. Instead,
>open the file properties in explorer, including the "advanced" box, and
>make sure none of these are checked (or turn them off if they are):
>- read only
>- hidden
>- file is ready for archiving
>- for fast searching allow indexing service to index this file
>- compress contents to save disk space
>- encrypt contents to secure data.
>
>For files with no attributes set (including none of the extended NTFS
>attributes) fc fails every time.
Then there is your solution, add an archive attribute to the first file in
the FC command line before comparing, no? Many batch file techniques
depend on curiosities in the system, so here it seems is one more.
Liviu
"foxidrive" wrote in message
That's one possible workaround, though it's somewhat intrusive. It could
confuse the heck out of programs which depend on the archive bit (such
as some sync/backup utilities), and may be downright impossible if the
user rights to the file in question don't allow attrib changes.
A cheaper solution is to use comp.exe instead of fc /b. It works with
individual files - including those with no attributes set which choke fc
(though comp.exe also ignores them when using wildcards).
--------
C:\etc>dir /b
dummy.txt
C:\etc>echo n | comp *.txt *.txt
Can't find/open file: *.txt
Compare more files (Y/N) ?
C:\etc>echo n | comp dummy.txt dummy.txt
Comparing dummy.txt and dummy.txt...
Files compare OK
Compare more files (Y/N) ?
--------
Tom Del Rosso
"Todd Vargo" <tlv...@sbcglobal.netz> wrote in message
news:g%mek.12356$cW3....@nlpi064.nbdc.sbc.com
> "Tom Del Rosso" <td...@att.net.invalid> wrote in message
> news:487966e1$0$5025$607e...@cv.net...
> >
> > I found a few usenet archives of threads on this problem, but found
> > no useful analysis there. I first saw it turn up with this batch
> > line:
> >
> > fc /lb0 /b "%%g" "%%f" | find /i "no differences" >nul
>
> /lb0 is invalid. Use /lb1 instead.
Right, it was that way in my batch before I started editing it.
> Note the first output used /lb0 and it returned "no differences" when
> clearly there are. As far as your file not found issue goes, try
> placing an ECHO in front of the line in your batch to see what is
> really being passed in "%%g" and "%%f". We can not see your input to
> the FOR command but you may need to insert a tilde in each variable
> to prevent quote doubling.
>
> Change "%%g" "%%f" to "%%~g" "%%~f"
It has no effect, since this also happens at the command line.
Tom Del Rosso
"billious" <billio...@hotmail.com> wrote in message
news:48797019$0$13876$a82e...@reader.athenanews.com
>
> Noticed the same phenomenon myself, and commented here with no
> response.
>
> From what I recall, I found that once the system had decided that a
> file did not exist, nothing could persuade it otherwise beyond a
> reboot. It appeared that it occurred with mapped network drives, and
> I would have been using short unquoted filenames exclusively. I'd
> confirm the dissociation from the archive bit - I found that you
> could execute the SAME line that is
>
> FC file1 file2 works fine
> FC file1 file3 can't find file
> FC file1 file2 can't find file
>
> but I can't recall whether it was always file1 or file2, although I
> suspect that
> FC file2 file1
>
> repeated the error.
>
> Never did get a solution.
I reversed the file order on the FC line again, and noticed that many files
in the other folder that do not have 8.3 names also trigger this, so I was
wrong about that. Name length is not a factor.
I also did more experiments with attributes and found that the index
attribute was the unique factor, and setting the archive or other bits fixes
it.
So the factors I have are:
1 - No attributes are set.
2 - It's the first file on the command line of certain 16 bit programs that
parse parameters a certain way.
3 - It must be quoted.
As far as I can see, anyway, this issue never arises if there are no quotes,
but another issue does, for a new thread.
Tom Del Rosso
"Liviu" <lab...@gmail.c0m> wrote in message
news:jSeek.15229$uE5....@flpi144.ffdc.sbc.com
>
> With /b (binary compare) I don't think that /lb0 is needed (or, in
> fact, that it does anything).
That seems to be true, because the output is the same with or without it.
Some time ago I found it executed much faster with /lb1, but output was sent
to nul and I didn't examine it. I'll have to try a speed test again.
> This sounds eerily familiar, could well be the same issue as this
>
http://groups.google.com/group/microsoft.public.win32.programmer.kernel/browse_frm/thread/7d3d631c746ff672/41c9596e1c9b7bb6
> (or google the newsgroup archives for "ntfs comp, fc miss some files
> without archive bit").
I hadn't found that one. I found another thread that said the same thing,
but I discounted it because all the files had the attributes cleared, not
just the problems files. But I just checked the index attribute and
confirmed that this explanation is correct. Only the problem files had
index cleared.
> In short, one reason which can cause this to happen is files with no
> attribute set (including the ntfs attributes - compressed, encrypted,
> indexed etc). This was confirmed to be an fc bug back in 2003, and I
> see it's still allive and well under today's xp.sp3.
The thing is, however, it is not an FC bug. It's a Windows bug. The same
thing happens if you open the file with debug, or any DOS program.
Apparently some programs still open files using old methods, and Windows
passes the file name to DOS programs using the attribute filter incorrectly.
But Windows only makes this mistake if the pathname is quoted.
Liviu
>
> is correct. Only the problem files had index cleared.
In that case, and if you want a binary compare anyway, you can just
replace "fc /b" with "comp" and the batch should then work.
>> In short, one reason which can cause this to happen is files with no
>> attribute set (including the ntfs attributes - compressed, encrypted,
>> indexed etc). This was confirmed to be an fc bug back in 2003, and I
>> see it's still allive and well under today's xp.sp3.
>
> The thing is, however, it is not an FC bug. It's a Windows bug.
No. It _is_ an FC bug - it attempts to open the file using the wrong
combination of flags. You can find the ugly/tech details in the old
thread, and another one preceding it back at that time.
> The same thing happens if you open the file with debug, or any DOS
> program. Apparently some programs still open files using old methods,
> and Windows passes the file name to DOS programs using the attribute
> filter incorrectly. But Windows only makes this mistake if the
> pathname is quoted.
Sorry, I don't follow this. For one thing, I don't see any difference
between quotes or no quotes at the command line. Then, I am not sure
what you mean by "DOS programs". Both FC and COMP are 32b console
applications (= text mode programs, but neither 16b nor DOS) with full
and equal rights as far as Windows is concerned. One of them (fc) tries
to open a file the wrong way, and fails. The other one (comp) uses the
right flags to open the same file and works. That's all it is to this
story. If other programs you know fail the same way as FC, then they
just happen to have the same bug. ( Incidentally, comp has a related bug
when using wildcards. However, it works correctly for single files. )
Todd Vargo
> Todd Vargo wrote:
>> Tom Del Rosso wrote:
>>>
>>> I found a few usenet archives of threads on this problem, but found
>>> no useful analysis there. I first saw it turn up with this batch
>>> line:
>>>
>>> fc /lb0 /b "%%g" "%%f" | find /i "no differences" >nul
>>
>> /lb0 is invalid. Use /lb1 instead.
>
> Right, it was that way in my batch before I started editing it.
>
>
>> Note the first output used /lb0 and it returned "no differences" when
>> clearly there are. As far as your file not found issue goes, try
>> placing an ECHO in front of the line in your batch to see what is
>> really being passed in "%%g" and "%%f". We can not see your input to
>> the FOR command but you may need to insert a tilde in each variable
>> to prevent quote doubling.
>>
>> Change "%%g" "%%f" to "%%~g" "%%~f"
>
> It has no effect, since this also happens at the command line.
Did changing /lb0 to /lb1 solve the problem? If not, please restate the
remaining problem and include an actual command line so that others can
reproduce the problem. It may help if you isolate a few problem files into a
folder by themselves and then provide us with full details so that others
would be able to reproduce the situation exactly.
Tom Del Rosso
"Liviu" <lab...@gmail.c0m> wrote in message
> >
> > I just checked the index attribute and confirmed that this
> > explanation is correct. Only the problem files had index cleared.
>
> In that case, and if you want a binary compare anyway, you can just
> replace "fc /b" with "comp" and the batch should then work.
There are a few workarounds, but I wanted to characterize the problem
thoroughly so at least I could trust the workarounds.
> >> In short, one reason which can cause this to happen is files with
> >> no attribute set (including the ntfs attributes - compressed,
> >> encrypted, indexed etc). This was confirmed to be an fc bug back
> >> in 2003, and I see it's still allive and well under today's xp.sp3.
> >
> > The thing is, however, it is not an FC bug. It's a Windows bug.
>
> No. It _is_ an FC bug - it attempts to open the file using the wrong
> combination of flags. You can find the ugly/tech details in the old
> thread, and another one preceding it back at that time.
Ok, right, it's a different issue. Debug seems to be a DOS program so it
refuses quoted names. When I give it an unquoted name it works regardless
of the attributes.
I had tested other programs with the problem files, but not with the files
that worked, so I thought it was the same issue.
> > The same thing happens if you open the file with debug, or any DOS
> > program. Apparently some programs still open files using old
> > methods, and Windows passes the file name to DOS programs using the
> > attribute filter incorrectly. But Windows only makes this mistake
> > if the pathname is quoted.
>
> Sorry, I don't follow this. For one thing, I don't see any difference
> between quotes or no quotes at the command line.
I don't see any difference now either. But last night I thought I did, with
FC at the command line or in a batch. The sleepy attribute is the only
cause I can think of.
> Then, I am not sure
> what you mean by "DOS programs". Both FC and COMP are 32b console
> applications (= text mode programs, but neither 16b nor DOS) with full
> and equal rights as far as Windows is concerned. One of them (fc)
> tries to open a file the wrong way, and fails. The other one (comp)
> uses the right flags to open the same file and works. That's all it
> is to this story. If other programs you know fail the same way as FC,
> then they just happen to have the same bug. ( Incidentally, comp has
> a related bug when using wildcards. However, it works correctly for
> single files. )
Got it. With debug and DOS programs it was a different problem though.
Because I thought DOS programs were doing the same thing, I thought Windows
had to be at fault since their attribute filters don't include all the bits.
Tom Del Rosso
"Todd Vargo" <tlv...@sbcglobal.netz> wrote in message
> >>
> >> Change "%%g" "%%f" to "%%~g" "%%~f"
> >
> > It has no effect, since this also happens at the command line.
>
> Did changing /lb0 to /lb1 solve the problem?
No, just a side issue.
> If not, please restate
> the remaining problem and include an actual command line so that
> others can reproduce the problem. It may help if you isolate a few
> problem files into a folder by themselves and then provide us with
> full details so that others would be able to reproduce the situation
> exactly.
I think I isolated it to the attributes. If all the bits are cleared
including index (which doesn't display in the file list) then FC can't open
it.
Another issue had confused me because they overlapped. DOS apps can't take
quoted file names, and debug appears to be a DOS program.
Todd Vargo
EDIT is a DOS program and it does accept quoted filenames.
Is the problem all DOS apps, or just the ones not updated to work with LFNs?
Tom Del Rosso
"Todd Vargo" <tlv...@sbcglobal.netz> wrote in message
>
> EDIT is a DOS program and it does accept quoted filenames.
> Is the problem all DOS apps, or just the ones not updated to work
> with LFNs?
In that case "that" problem is only with some programs. But it is not the
same problem that came up with FC, I now realize.
Dr J R Stockton
Jul 2008 22:17:55, Tom Del Rosso <td...@att.net.invalid> posted:
>
>So maybe the only solution is to get a replacement for FC.
FILECMPR, PAS EXE ZIP via sig line 3, may serve.
--
(c) John Stockton, nr London UK. ?@merlyn.demon.co.uk DOS 3.3, 6.20; WinXP.
Web <URL:http://www.merlyn.demon.co.uk/> - FAQqish topics, acronyms & links.
PAS EXE TXT ZIP via <URL:http://www.merlyn.demon.co.uk/programs/00index.htm>
My DOS <URL:http://www.merlyn.demon.co.uk/batfiles.htm> - also batprogs.htm.