# Path length for files on NTFS - Thread: https://externals.io/message/42656 - Original archive: https://news-web.php.net/php.internals/42656 - Started by Karsten Dambekalns on 2009-01-16T10:42:46+00:00 - Messages: 10 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #42656 — Karsten Dambekalns — 2009-01-16T10:42:46+00:00 URL: https://externals.io/message/42656#42656 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. :) --- ## #42659 — Pierre Joye — 2009-01-16T13:33:57+00:00 URL: https://externals.io/message/42656#42659 · In reply to: #42656 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 http://blog.thepimp.net | http://www.libgd.org --- ## #42660 — Karsten Dambekalns — 2009-01-16T14:53:42+00:00 URL: https://externals.io/message/42656#42660 · In reply to: #42659 Hi Pierre. > > […] > > 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 --- ## #42661 — Pierre Joye — 2009-01-16T16:03:08+00:00 URL: https://externals.io/message/42656#42661 · In reply to: #42660 > Hi Pierre. > > > > […] > > In what way? > > > […] > > Right. One FAT volume could wreck it all. > > > […] > > Sounds bad. I just cannot believe it is still easily possible to "break" a > machine by simply using FAT32 under Vista. Phew. > > > […] > > 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 http://blog.thepimp.net | http://www.libgd.org --- ## #42662 — Pierre Joye — 2009-01-16T16:12:20+00:00 URL: https://externals.io/message/42656#42662 · In reply to: #42661 > > […] > > 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 http://blog.thepimp.net | http://www.libgd.org --- ## #42663 — Karsten Dambekalns — 2009-01-16T17:27:44+00:00 URL: https://externals.io/message/42656#42663 · In reply to: #42662 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_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 --- ## #42665 — Pierre Joye — 2009-01-16T17:42:28+00:00 URL: https://externals.io/message/42656#42665 · In reply to: #42663 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_MessageQueuePersistenceAspect > > For 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. > > […] > > 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 http://blog.thepimp.net | http://www.libgd.org --- ## #42667 — crrodriguez@suse.de — 2009-01-16T18:08:03+00:00 URL: https://externals.io/message/42656#42667 · In reply to: #42665 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/ --- ## #42669 — Pierre Joye — 2009-01-16T22:36:31+00:00 URL: https://externals.io/message/42656#42669 · In reply to: #42667 > Pierre Joye escribió: > > > […] > > can 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 http://blog.thepimp.net | http://www.libgd.org --- ## #42682 — Kalle Sommer Nielsen — 2009-01-18T12:21:00+00:00 URL: https://externals.io/message/42656#42682 · In reply to: #42665 2009/1/16 Pierre Joye : > hi > > > > > […] > > 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? > > > […] > > It is system dependent and there is many values. > > > […] > > 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) :) > > > […] > > 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