[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: bugs in dirname module
From: |
Eric Blake |
Subject: |
Re: bugs in dirname module |
Date: |
Fri, 18 Nov 2005 00:08:01 +0000 |
> > Actually, I think that calling base_name should strip the trailing
> > slashes, similar to POSIX basename().
>
> But if you do that, you violate this basic rule:
>
> > If you have a valid file name F, then accessing F is the same as
> > chdir(dir_name(F)) followed by accessing base_name(F). Furthermore
> > if you successfully { chdir(dir_name(F)); rename(base_name(F),"foo"); },
> > you have renamed F to a file named "foo" in the same directory that F was
> in.
> If a/b is a symbolic link to a directory, then a/b/ is not the same as
> a/b and should not be treated like it. Hence base_name shouldn't
> strip trailing slashes.
OK, I missed the finer points of that on my first read. My patch
will have the malloc'ing version (whether that will be spelled
base_name or something else still remains to be seen) preserve
the trailing slashes, so that rename(base_name("symlink","foo"))
behaves differently than rename(base_name("symlink/","foo")),
along with a comment that for POSIX basename() semantics, you
must use strip_trailing_slashes(base_name()).
I guess that also means that base_len() is still useful;
base_len(base_name("symlink/")) is smaller than
strlen(base_name("symlink/")), without modifying the
resulting string.
--
Eric Blake
Re: bugs in dirname module, Eric Blake, 2005/11/17
Re: bugs in dirname module,
Eric Blake <=