Hi All,

When you are trying to delete a a file
that has a very long file & path name ,
from the cmd line, powershell, your unlink
command within your compiler, and it just
wont delete. And you get the following
the returned error message of
"File not found"
And no you did not misspell it it.

But you can delete it with Windows
Explorer, here is what is going on.

Windows has two maximum file & path names
character lengths.

The default is called "MAX_PATH" and it is
260 characters long. Del and friends
makes an API (Application Program Interface)
call to DeleteFileA (UTF8) or DeleteFileW
(UTF16). The call lops off the extra
characters above MAX_PATH, so you
are trying to delete a different file name,
which is why the File Not Found error.

The solution is to use the other maximum,
non-default path limit of 32,767 characters.

To do this, prepend \\?\ to your path/file name.
Windows Explorer does this automatically
for you which is why it works. You can also
prepend this to shorter files without issue
(it is probably shower though.)

Some examples from the Raku (Perl6) module
I wrote to handle this. It returns OK if
the file got deleted or the error message
if not:

The Q[...] means a direct quote.("" does not work
so when used from the command line with Raku.)

Current directory path:
echo abc > eraseme.txt && raku -I. -e "use NativeDelete
:ApiDeleteFile; say ApiDeleteFile( Q[eraseme.txt] )" && type eraseme.txt
OK
The system cannot find the file specified.

Looking for the wrong file:
echo abc > eraseme.txt && raku -I. -e "use NativeDelete
:ApiDeleteFile; say ApiDeleteFile( Q[eraseme2.txt] )" && type eraseme.txt
The system cannot find the file specified.
abc

Long path from hell:
raku -I. -e "use NativeDelete :ApiDeleteFile; say ApiDeleteFile(
Q[\\?\D:\MyDocsBackup\backup2\Mozilla 2024-04-15 21;14;31
(Full)\Firefox\Profiles\pj0elosu.default-release\storage\default\https+++505991220932649.webpush.freshchat.com^partitionKey=%28https%2Cbid13.com%29\cache\morgue\114\{7cccd5e9-a7aa-4349-a2e9-569baf007272}.final]
);"
OK

HTH,
-T

On 4/21/2024 11:16 PM, T wrote:
> Hi All,
>
> When you are trying to delete a a file
> that has a very long file & path name ,
> from the cmd line, powershell, your unlink
> command within your compiler, and it just
> wont delete.  And you get the following
> the returned error message of
>     "File not found"
> And no you did not misspell it it.
>
> But you can delete it with Windows
> Explorer, here is what is going on.
>
> Windows has two maximum file & path names
> character lengths.
>
> The default is called "MAX_PATH" and it is
> 260 characters long.  Del and friends
> makes an API (Application Program Interface)
> call to DeleteFileA (UTF8) or DeleteFileW
> (UTF16).  The call lops off the extra
> characters above MAX_PATH, so you
> are trying to delete a different file name,
> which is why the File Not Found error.
>
> The solution is to use the other maximum,
> non-default path limit of 32,767 characters.
>
> To do this, prepend \\?\ to your path/file name.
> Windows Explorer does this automatically
> for you which is why it works.  You can also
> prepend this to shorter files without issue
> (it is probably shower though.)
>
> Some examples from the Raku (Perl6) module
> I wrote to handle this.  It returns OK if
> the file got deleted or the error message
> if not:
>
> The Q[...] means a direct quote.("" does not work
> so when used from the command line with Raku.)
>
> Current directory path:
>       echo abc > eraseme.txt && raku -I. -e "use NativeDelete :ApiDeleteFile; say ApiDeleteFile( Q[eraseme.txt] )" && type eraseme.txt
>       OK
>       The system cannot find the file specified.
>
> Looking for the wrong file:
>       echo abc > eraseme.txt && raku -I. -e "use NativeDelete :ApiDeleteFile; say ApiDeleteFile( Q[eraseme2.txt] )" && type eraseme.txt
>       The system cannot find the file specified.
>       abc
>
> Long path from hell:
>       raku -I. -e "use NativeDelete :ApiDeleteFile; say ApiDeleteFile( Q[\\?\D:\MyDocsBackup\backup2\Mozilla 2024-04-15 21;14;31 (Full)\Firefox\Profiles\pj0elosu.default-release\storage\default\https+++505991220932649.webpush.freshchat.com^partitionKey=%28https%2Cbid13.com%29\cache\morgue\114\{7cccd5e9-a7aa-4349-a2e9-569baf007272}.final] );"
>       OK
>
> HTH,
> -T

In the backwoods where I live, permissions are likely to be the reason a file
cannot be removed.

NTFS New Compression is a close second. This should be
done as soon as humanly possible after an installation.

fsutil behavior set disablecompression 1 # disable New Compression

gpedit
computer configuration\Administrative template\system\filesystem\ntfs\Do not allow compression

A tablet with 32GB of storage, needs crutches like New Compression, for its
survival. Desktops with gobs of storage, this detritus should stay switched off.
That setting applies to all storage devices on the computer.

Microsoft has created filenames in C: (in a couple of areas related to products
you might pay for), where the character set was "unrepresentable". Attempting
to type or paste the wacky symbols simply will not work. But some manager at
MS must have given the Intern a kick in the bum for that, and the obnoxious structure
disappeared. It might have been considered to be an "exotic namespace". I think
CleanMgr could remove it, but you couldn't actually tell it to remove a specific
item, and only certain situations made removal possible ("Windows.old").

The "Length Bug" was removed some time ago. I could arrange a file to have
a certain length ("260"), it could not be removed in File Explorer, but a Perl rename()
could shorten the name enough to allow regular deletion. At a later point,
that rough spot was removed.

Paul

On Mon, 22 Apr 2024 00:51:12 -0400, Paul <nospam@needed.invalid>
wrote:

>On 4/21/2024 11:16 PM, T wrote:
>> Hi All,

<<snipped>>

>Microsoft has created filenames in C: (in a couple of areas related to products
>you might pay for), where the character set was "unrepresentable". Attempting
>to type or paste the wacky symbols simply will not work.

I don't understand what would go wrong with a paste but I'm quite
prepared to believe that it did. Computers are often very strange.

>But some manager at
>MS must have given the Intern a kick in the bum for that, and the obnoxious structure
>disappeared. It might have been considered to be an "exotic namespace". I think
>CleanMgr could remove it, but you couldn't actually tell it to remove a specific
>item, and only certain situations made removal possible ("Windows.old").

I have found, on occasion, that trying to move web-pages with
question marks in their names ("Is this the end of the world?.html" or
similar news pages kept for short periods for reference) from a *Nix
based OS like MacOS to Win-7 sometimes leaves files on the Win-7 box
that the Win-7 OS can't delete. It treats the "?" as a wildcard unless
you can force an escape on it.

>
>The "Length Bug" was removed some time ago.

Really? It's still there in Win-7, though I probably shouldn't be
surprised at this as Win-7 is obsolete.

I tried to move stuff from my MBP to archive on an external drive
hanging off of my Win-7 box but the Windows OS complained that some of
the files had names that were too long. Possibly due to the tree
length of the paths.

I'm still trying to think of a work-around.

There's far too many files to manually shorten the paths and names so
it needs to be an automatic magical solution. One thing I could do is
to drain the lower branches of the tree into upper ones and so shorten
the path-names but I don't know whether that would work on the Win-7
box.

>I could arrange a file to have
>a certain length ("260"), it could not be removed in File Explorer, but a Perl rename()
>could shorten the name enough to allow regular deletion.

I don't do Perl, yet. Probably never will. I've no incentive to learn
it.

> At a later point,
>that rough spot was removed.

In Win-10 and 11 I suppose?

J.

>
> Paul

On Tue, 23 Apr 2024 00:09:00 +0100, John <Man@the.keyboard> wrote:

>On Mon, 22 Apr 2024 00:51:12 -0400, Paul <nospam@needed.invalid>
>wrote:
>
>>The "Length Bug" was removed some time ago.
>
> Really? It's still there in Win-7, though I probably shouldn't be
>surprised at this as Win-7 is obsolete.

If it's what I'm thinking of, I don't think it's actually a bug, but the 'path
length' issue is still present in Win 10, just as it was in each of the earlier
Windows versions. I remember running into it in Win 95 and every version since
then. I skipped Vista, but I'm sure it's there, as well.

Create a file, let's say a.txt to keep it simple. Put it into a folder. Put that
folder into a folder. And so on. You can repeat that last step as often as you
like, and there will never be a warning that you've exceeded the default max 260
character path length. You'll only be warned when you try to delete or cut that
deeply nested file. At least one workaround is easy, though.

> I tried to move stuff from my MBP to archive on an external drive
>hanging off of my Win-7 box but the Windows OS complained that some of
>the files had names that were too long. Possibly due to the tree
>length of the paths.

I create a temp folder in the volume root and then I cut/paste a folder (and of
course its subfolders) from the problematic branch. With the total path
temporarily shortened, deleting or cutting can proceed normally. If I'm cutting,
then I simply paste it back where it belongs. I have an mp3 library that must
have at least a thousand of those paths that exceed the max limit. In normal
everyday use, they don't cause any problems.

As someone else mentioned, you can also disable the 260 character max path, but
I don't bother.

> There's far too many files to manually shorten the paths and names so
>it needs to be an automatic magical solution. One thing I could do is
>to drain the lower branches of the tree into upper ones and so shorten
>the path-names but I don't know whether that would work on the Win-7
>box.

I almost never temp move individual files, preferring instead to move entire
folders and their subfolders and files. That way, it's easy to put things back
where they belong afterwards.

>> At a later point,
>>that rough spot was removed.
>
> In Win-10 and 11 I suppose?

Not 10 and probably not 11.

On Tue, 23 Apr 2024 23:16:00 -0500, Char Jackson <none@none.invalid>
wrote:

<snipped>>
>
>I almost never temp move individual files, preferring instead to move entire
>folders and their subfolders and files. That way, it's easy to put things back
>where they belong afterwards.

The only time I seem to move stuff is to archive it. Bar that, files
seem to magically accumulate. :)

>
<<snipped>>

Thank you.

J.