Hi everyone.
I posted this on php.windows a two days ago without a response. Maybe
someone here can help me.
Recently someone using our software told us about problems with
generated filenames being too long. I did some research on the net and
some quick tests on Vista Business, and it seems there is indeed still a
problem.
While NTFS supports path lengths of up to 32k characters, "most
software" still supports only 255 (or 260 on Vista) character filenames.
Since that includes the full path, we run into this problem with file
based caching filenames.
Since there are ways to use long(er) filenames, does anyone know if this
planned for PHP? Should it work? Is this a problem others also see?
Kind regards,
Karsten
PS: Those questions may sound stupid, but coming from a Linux/Mac
background this is simply a completely new problem to me. :)
hi,
Recently someone using our software told us about problems with generated
filenames being too long. I did some research on the net and some quick
tests on Vista Business, and it seems there is indeed still a problem.While NTFS supports path lengths of up to 32k characters,
By the way, this limit is approximative.
"most software"
still supports only 255 (or 260 on Vista) character filenames. Since that
includes the full path, we run into this problem with file based caching
filenames.Since there are ways to use long(er) filenames, does anyone know if this
planned for PHP? Should it work? Is this a problem others also see?
There is no plan yet to increase this value. The main problem is that
the maximum length of a path is volume dependent, not system
dependent.
To support longer path, it would mean to check the volume information
for each file operation (once per volume, cache it and reuse it) as
well as using dymamic allocation for for the filename itself, in many
places. I'm not sure it is worth the effort.
You can use a hash as filename, as a temporary workaround.
Cheers,
Pierre
Hi Pierre.
While NTFS supports path lengths of up to 32k characters,
By the way, this limit is approximative.
In what way?
There is no plan yet to increase this value. The main problem is that
the maximum length of a path is volume dependent, not system
dependent.
Right. One FAT volume could wreck it all.
To support longer path, it would mean to check the volume information
for each file operation (once per volume, cache it and reuse it) as
well as using dymamic allocation for for the filename itself, in many
places. I'm not sure it is worth the effort.
Sounds bad. I just cannot believe it is still easily possible to "break"
a machine by simply using FAT32 under Vista. Phew.
You can use a hash as filename, as a temporary workaround.
Well, not really. Our names include some information, so hashing isn't
really an option. For now we'll probably just skip supporting Windows.
Regards,
Karsten
Hi Pierre.
While NTFS supports path lengths of up to 32k characters,
By the way, this limit is approximative.
In what way?
There is no plan yet to increase this value. The main problem is that
the maximum length of a path is volume dependent, not system
dependent.Right. One FAT volume could wreck it all.
To support longer path, it would mean to check the volume information
for each file operation (once per volume, cache it and reuse it) as
well as using dymamic allocation for for the filename itself, in many
places. I'm not sure it is worth the effort.Sounds bad. I just cannot believe it is still easily possible to "break" a
machine by simply using FAT32 under Vista. Phew.You can use a hash as filename, as a temporary workaround.
Well, not really. Our names include some information, so hashing isn't
really an option. For now we'll probably just skip supporting Windows.
The problem is exactly the same on any OS, only the size varies. The
limit is not higher either. What do you use as naming for your
entries?
--
Pierre
Well, not really. Our names include some information, so hashing isn't
really an option. For now we'll probably just skip supporting Windows.The problem is exactly the same on any OS, only the size varies. The
limit is not higher either. What do you use as naming for your
entries?
Btw, what do you do when the path len of the path where the cache is
stored is closed from MAXPATHLEN (PHP_MAXPATHLEN in userland)? Given
than MAXPATHLEN can be between 260 and 2048 (~), that' can happen
easily.
Cheers,
Pierre
Hi.
The problem is exactly the same on any OS, only the size varies. The
limit is not higher either. What do you use as naming for your
entries?
Oe example with 229 characters:
/Users/karsten/Sites/typo3v5/Data/Temporary/6e7991cd3e3f10e110df4a26825c1f8c/_www/Cache/Testing/Tags/%CLASS%F3_Widget_Persistence_MessageQueuePersistenceAspect/FLOW3_Reflection-F3_Widget_Persistence_MessageQueuePersistenceAspect
For deeper nested namespaces this will get longer, add some deeper
directory structure at the start and - bang.
Now, I never ran into problems with paths being too long for anything I
tried on Linux or Mac, so what limits exist? Admittedly I never thought
about that much. Given we live in a world of terabytes I'd expect names
to be virtually as long as I want. :)
Btw, what do you do when the path len of the path where the cache is
stored is closed from MAXPATHLEN (PHP_MAXPATHLEN in userland)? Given
than MAXPATHLEN can be between 260 and 2048 (~), that' can happen
easily.
Never heard of that constant, thanks for pointing it out. The
documentation doesn't explain it, is there some background information
available somewhere?
So, in the best case we hit the roof at ~2k? Good to know...
Thanks,
Karsten
hi
Oe example with 229 characters:
/Users/karsten/Sites/typo3v5/Data/Temporary/6e7991cd3e3f10e110df4a26825c1f8c/_www/Cache/Testing/Tags/%CLASS%F3_Widget_Persistence_MessageQueuePersistenceAspect/FLOW3_Reflection-F3_Widget_Persistence_MessageQueuePersistenceAspectFor deeper nested namespaces this will get longer, add some deeper directory
structure at the start and - bang.
With such naming, you are likely to hit this issue anyway, no matter
the OS. Think about one having his host directories in deeper level,
for example, or the hostnames use some lengthy values/names?
Now, I never ran into problems with paths being too long for anything I
tried on Linux or Mac, so what limits exist? Admittedly I never thought
about that much. Given we live in a world of terabytes I'd expect names to
be virtually as long as I want. :)
It is system dependent and there is many values.
Btw, what do you do when the path len of the path where the cache is
stored is closed from MAXPATHLEN (PHP_MAXPATHLEN in userland)? Given
than MAXPATHLEN can be between 260 and 2048 (~), that' can happen
easily.Never heard of that constant, thanks for pointing it out. The documentation
doesn't explain it, is there some background information available
somewhere?
it reflects the internal constant MAXPATHLEN, which is defined at
compile time (per os/system).
So, in the best case we hit the roof at ~2k? Good to know...
Keep in mind that the complete path has to fit in there, not only
the last part (your cache name). I think you should rethink a bit the
naming of your caching system, that'll save you some troubles soon
later.
About the 260 limit on windows, we may find an efficitent solution to
increase it in a safe way, but I don't have one at hand right now. I
have to think more about that and see what can be done for 5.3 (which
supports XP+ only, which means NTFS in the most cases).
Cheers,
Pierre
Pierre Joye escribió:
which is defined at
compile time
can also be obtained at runtime using pathconf(3)
--
"We have art in order not to die of the truth" - Friedrich Nietzsche
Cristian Rodríguez R.
Software Developer
Platform/OpenSUSE - Core Services
SUSE LINUX Products GmbH
Research & Development
http://www.opensuse.org/
Pierre Joye escribió:
which is defined at
compile timecan also be obtained at runtime using pathconf(3)
Yes, (and GetVolumeInfo on win), but then we have to allocate the path
instead of using static size, in many places.
Cheers,
Pierre
2009/1/16 Pierre Joye pierre.php@gmail.com:
hi
Oe example with 229 characters:
/Users/karsten/Sites/typo3v5/Data/Temporary/6e7991cd3e3f10e110df4a26825c1f8c/_www/Cache/Testing/Tags/%CLASS%F3_Widget_Persistence_MessageQueuePersistenceAspect/FLOW3_Reflection-F3_Widget_Persistence_MessageQueuePersistenceAspectFor deeper nested namespaces this will get longer, add some deeper directory
structure at the start and - bang.With such naming, you are likely to hit this issue anyway, no matter
the OS. Think about one having his host directories in deeper level,
for example, or the hostnames use some lengthy values/names?Now, I never ran into problems with paths being too long for anything I
tried on Linux or Mac, so what limits exist? Admittedly I never thought
about that much. Given we live in a world of terabytes I'd expect names to
be virtually as long as I want. :)It is system dependent and there is many values.
Btw, what do you do when the path len of the path where the cache is
stored is closed from MAXPATHLEN (PHP_MAXPATHLEN in userland)? Given
than MAXPATHLEN can be between 260 and 2048 (~), that' can happen
easily.Never heard of that constant, thanks for pointing it out. The documentation
doesn't explain it, is there some background information available
somewhere?it reflects the internal constant MAXPATHLEN, which is defined at
compile time (per os/system).
As of 5.3, the MAXPATHLEN constant is available in userland as
PHP_MAXPATHLEN btw (without having read the whole thread) :)
So, in the best case we hit the roof at ~2k? Good to know...
Keep in mind that the complete path has to fit in there, not only
the last part (your cache name). I think you should rethink a bit the
naming of your caching system, that'll save you some troubles soon
later.About the 260 limit on windows, we may find an efficitent solution to
increase it in a safe way, but I don't have one at hand right now. I
have to think more about that and see what can be done for 5.3 (which
supports XP+ only, which means NTFS in the most cases).Cheers,
Pierre
http://blog.thepimp.net | http://www.libgd.org
--
--
Kalle Sommer Nielsen