Support for path+filename > MAX_PATH (on NTFS)

[demb]

Hi All (especially Author ),
Is there a plan to add such support? NTFS itself allows paths up to 32k chars (btw. each "piece" in path - /folder/ or /filename - still has to be up to 256 long) - only almost all programs, including windows explorer, use old/common API functions that cannot handle long paths. Microsoft's advice is to use third party software written with calls to Unicode versions of API functions.
I think it's worth to improve TC because:

• * a lot of resources have very long paths, and regular users in don't care about it (especially in companies ),
  * adding it should be relatively simple - that new functions are identical to old,
  * from my little research, there are very, very small number of such programs - it would make TC more exclusive ,
  * if there is no way to put this feature in runtime options (to stay compatible with non NTFS systems) such TC version can be compiled individually - and published with "for experienced users" remark or sth,
  * maybe it could be a filesystem plug-in?

thanks for viewing/replying, regards
adam

[sqa_wizard]

Well, an interesting idea, indeed.

But IMHO this makes not much sense.

As you already said:

... from my little research, there are very, very small number of such program ...

Even if TC could handle long paths, the files there cannot be handled by other programs:
- you cannot start those programs by a windows shortcut (explorer doesn't support)
- the program itself may not run either (cannot find its own DLLs or data in its own directory
- you cannot open documents with other programs than TC

Where is the advantage to place files at commonly not supported locations ?

[demb]

hi sga_wizard,
Yes, you are completely right - there is no smallest sense to place files in deep path, because of all you said about and more. But look from admin sight - like my situation - there is a server with many shares, clients map them to letter, so they see and work with "shorter" path. They fill network drives with something like this for example:
W:\904900-123 project - water treatment for city X\2006-01-01 Proposal\Phase I - revised version\Technical Part\Executing project\sended and approved\Main buildings\ ... \ (and here copy of CD with many folders). One project contains thousands of files, so names have to be explanational eq. "STD 825 Adjustment of level transmitter - Silo for dried sludge 30m3.dwg" - so long pathes are my day by day experience. From their sight everything is ok, but when I want to copy/move/backup files I'm encountering problems - that few letters from server's local folder name causes unreadability. And that's all - the only thing I need is nice tool without filename restrictions.
Uff, I will write smaller posts in future, sorry

[Sheepdog]

What would you think of a feature that TC will ask you at those inaccessible paths to 'subst' them to a drive-letter? Would this be of any help?

sheepdog

[demb]

hi Sheepdog,
It is some solution, but in "mass usage" very uncomfortably. I'm doing now in similar way - mounting server's own share to letter or temporalily moving part of folder tree to root. But it needs frequent re-mapping (there are many shares, I'm out of free letters) and remembering it all - and it is dangerous - mistakes can happen (not once ). Moving is impossible when people work on files. Of course I'm dealing with it, but just pressing F5 would be so nice...

[SQUIRE]

Hmm, what an fascinating problem! Just a few thoughts:

[1] You could free up drive letters by mounting volumes to a named directory without using drive letters by using a DOS window and the mountvol command. See here for some useful background on volume mount points.

[2] If these long file paths lie within the same volume, you could perhaps establish shorter-named hard links to them? The path then does not become an issue because by creating a hard link, you ask the system to create a virtual shortcut to a file. By creating hard links you can:

Use the same file name as the original file but appear in different folders.

Use different file names from the original file but appear in the same folder.

Use different file names from the original file and appear in different folders.

Because a hard link is a directory entry for a file, an application can modify a file by using any of its hard links i.e. copy, move, etc.
Applications that use any other hard link can detect the changes.
However, directory entries for hard links are updated only when a user accesses a file by using the hard link. For example, if a user opens and modifies a file by using its hard link, and the size of the original file changes, the hard link that is used to access the file also shows the new size.

[3] See this last post for a nice Unicode utility that will clone a whole directory tree with hard links if you want.

Note the limitation: HardLinks can only be made within the same NTFS volume, and can not span across NTFS volumes.

[4] I haven't tried any really deep paths beyond the limit so I don't know what the snags are, if any. You'll have to experiment by yourself, sorry!

Hope this is of some use. If you find a solution, please share it with us.