All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jeff Mahoney <jeffm@suse.com>
To: "Vladimir V. Saveliev" <vs@namesys.com>
Cc: "Xuân Baldauf"
	<xuan--2005.08.22--reiserfs-list--namesys.com@baldauf.org>,
	reiserfs-list@namesys.com
Subject: Re: REISERFS_MAX_NAME and ENAMETOOLONG
Date: Tue, 30 Aug 2005 03:01:59 -0400	[thread overview]
Message-ID: <43140467.8030704@suse.com> (raw)
In-Reply-To: <43099FFC.9000606@namesys.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Vladimir V. Saveliev wrote:
> Hello
> 
> Xuân Baldauf wrote:
>>Hello,
>>
>>when downloading something from java.sun.com (e.g.
>>http://javashoplm.sun.com/ECom/docs/Welcome.jsp?StoreId=22&PartDetailId=jdk-1.5.0-doc-oth-JPR&SiteId=JSC&TransactionId=noreg
>>), very long URLs are encountered. When trying to download using "wget",
>>wget tries to open a file with those long filenames, and fails with
>>ENAMETOOLONG (File name too long).
>>
>>I think that the limit is due to the REISERFS_MAX_NAME macro
>>(http://lxr.linux.no/source/include/linux/reiserfs_fs.h?v=2.6.10#L1107),
>>which currently resolves to "255" (which supposedly means 255 bytes).
>>
>>Is it safe to change REISERFS_MAX_NAME to something larger, or does this
>>change the disk layout in an unexpected or incompatible way?
>>
> 
> Yes. Max long name in reiserfs used to be much longer and then it was changed for compilability with something.
> I believe you can easlily change it to 3500.

Just as a data point:

http://marc.theaimsgroup.com/?l=reiserfs&m=97908551206263&w=2

The current state:

The kernel doesn't care about the length of a file name, so long as the
maximum path used to access it is below PATH_MAX (currently 4k). dirents
are dynamically sized, so there is no more 255 byte limit inside the kernel.

Glibc still defines dirent->d_name as char[256] for backward
compatibility. If the kernel supports d_reclen (which it has for a very
long time), dirents are treated as dynamically sized. Since glibc
allocates an 8k (_IO_BUFSIZE) buffer and passes it to sys_getdents,
proper bounds checking is done, and the max length is supported.

I did a quick test using your suggestion on my development machine, and
got proper results back.

- -Jeff

- --
Jeff Mahoney
SuSE Labs
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)

iD8DBQFDFARnLPWxlyuTD7IRAo1wAJ4lD9WoukhZDVNMu0vvLdAbWZgYkACfR9Zb
y3uYCK410VR/ykpWijRt5xw=
=5Tlx
-----END PGP SIGNATURE-----

  reply	other threads:[~2005-08-30  7:01 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-08-22  9:42 REISERFS_MAX_NAME and ENAMETOOLONG Xuân Baldauf
2005-08-22  9:50 ` Vladimir V. Saveliev
2005-08-30  7:01   ` Jeff Mahoney [this message]
2005-08-30  8:33     ` Xuân Baldauf
2005-08-22 13:03 ` Chet Hosey
2005-08-22 14:13 ` michael chang

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=43140467.8030704@suse.com \
    --to=jeffm@suse.com \
    --cc=reiserfs-list@namesys.com \
    --cc=vs@namesys.com \
    --cc=xuan--2005.08.22--reiserfs-list--namesys.com@baldauf.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.