Yes, it's a contrived and minor thing anyway. I happened to hit this error for having directory=. option left when filename=/path/to/file was used. 2017-06-24 1:16 GMT+03:00 Jens Axboe <axboe@xxxxxxxxx>: > On 06/23/2017 04:07 PM, kusumi.tomohiro@xxxxxxxxx wrote: >> From: Tomohiro Kusumi <tkusumi@xxxxxxxxxx> >> >> When filename= is specified in absolute path format (starts with '/'), >> being able to use directory= doesn't make much sense and also likely >> to result in an unexpected error, thus it should be ignored if any. >> >> (If combining directory= and absolute filename= is a feature rather >> than unexpected, then it should be documented, since it works as long >> as directory/filename doesn't contain invalid directory. For example, >> directory=. and filename=/tmp/xxx work as ./tmp/xxx if ./tmp exists >> as shown in below.) >> >> Not sure about the proper way to handle this on Windows, so I had to >> add WIN32 guard. > > Honestly, I'd rather just keep it as a strict concatenation of > directory+filename. People could have valid jobs or scripts that > already do variants of > > directory=/some_dir > filename=/file_in_some_dir > > and it works fine. Your example above is a bit contrived, in my > opinion. If anything, we should improve the error so it shows > the file name fio attempted to use. > > -- > Jens Axboe > -- To unsubscribe from this list: send the line "unsubscribe fio" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
