work with long (actually very long) file/dir names.

[_hunter]

Greetings...

On My work I sometimes should work within very long dirs (more then 260 symbols total length). Unfortunately TC cant't handle such pathes. So I have to use our (developed by our firm) utility to veew/edit/delete those files. But it's not very comfortable

So, maybe, You can add support of such pathes to TC?

Best regards...

[_hunter]

thanks. it is it...

[ghisler(Author)]

There is some hope, because TC 7.5 will use 1024 character Unicode names internally to store file names. Long name support has already been added to the Delete function, and will probably be added also to all other file functions.

[Lefteous]

2ghisler(Author)
Did you encounter any compatibility problems with shell functions where Microsoft doesn't guarantee that they support more than 259 characters?

[ghisler(Author)]

I haven't tested any shell functions yet, but functions like DeleteFile will just fail except when using the special prefix...

[Lefteous]

2ghisler(Author)

I'm referring to this hint in the MSDN.

http://msdn2.microsoft.com/en-us/library/aa365247.aspx

Section "Maximum path length"

The shell and the file system have different requirements. It is possible to create a path with the API that the shell UI cannot handle.

[m^2]

Shell functions aren't (at least not all) compatible with long paths.
http://msdn2.microsoft.com/en-us/library/bb759795.aspx

SHFileOperation fails on any path prefixed with "\\?\".

[gigaman]

I haven't tested any shell functions yet, but functions like DeleteFile will just fail except when using the special prefix...

Any function will fail for long paths without the special prefix - that's why the prefix is there, isn't it?

[m^2]

Sorry for late reply, but I missed one thing till now...Why 1024 characters instead of 32767? I agree that very few need more, but it would be good to have compatibility with all long paths anyway.

[ghisler(Author)]

Because it would cause a huge memory usage for almost no reason...

[m^2]

How many paths does TC store normally? It's additional 62KB/path. If it's like 1 path/tab+(some constant <10)+paths stored for a short period, IMO it would have absolutely no significance.
If it's much bigger number, maybe variable size strings would be a good solution?

[HolgerK]

How many paths does TC store normally?

A lot:
<Ctrl+B> Branch view (with subdirs)
even more:
<ALT+F7>+" *.* all drives"+ Feed to listbox

Let's say you get 2*10^6 results.
Thats about 122 MiByte (2*10^6*2*32/1024/1024).
With 10 million files you are running in trouble under Win95.

Kind regards,
Holger (using 2 GiByte RAM)

Edit: Too late in the evening.
Forgot to multiply with (32) KiByte
so the correct values for 2 million paths is 122 GiByte.
That's even a lot of bits if you use an actual 64Bit System...

[Lefteous]

As path components can be only 255 characters long a full path can be stored as a list of path components. Now imagine that you assign a number to each directory component name. Each number could be the index in an suitable container. At the end you only need to store each path as a list of numbers. When you need the names behind the numbers you just need to access the array which stores the numbers.
This will save a lot of memory - especially when not all paths are completely different...

[HolgerK]

... Each number could be the index in an suitable container. At the end you only need to store each path as an array of numbers. ...

That's a clever solution!

Kind regards,
Holger

[gigaman]

Maybe I'm missing something obvious - but why not use dynamic strings (i.e. with a size allocated according to current content length) - especially if memory usage should be an issue?
Since most paths are short anyway (shorter than 260 characters), it would save memory almost always...