Hi Ben,

I agree, it's better to use the fixed value and not to depend on the 'stat'. 
That's why the 'if' condition checks if 'stat' is available.  But your 
suggested patch is simpler and better.

However, if we are looking for a generic solution then we could try to create a 
directory with 150 characters and if it fails then try to create another one 
with 149 characters and so on.  Like this:

longname=012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789

mkdir $longname > /dev/null 2>&1
while ! test -d $longname && test $(expr length $longname) -gt 0; do
  longname=$(expr substr $longname 1 $(expr $(expr length $longname) - 1))
  mkdir $longname > /dev/null 2>&1
done

This is not so nice since there could be several fail attempts but this could 
be used for different type of file systems with different maximum filename 
length support. What do you think? Is this "probing" acceptable in the tests? 
If it isn't, then we should use your patch.

In the generic "probing" case the patch could be:

---

Signed-off-by: Zoltán Balogh <[email protected]>

diff --git a/tests/library.at b/tests/library.at
index d5dcb12..fa39d65 100644
--- a/tests/library.at
+++ b/tests/library.at
@@ -147,9 +147,18 @@ dnl a directory fd using /proc/self/fd/<dirfd>.  We do not 
have a workaround
 dnl for other platforms, so we skip the test there.
 AT_SETUP([test unix socket, long pathname - C])
 AT_SKIP_IF([test "$IS_WIN32" = "yes"])
-dnl Linux has a 108 byte limit; this is 150 bytes long.
+dnl Linux has a 108 byte limit; this is 150 bytes long.  If filesystem
+dnl supports shorter names then let use the maximum length.
+
 
longname=012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789
-mkdir $longname
+
+mkdir $longname > /dev/null 2>&1
+while ! test -d $longname && test $(expr length $longname) -gt 0; do
+  longname=$(expr substr $longname 1 $(expr $(expr length $longname) - 1))
+  echo $longname
+  mkdir $longname > /dev/null 2>&1
+done
+
 cd $longname
 AT_CHECK([ovstest test-unix-socket ../$longname/socket socket])
 AT_CLEANUP
@@ -166,9 +175,18 @@ dnl a directory fd using /proc/self/fd/<dirfd>.  We do not 
have a workaround
 dnl for other platforms, so we skip the test there.
 AT_SETUP([test unix socket, long pathname - Python])
 AT_SKIP_IF([test $HAVE_PYTHON = no || test "$IS_WIN32" = "yes"])
-dnl Linux has a 108 byte limit; this is 150 bytes long.
+dnl Linux has a 108 byte limit; this is 150 bytes long.  If filesystem
+dnl supports shorter names then let use the maximum length.
+
 
longname=012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789
-mkdir $longname
+
+mkdir $longname > /dev/null 2>&1
+while ! test -d $longname && test $(expr length $longname) -gt 0; do
+  longname=$(expr substr $longname 1 $(expr $(expr length $longname) - 1))
+  echo $longname
+  mkdir $longname > /dev/null 2>&1
+done
+
 cd $longname
 AT_CHECK([$PYTHON $abs_srcdir/test-unix-socket.py ../$longname/socket socket])
 AT_CLEANUP

---

Best regards,
Zoltán

-----Original Message-----
From: Ben Pfaff [mailto:[email protected]] 
Sent: Tuesday, February 16, 2016 8:15 PM
To: Zoltán Balogh
Cc: [email protected]
Subject: Re: [ovs-dev] [PATCH] tests : fix tests #46 and #48 failing on some 
filesystems

On Tue, Feb 16, 2016 at 06:50:18PM +0000, Zoltán Balogh wrote:
> Hi Ben,
> 
> Sorry, I forgot the sign-off.
> 
> Signed-off-by: Zoltán Balogh <[email protected]>

Thanks.

Looking at the test more carefully, I'm not sure that it's a good idea to 
depend on the "stat" utility, which is not standardized as far as I know.  I 
think it's probably more robust to use another approach.  I sent out a 
suggested patch:
        https://patchwork.ozlabs.org/patch/583656/
What do you think?

Thanks,

Ben.
_______________________________________________
dev mailing list
[email protected]
http://openvswitch.org/mailman/listinfo/dev

Reply via email to