This sounds like a bug that should be fixed in tramp, not in JDE.
Directory *entry* length maximums are file system dependent too, which
means that a correct implementation of this hack would require looking at
the different filesystems that can be mounted on unix and windoze (both of
which can be nfs clients, of course, and so can mount other filesystems
through NFS or natively). A quick look at the header files on my linux
machine (which includes ufs_fs.h known to work with Solaris and HP/UX,
as well as ext{2,3}_fs.h, reiser_fs.h etc.) shows that 255 is a popular
(smile) maximum length for directory entries.
If the question being asked is "what's the longest legal *path* name" --
well, on unix that can be very, very large. I don't know how big exactly,
but you can definitely create paths that are much bigger than the thread
below would allow. To illustrate: I ran this script on my linux machine
(ext2 filesystem). Starting at /home/eric, it happily created a directory
structure /home/eric/0/1/2/3/../4096. Note also that it had no trouble
traversing the structure as it went. Note also that each of the nodes
in this path *could* have been up to 255 characters long. In sum,
(255 * 4097) > 100.
Obviously this is an edge case (although anyone with ClearCase experience
knows that you can end up dealing with some mighty big pathnames once
you start poking around in mvfs' "view extended pathnames"), but I
think it shows why it would be better to solve this problem through some
other means. Perhaps the original poster could describe the specific
issue with tramp in more detail? Perhaps the folks on the tramp mailing
list could be enlisted to help resolve it?
#!/usr/bin/perl
for my $n (0 .. 4096) { # upper limit chosen at random (note: *inclusive*)
system 'mkdir', "$n";
if ($?) { exit 1; }
chdir $n;
}
In message <[EMAIL PROTECTED]>, Paul Kinnucan writes
:
:
: Can anyone help with the question raised in the following
: thread?
:
: Paul
:
: Jose M Vidal writes:
: >
: > Yup, 100 is a hack that works for me. I don't know what the actual
: > maximums are.
: >
: > On the other hand, we just need to pick a number bigger than the most
: > unreasonably long file name but smaller than infinity. Hmmmm. What is
: > 1024?
: >
: > Sorry,
: > Jose
: >
: >
: > On Mon, 22 Oct 2001, [EMAIL PROTECTED] wrote:
: >
: > > Jose M Vidal writes:
: > > >
: > > > jde 1.17 will not work with tramp because of the way it keeps
: > > > trying to go up the directory hierarchy assuming ange-ftp
: > > > usage. It would get into an infinite loop. I fixed this by simply
: > > > constraining the length of the directory to 100 characters. I
: > > > think this makes the code much
: > >
: > > Hi Jose,
: > >
: > > Why did you choose 100 characters? How do you know that there won't
: > > be a valid path somewhere that is more than 100 characters.
: > > I'm very leery of hacks like this based on someone's estimate
: > > of what is a "reasonable" maximum for some value. I'd rather have
: > > the maximum be greater than the maximum of the maximum paths
: > > supported by Windows and Unix. Is there such a maximum? I vaguely
: > > recall reading somewhere that the limit for Windows paths is
: > > 256 characters. If Unix and Windows have constraints on path sizes,
: > > I'd be much more comfortable adopting this hack.
: > >
: > > - Paul
: > >
: > > > more robust. Here is the changed function (from jde.el):
: > > >
: > > >
: > > > (defun jde-find-project-file (dir)
: > > > "Finds the next project file upwards in the directory tree
: > > > from DIR. Returns nil if it cannot find a project file in DIR
: > > > or an ascendant directory."
: > > > (let ((file (find jde-project-file-name
: > > > (directory-files dir) :test 'string=)))
: > > > (if file
: > > > (expand-file-name file dir)
: > > > (if (< (length dir) 100)
: > > > (if (not (jde-root-dir-p dir))
: > > > (jde-find-project-file (concat dir "../")))))))
: > > >
: > > > Cheer, and thanks for a *great* product,
: > > > Jose
: > > >
: > > > --
: > > > Jose M. Vidal <[EMAIL PROTECTED]> http://jmvidal.cse.sc.edu
: > > > University of South Carolina http://www.multiagent.com
: > > >
: >
: > --
: > Jose M. Vidal <[EMAIL PROTECTED]> http://jmvidal.cse.sc.edu
: > University of South Carolina http://www.multiagent.com
: >
:
