Welcome!

By registering with us, you'll be able to discuss, share and private message with other members of our community.

SignUp Now!

FixNames problem?

Apr
1,794
15
[D:\Bad_Files\JPG_001]echo %@ascii["02kσtYukiA01.jpg"]
34 48 50 107 963 116 89 117 107 105 65 48 49 46 106 112 103 34

[D:\Bad_Files\JPG_001]echo %@unicode["02kσtYukiA01.jpg"]
34 48 50 107 963 116 89 117 107 105 65 48 49 46 106 112 103 34

When I do fixnames *.* it just reports the current folder. No files are processed.
 
[D:\Bad_Files\JPG_001]echo %@ascii["02kσtYukiA01.jpg"]
34 48 50 107 963 116 89 117 107 105 65 48 49 46 106 112 103 34

[D:\Bad_Files\JPG_001]echo %@unicode["02kσtYukiA01.jpg"]
34 48 50 107 963 116 89 117 107 105 65 48 49 46 106 112 103 34

When I do fixnames *.* it just reports the current folder. No files are processed.

That doesn't look like a problematic filename to me. (Unless the quotes are actually part of the filename, and not just added on by filename completion. Are you saying that e.g. DIR 02* reports the filename with quotes around it?)
 
Nope. I just did [ then tabbed to get the filename - and TCMD/TCC placed it in quotes. I think the problem might be the char that returns 963 with both ascii and unicode functions... Since the ascii table goes to the 250s range - what would cause a 963 return value?
----- Original Message -----
From: Charles Dye
To: [email protected]
Sent: Monday, September 26, 2011 11:52 AM
Subject: RE: [Plugins-t-3242] Re: FixNames problem?


Quote:
Originally Posted by Charles G
[D:\Bad_Files\JPG_001]echo %@ascii["02kÏftYukiA01.jpg"]
34 48 50 107 963 116 89 117 107 105 65 48 49 46 106 112 103 34

[D:\Bad_Files\JPG_001]echo %@unicode["02kÏftYukiA01.jpg"]
34 48 50 107 963 116 89 117 107 105 65 48 49 46 106 112 103 34

When I do fixnames *.* it just reports the current folder. No files are processed.

That doesn't look like a problematic filename to me. (Unless the quotes are actually part of the filename, and not just added on by filename completion. Are you saying that e.g. DIR 02* reports the filename with quotes around it?)
 
From: Charles G
| Nope. I just did [ then tabbed to get the filename - and TCMD/TCC
| placed it in quotes. I think the problem might be the char that
| returns 963 with both ascii and unicode functions... Since the ascii
| table goes to the 250s range - what would cause a 963 return value?
| ----- Original Message -----
| [D:\Bad_Files\JPG_001]echo %@ascii["02kÏftYukiA01.jpg"]
| 34 48 50 107 963 116 89 117 107 105 65 48 49 46 106 112 103 34
|
| [D:\Bad_Files\JPG_001]echo %@unicode["02kÏftYukiA01.jpg"]
| 34 48 50 107 963 116 89 117 107 105 65 48 49 46 106 112 103 34

The character whose code is reported to be 963 displays differently on my system, depending on the encoding I choose. I saw greek lower case letter sigma, tiny "v" on top of capital-D, capital I with two side-by-side dots on top.

One question about the report of the two functions @ASCII and @UNICODE - does it make any difference whether you choose ASCII or Unicode output, esp. when you obtain the name from the OS?

Did you try older versions of TCC?
--
Steve
 
Nope. I just did [ then tabbed to get the filename - and TCMD/TCC placed it in quotes. I think the problem might be the char that returns 963 with both ascii and unicode functions... Since the ascii table goes to the 250s range - what would cause a 963 return value?

I don't know the difference between the @ASCII and @UNICODE functions. But since @ASCII is pretty clearly intended to handle ASCII (or at most ANSI) characters, passing it characters past 255 is probably not kosher; getting the original value back seems like a nicer response than e.g. failing with an error message, 'translating' the character to some similar (or similar-looking!) character in the current code page, replacing it with e.g. a question mark....

Anyway, character 963 -- lowercase sigma in Unicode -- is a perfectly valid filename character; NTFS uses Unicode for filenames. What problem are you having with that file? Is it on a FAT volume, or NTFS?
 
Unicode output doesn't matter, nore does the TCC version. Tried v8 and v13 - same output on both. Also using the "[" then tab- tcc still places the filename in quotes.
----- Original Message -----
From: Steve Fabian
To: [email protected]
Sent: Monday, September 26, 2011 02:18 PM
Subject: RE: [Plugins-t-3242] Re: FixNames problem?


From: Charles G
| Nope. I just did [ then tabbed to get the filename - and TCMD/TCC
| placed it in quotes. I think the problem might be the char that
| returns 963 with both ascii and unicode functions... Since the ascii
| table goes to the 250s range - what would cause a 963 return value?
| ----- Original Message -----
| [D:\Bad_Files\JPG_001]echo %@ascii["02kÏftYukiA01.jpg"]
| 34 48 50 107 963 116 89 117 107 105 65 48 49 46 106 112 103 34
|
| [D:\Bad_Files\JPG_001]echo %@unicode["02kÏftYukiA01.jpg"]
| 34 48 50 107 963 116 89 117 107 105 65 48 49 46 106 112 103 34

The character whose code is reported to be 963 displays differently on my system, depending on the encoding I choose. I saw greek lower case letter sigma, tiny "v" on top of capital-D, capital I with two side-by-side dots on top.

One question about the report of the two functions @ASCII and @UNICODE - does it make any difference whether you choose ASCII or Unicode output, esp. when you obtain the name from the OS?

Did you try older versions of TCC?
--
Steve
 
it's on a NTFS volume. The snipet of code that has the error is:

========== begin paste
setdos /x-5
do cFile in @jpg.out
iff not isfile "%cFile" then
echo N/F: %cfile >>! move_jpgs.err
ITERATE
endiff
========== end paste

jpg.out is made by:

dir /b /s .jpg > jpg.out
----- Original Message -----
From: Charles Dye
To: [email protected]
Sent: Monday, September 26, 2011 02:41 PM
Subject: RE: [Plugins-t-3242] Re: FixNames problem?


Quote:
Originally Posted by Charles G
Nope. I just did [ then tabbed to get the filename - and TCMD/TCC placed it in quotes. I think the problem might be the char that returns 963 with both ascii and unicode functions... Since the ascii table goes to the 250s range - what would cause a 963 return value?

I don't know the difference between the @ASCII and @UNICODE functions. But since @ASCII is pretty clearly intended to handle ASCII (or at most ANSI) characters, passing it characters past 255 is probably not kosher; getting the original value back seems like a nicer response than e.g. failing with an error message, 'translating' the character to some similar (or similar-looking!) character in the current code page, replacing it with e.g. a question mark....

Anyway, character 963 -- lowercase sigma in Unicode -- is a perfectly valid filename character; NTFS uses Unicode for filenames. What problem are you having with that file? Is it on a FAT volume, or NTFS?
 
From: Charles G
| jpg.out is made by:
|
| dir /b /s .jpg > jpg.out

I suspect the actual list generator code is something more like this (note the asterisk):
dir /b /s *.jpg > jpg.out
--
Steve
 
yes it did have the * where you said.... I was eating dinner, listening to TV, while repling to a lot of emails. Sorry...
----- Original Message -----
From: Steve Fabian
To: [email protected]
Sent: Monday, September 26, 2011 07:18 PM
Subject: RE: [Plugins-t-3242] Re: FixNames problem?


From: Charles G
| jpg.out is made by:
|
| dir /b /s .jpg > jpg.out

I suspect the actual list generator code is something more like this (note the asterisk):
dir /b /s *.jpg > jpg.out
--
Steve
 
Also it seems that sending in Outlook Express I had the lines following the DO cFile ... line indented but it's not when posted to the list.... Is it on my end or any ideas?
----- Original Message -----
From: Charles G
To: [email protected]
Sent: Monday, September 26, 2011 06:55 PM
Subject: RE: [Plugins-t-3242] Re: FixNames problem?


it's on a NTFS volume. The snipet of code that has the error is:

========== begin paste
setdos /x-5
do cFile in @jpg.out
iff not isfile "%cFile" then
echo N/F: %cfile >>! move_jpgs.err
ITERATE
endiff
========== end paste

jpg.out is made by:

dir /b /s .jpg > jpg.out
----- Original Message -----
From: Charles Dye
To: [email protected]
Sent: Monday, September 26, 2011 02:41 PM
Subject: RE: [Plugins-t-3242] Re: FixNames problem?


Quote:
Originally Posted by Charles G
Nope. I just did [ then tabbed to get the filename - and TCMD/TCC placed it in quotes. I think the problem might be the char that returns 963 with both ascii and unicode functions... Since the ascii table goes to the 250s range - what would cause a 963 return value?

I don't know the difference between the @ASCII and @UNICODE functions. But since @ASCII is pretty clearly intended to handle ASCII (or at most ANSI) characters, passing it characters past 255 is probably not kosher; getting the original value back seems like a nicer response than e.g. failing with an error message, 'translating' the character to some similar (or similar-looking!) character in the current code page, replacing it with e.g. a question mark....

Anyway, character 963 -- lowercase sigma in Unicode -- is a perfectly valid filename character; NTFS uses Unicode for filenames. What problem are you having with that file? Is it on a FAT volume, or NTFS?
 
On Mon, Sep 26, 2011 at 7:38 PM, Charles G <> wrote:

> Also it seems that sending in Outlook Express I had the lines following the DO cFile ... line indented but it's not when posted to the list.... *Is it on my end or any ideas?

The code snippet message sent to the list showed as properly indented
in GMail here.
______
Dennis
 
Thank you Dennis - I sent and rec'd both in OE 6 under Win XP sp3 Pro...
----- Original Message -----
From: DMcCunney
To: [email protected]
Sent: Monday, September 26, 2011 08:06 PM
Subject: RE: [Plugins-t-3242] Re: FixNames problem?


On Mon, Sep 26, 2011 at 7:38 PM, Charles G <> wrote:


Quote:
> Also it seems that sending in Outlook Express I had the lines following the DO cFile ... line indented but it's not when posted to the list.... *Is it on my end or any ideas?

The code snippet message sent to the list showed as properly indented
in GMail here.
______
Dennis
 
it's on a NTFS volume. The snipet of code that has the error is:

I'm wondering whether that mystery character really is character #963, or whether it's something else that just gets 'translated' to that value. Like say maybe character 229, which was the lowercase sigma in ye olde IBM PC character set, and was used to mark deleted files on FAT volumes; that might cause weird behavior...?

If you're having trouble accessing that file, you might try renaming it via the 8.3 filename. Use Tab completion to get the long filename, then press Control-A for the short.
 
After a fresh reboot.....

D:\Bad_Files\JPG_001]copy "02kσtYukiA01.jpg" 02KTYU~1.JPG
D:\Bad_Files\JPG_001\02kσtYukiA01.jpg => D:\Bad_Files\JPG_001\02KTYU~1.JPG
TCC: (Sys) The process cannot access the file because it is being used by another process.

0 files copied 1 failed
----- Original Message -----
From: Charles Dye
To: [email protected]
Sent: Monday, September 26, 2011 09:23 PM
Subject: RE: [Plugins-t-3242] Re: FixNames problem?


Quote:
Originally Posted by Charles G
it's on a NTFS volume. The snipet of code that has the error is:

I'm wondering whether that mystery character really is character #963, or whether it's something else that just gets 'translated' to that value. Like say maybe character 229, which was the lowercase sigma in ye olde IBM PC character set, and was used to mark deleted files on FAT volumes; that might cause weird behavior...?

If you're having trouble accessing that file, you might try renaming it via the 8.3 filename. Use Tab completion to get the long filename, then press Control-A for the short.
 
From: Charles G
| After a fresh reboot.....
|
| D:\Bad_Files\JPG_001]copy "02kσtYukiA01.jpg" 02KTYU~1.JPG
| D:\Bad_Files\JPG_001\02kσtYukiA01.jpg =>
| D:\Bad_Files\JPG_001\02KTYU~1.JPG
| TCC: (Sys) The process cannot access the file because it is being
| used by another process.
|
| 0 files copied 1 failed

I think you misunderstood Charles Dye' post. The above failed because the target file was the same as the source. He wanted you to RENAME the file to some simple name, other than the SFN (8.3 name) already assigned to it. He suggested that you obtain the existing SFN of the file (because of the problems with the LFN), and use it to rename the file. However, that may not have worked anyway. I suggest the following steps:

1/ make the directory where the problem file is your default
2/ enter the command (assuming COPY is the internal command, not an alias) but do not execute it:

copy /md # \temp\bad_name.jpg

3/ make sure command line editing is in INSERT mode
4/ move the cursor on the number sign (#), delete it (it was just a place marker) and press TAB until the name of the problem file is in the command line
5/ use ctrl-A to convert the command line to using SFN, and execute it.

This ought to create a copy of the file in the \TEMP directory of the same drive, under the name BAD_NAME.JPG (it will be all capitals because of the ctrl-A). That copy should now be fully accessible.

Alternately, if your goal was to MOVE the file to a different directory, use the MOVE command instead of the COPY command above/
--
HTH, Steve
 
in TCC v13 - current build...

[D:\Bad_Files\JPG_001]copy /md 02KTYU~1.JPG temp\bad_file.jpg
TCC: (Sys) The system cannot find the file specified.
"D:\Bad_Files\JPG_001\02KTYU~1.JPG"

0 files copied
----- Original Message -----
From: Steve Fabian
To: [email protected]
Sent: Monday, September 26, 2011 11:05 PM
Subject: RE: [Plugins-t-3242] Re: FixNames problem?


From: Charles G
| After a fresh reboot.....
|
| D:\Bad_Files\JPG_001]copy "02kÏftYukiA01.jpg" 02KTYU~1.JPG
| D:\Bad_Files\JPG_001\02kÏftYukiA01.jpg =>
| D:\Bad_Files\JPG_001\02KTYU~1.JPG
| TCC: (Sys) The process cannot access the file because it is being
| used by another process.
|
| 0 files copied 1 failed

I think you misunderstood Charles Dye' post. The above failed because the target file was the same as the source. He wanted you to RENAME the file to some simple name, other than the SFN (8.3 name) already assigned to it. He suggested that you obtain the existing SFN of the file (because of the problems with the LFN), and use it to rename the file. However, that may not have worked anyway. I suggest the following steps:

1/ make the directory where the problem file is your default
2/ enter the command (assuming COPY is the internal command, not an alias) but do not execute it:

copy /md # \temp\bad_name.jpg

3/ make sure command line editing is in INSERT mode
4/ move the cursor on the number sign (#), delete it (it was just a place marker) and press TAB until the name of the problem file is in the command line
5/ use ctrl-A to convert the command line to using SFN, and execute it.

This ought to create a copy of the file in the \TEMP directory of the same drive, under the name BAD_NAME.JPG (it will be all capitals because of the ctrl-A). That copy should now be fully accessible.

Alternately, if your goal was to MOVE the file to a different directory, use the MOVE command instead of the COPY command above/
--
HTH, Steve
 
Any further thoughts?
----- Original Message -----
From: Charles G
To: [email protected]
Sent: Monday, September 26, 2011 11:50 PM
Subject: RE: [Plugins-t-3242] Re: FixNames problem?


in TCC v13 - current build...

[D:\Bad_Files\JPG_001]copy /md 02KTYU~1.JPG temp\bad_file.jpg
TCC: (Sys) The system cannot find the file specified.
"D:\Bad_Files\JPG_001\02KTYU~1.JPG"

0 files copied
----- Original Message -----
From: Steve Fabian
To: [email protected]
Sent: Monday, September 26, 2011 11:05 PM
Subject: RE: [Plugins-t-3242] Re: FixNames problem?


From: Charles G
| After a fresh reboot.....
|
| D:\Bad_Files\JPG_001]copy "02kÏftYukiA01.jpg" 02KTYU~1.JPG
| D:\Bad_Files\JPG_001\02kÏftYukiA01.jpg =>
| D:\Bad_Files\JPG_001\02KTYU~1.JPG
| TCC: (Sys) The process cannot access the file because it is being
| used by another process.
|
| 0 files copied 1 failed

I think you misunderstood Charles Dye' post. The above failed because the target file was the same as the source. He wanted you to RENAME the file to some simple name, other than the SFN (8.3 name) already assigned to it. He suggested that you obtain the existing SFN of the file (because of the problems with the LFN), and use it to rename the file. However, that may not have worked anyway. I suggest the following steps:

1/ make the directory where the problem file is your default
2/ enter the command (assuming COPY is the internal command, not an alias) but do not execute it:

copy /md # \temp\bad_name.jpg

3/ make sure command line editing is in INSERT mode
4/ move the cursor on the number sign (#), delete it (it was just a place marker) and press TAB until the name of the problem file is in the command line
5/ use ctrl-A to convert the command line to using SFN, and execute it.

This ought to create a copy of the file in the \TEMP directory of the same drive, under the name BAD_NAME.JPG (it will be all capitals because of the ctrl-A). That copy should now be fully accessible.

Alternately, if your goal was to MOVE the file to a different directory, use the MOVE command instead of the COPY command above/
--
HTH, Steve
 
I opened CMD and copied the full name to 1.jpg - which worked great. CMD uses Raster fonts - wondering if TCC isn't seeing the special char.
----- Original Message -----
From: Charles Dye
To: [email protected]
Sent: Wednesday, September 28, 2011 05:14 PM
Subject: RE: [Plugins-t-3242] Re: FixNames problem?


Quote:
Originally Posted by Charles G
Any further thoughts?

Open a copy of CMD.EXE -- not TCC -- and try renaming the troublesome file using its short filename. (DIR /X shows SFNs.)

If that doesn't work, then maybe CHKDSK /F ...?
 
I opened CMD and copied the full name to 1.jpg - which worked great. CMD uses Raster fonts - wondering if TCC isn't seeing the special char.

A little feature that I'd forgotten about: If you pass a short filename to an internal command, TCC internally converts it to the equivalent long filename. Which is pretty cool 99% of the time -- but on the rare occasion when the long filename is broken, it bites you. To actually manipulate files via SFN, you have to use CMD....
 
CMD uses Raster fonts - wondering if TCC isn't seeing the special char.

CMD uses whatever font the console window is using (just like TCC). Typically that's "Raster Fonts", but you can change it to a TrueType font if you like. Most versions of Windows include either Lucida Console or Consolas in the console fonts list, and you can add others with a registry tweak.
 
With TCC and passing the LFN it wasn't working. Don't think the SFN/LFN had anyhting to do with it not COPYing. Just don't understand why CMD works and TCC doesn't using the LFN....
----- Original Message -----
From: Charles Dye
To: [email protected]
Sent: Wednesday, September 28, 2011 06:43 PM
Subject: RE: [Plugins-t-3242] Re: FixNames problem?


Quote:
Originally Posted by Charles G
I opened CMD and copied the full name to 1.jpg - which worked great. CMD uses Raster fonts - wondering if TCC isn't seeing the special char.

A little feature that I'd forgotten about: If you pass a short filename to an internal command, TCC internally converts it to the equivalent long filename. Which is pretty cool 99% of the time -- but on the rare occasion when the long filename is broken, it bites you. To actually manipulate files via SFN, you have to use CMD....
 
What is the reg key and the TCMD/TCC INI entry to check for what I have where?
----- Original Message -----
From: Charles Dye
To: [email protected]
Sent: Wednesday, September 28, 2011 06:48 PM
Subject: RE: [Plugins-t-3242] Re: FixNames problem?


Quote:
Originally Posted by Charles G
CMD uses Raster fonts - wondering if TCC isn't seeing the special char.

CMD uses whatever font the console window is using (just like TCC). Typically that's "Raster Fonts", but you can change it to a TrueType font if you like. Most versions of Windows include either Lucida Console or Consolas in the console fonts list, and you can add others with a registry tweak.
 
Back
Top