Handling paths of length > 260 in Tcl on Windows
ChrisR
Windows, ones that (although they exceed Explorer's hard limit of 255)
may be nearly-arbitrary in length.
This MSDN article mentions the issue:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/fileio/fs/naming_a_file.asp
Basically, right now it looks like the normalized filenames in the Tcl
file libraries are normalized as "<drive>:/<path... >" whereas for this
functionality to work, at the very least, the file and I/O commands
would also have to accept "\\?\<drive>:\<path...>
Is there a workaround for this? I can't be the first person who has
needed this functionality...
Donald Arseneau
> As the subject suggests, I need to be able to handle long pathnames on
> Windows, ones that (although they exceed Explorer's hard limit of 255)
> Is there a workaround for this? I can't be the first person who has
> needed this functionality...
It was discussed here not long ago (months) -- I remember it even though
I wasn't interested. Check with google/groups.
--
Donald Arseneau as...@triumf.ca
ChrisR
are far more in the way of questions about filename/path-part lengths
than there are about this issue.
Does anyone else have a better idea of the location of these messages?
Uwe Klein
Are there Pathes beyond 255 Characters?
Hitches, opinions, religion on windows pathlength limitations:
http://sourceforge.net/mailarchive/forum.php?thread_id=9833529&forum_id=3854
http://sourceforge.net/mailarchive/forum.php?thread_id=9833535&forum_id=3854
google-groups is excused ;-)
uwe
Benjamin Riefenstahl
"ChrisR" writes:
> the file and I/O commands would also have to accept
> "\\?\<drive>:\<path...>
I still suggest that you file a bug report on the bug tracker that
calls like this do not work currently:
glob {\\?\c:\tmp\*}
open {\\?\c:\tmp\testfile}
If those and similar functions were made to work with the non-limiting
syntax, the rest could easily be done on the application level.
benny
Donald Arseneau
> google-groups is excused ;-)
Sorry for the misdirection.
--
Donald Arseneau as...@triumf.ca
Chris R
hope of seeing this, say, next week ;)
A man can dream...
Chris R
yet resolved.
It might be worth adding that interacting with large, complex Java
projects using Tcl as a tool platform requires this kind of support, as
well, as Java uses the extended filename APIs under the Win32 hood, and
some IBM WebSphere tools, as well as Webservice stub generators are all
capable of generating filenames with this problem on any organized
project structure. The varying part of some of those filenames and
paths (the parts that are tool-generated) can, and do, hi 240
characters, forcing us to keep our projects in D:\ if we want them to
be buildable, using Tcl-based tools. This is not a good thing, for
obvious reasons.
Anyway...
I'd like to see this support added in to the core, assuming it's
possible to just pass the names to the underlying routines.
Michael Schlenker
> That is exactly what I want to see happen. Now, if only there were a
> hope of seeing this, say, next week ;)
>
> A man can dream...
>
week, otherwise its probably dreaming. If its important enough for you,
fix it and publish the patch.
There isn't even a feature request, bug report or anything related to
this in the sourceforge tracker, as far as i can see. That would be
absolute minimum to get anyone to do something, or at least remeber this
issue if something is done on the filesystem code for other reasons.
Depending on the amount of changes needed, writing a TIP and providing a
sample implementation patch for this would be the next step for someone
needing this enough.
Michael
Donal K. Fellows
> Depending on the amount of changes needed, writing a TIP and providing a
> sample implementation patch for this would be the next step for someone
> needing this enough.
Offhand, it's probably possible to fix this without a TIP. It's just
"making filenames work right", and I suspect it doesn't need an API
change (which would force a TIP). In any case, first steps are "make
sure there's a bug report" and "write a fix". :-)
Donal.
Chris R
I've been looking at the code that handles this, though, and I'll be
the first to admit, I don't really know *where* to start fixing this.
I suspect that it's partially in the file normalization code (which
seems to strip out the prefix if it finds it) and partially
"elsewhere", where "elsewhere" is some part of the windows code that
I'm not able to locate.
There is one issue with this, though -- what *should* the results of a
file normalize be, given this consideration? The two forms (with and
without \\?\ prefix) are equivalent to the API, even if not all
frontend applications support them.
Chris R
TclpNativeToNormalized, the prefixes \\?\ and \??\ are stripped from a
pathname. One suspects that tis is probably not the only effect that
this'll have.
I'm not quite clear on where and how pathname normalization occurs. We
use Tcl rather extensively, so it's pretty important that it not
regress if a change like this is made.
Benjamin Riefenstahl
"Chris R" writes:
> There is one issue with this, though -- what *should* the results of
> a file normalize be,
[file normalize] for normal file names should not change IMO.
> The two forms (with and without \\?\ prefix) are equivalent to the
> API, even if not all frontend applications support them.
No they are not. Opening "\\?\c:\tmp\com1" will create a file "com1"
which the user will than be unable to delete. Opening "c:\tmp\com1"
will open the first serial port. There are probably other
incompatibilities and Microsoft might introduce more. Also "\\?\..."
doesn't mean anything to W9x/Me.
Tcl handles UNC paths fine right now. Last time I tested this, the
error result for opening \\?\c:\tmp\... took some time, which hints to
me that some code probably tried to resolve the host "?". That would
run into a timeout, because that host doesn't exist, of course.
From testing it seems that the code already handles ".", which is used
for devices. I think we might just need a special case in the code
that handles UNC paths for the special hostname "?".
benny
Donald Arseneau
However, do you really want to have to type the "\\?\" (or "\\\\?\\")
prefix?
What about having the "nativename" code detect a long file name and
insert the prefix automatically?
--
Donald Arseneau as...@triumf.ca
vince....@gmail.com
> However, do you really want to have to type the "\\?\" (or "\\\\?\\")
> prefix?
>
> What about having the "nativename" code detect a long file name and
> insert the prefix automatically?
That would be my preferred approach. It should "just work", as with
most other stuff in Tcl!
This would mean changing the code in
tclWinFile.c:TclNativeCreateNativeRep(), to add those prefixes (and
then to check that all uses of the resulting ClientData inside Tcl are
to win32 APIs that allow long paths, and if not to trim off the prefix
when calling those old APIs)
Vince.
Donald Arseneau
> then to check that all uses of the resulting ClientData inside Tcl are
> to win32 APIs that allow long paths, and if not to trim off the prefix
> when calling those old APIs)
Oh dear! That sounds onerous.
Are there any old APIs that would not handle the prefix, but *would*
correctly handle paths of long length?
If, as I expect, not, then Tcl could just leave the prefix, as there is
bound to be an error anyway. However, the error from an unexpected prefix
could be mystifying to the user.
--
Donald Arseneau as...@triumf.ca