I am creating some files with dynamic code and dynamic content via code deployed in a Unix system. The name of the file changes when it is placed in a windows shared path.
E.G
Suppose a file name was Ämber.xml which is created in unix system where my code is deployed. After the file creation is finished, it is placed in a windows shared path folder. In the windows shared path folder when I look at the file, the content is perfect but the name changes to Ãmber.xml. So the Ä changes to Ã.
Could you please provide me a solution to this? Thank you.
This is ultimately because an UTF-8 filename is interpreted as ISO (or another non-unicode) encoded string.
Probably the filename encoding is not configured correctly on the Unix system (or a buggy driver is used for mounting), so I'd try checking the mount options for the share. Details vary depending on the OS ("Unix" is pretty general).
Related
I have three separate Linux servers that mount and share the same single file system under a directory called /efs
I have a Java application that uses this file system, and needs to be able to verify that the file system has been mounted correctly (Or else, it would simply write to /efs on the local machine instead of the shared storage without knowing) - How would I detect at run time from my application that the file system has been mounted to the directory?
Sorry if this is a duplicate question. I really did try to find information on this but I couldn't find a clear answer.
I see a few approaches to this problem:
If the mounted filesystem at /efs is different from the root filesystem, you can compare them using Files.getFileStore(path).type(). The filesystem for / being the same would then be a clear indicator that the /efs mount is missing. This assumes JDK >= 7.
Read and parse /proc/mounts to see which file systems are mounted and with which options. This is the same data source Java's FileStore API uses under the hood, so you might take the parsing logic directly from the JDK sources. This would be independent on the Java version.
Have a file on the mounted filesystem which is never on the root filesystem which can then be checked for simply by Files.exists(path) or new File(path).exists(). This would be independent from the Java version and even independent from Linux.
Answering my own question - It just occurred to me to create a file in the mounted file system and simply check the file exists avoiding any OS dependent code.
I have a file on linux ubuntu server hosted with path name /home/kishor/project/detail/.
When I made a web app in window to upload and download file from specified location i used path "c:\kishor\projects\detail\" for saving in window.
For my surprise when i used window file path name in my server i am still able to get files and upload them, i.e, "c:\kishor\projects\detail\".
Can anyone explain why it is working (as window and linux both use different file path pattern).
I've seen this work too. What linux does is create a file whose name is literally c:\kishor\projects\detail\
If you say, you can "upload" files... perhaps there is now a new folder structure.
Some months ago i saw a similar thing: Under /home/webadmin was an new structure "/c:/Users/...."
I have a Java app which I am packaging to a Mac Application Bundle (That folder structure that contains all of the app but looks like a single executable file to the user).
My Problem:
I am reading and writing some config files in the local folder ("."). However, on Mac this seems to be the folder in which the application bundle is located (so usually the "Applications" folder and I obviously don't want that.
My question:
How can I store a file inside that bundle? How can I programmatically retrieve the bundle name to compute the fully qualified folder?
I know I could try to go the ClassLoader way, but I'd like to avoid that (for security reasons).
Or is there simply a better way how to store application cache and config data locally?
The Mac OS X Finder treats any directory whose name ends in .app as an application; right-click to Show Package Contents. It remains an otherwise normal directory for I/O purposes. This project is an example. See this answer regarding paths relative to the application bundle.
Addendum: Is there a better way how to store application cache and config data locally?
The example cited uses java.util.prefs.Preferences, but javax.jnlp.PersistenceService is an alternative.
Ok, the basic answer / solution is: don't do it.
The reason I originally wanted to do it was to cache larger amounts of data on the local HD. Java preferences are a good choice for config data (i.e. small data amounts) but fail to handle data in the megabyte size range.
My solution:
On MacOSX (System.getProperty("os.name").contains("Mac OS X")) I simply create a folder in the user's home folder (System.getProperty("user.home")). I prefix that folder with a . to ensure it is hidden from the user. This also ensures that I have write access to the folder (which could be a problem in the .app folder depending on where the user copies it)
On Windows (System.getProperty("os.name").contains("Windows")) I create that folder in the System.getenv("APPDATA") directory (note that this env variable only exists on Windows systems.
Now I have full access to the filesystem (even without admin rights) and can store as much data as I like.
Is there a way of accessing the current script's absolute physical path via a variable/property? There doesn't appear to be anything listed via a Debug Sampler.
It's incredibly annoying that actions like loading CSV files and JMX Includes uses the current working directory as its relative path.
I used the answer provided by haridsv. It worked great except that I needed to put the directory to the JMX file in a variable. I made a "User Defined Variables" component and used BeanShell in the variable's "Value" field like this:
${__BeanShell(import org.apache.jmeter.services.FileServer; FileServer.getFileServer().getBaseDir();)}${__BeanShell(File.separator,)}
The first BeanShell section calls the Java class that gets the directory in question. The second appends a file separator to the path, which is of course optional.
Include Controller
As per component's reference:
This element does not support variables/functions in the filename
field.
However, if the property includecontroller.prefix is
defined, the contents are used to prefix the pathname. If the file
cannot be found at the location given by prefix+filename, then the
controller attempts to open the fileName relative to the JMX launch
directory (versions of JMeter after 2.3.4).
You can pass JMeter a java property named includecontroller.prefix
which can be used to prepend a directory to the JMX file you're
including.
1) In case of console launch use:
-Jincludecontroller.prefix=/full/path/to/jmx/scripts/dir/
2) in case of GUI - add the same to .sh/.cmd/.bat file or write a wrapper file;
3) in case of Jmeter Ant Task usage - set as separate property:
<jmeter
jmeterhome="${jmeter.home}"
testplan="..."
resultlog="...">
<property name="jmeter.save.saveservice.assertion_results" value="all"/>
<property name="jmeter.save.saveservice.output_format" value="xml"/>
<property name="includecontroller.prefix" value="..."/>
</jmeter>
CSV Data Set Config
As per component's reference:
Relative file names are resolved with respect to the path of the
active test plan.
Absolute file names are also supported, but note
that they are unlikely to work in remote mode, unless the remote
server has the same directory structure. If the same physical file is
referenced in two different ways - e.g. csvdata.txt and ./csvdata.txt - then these are > > treated as different files. If the OS does not distinguish between upper
and lower case, csvData.TXT would also be opened separately.
You can declare a test plan variable that retrieves parameter value with the folder containing csv data files:
e.g.csv.path | ${__P(csv.path, ${__property(user.dir)}${__BeanShell(File.separator,)})}
CSV Data Set Config
Filename = ${csv.path}${__P(users-list,)}
Setting from console:
-Jcsv.path=/full/path/to/csv/data/dir/
Setting for distributed testing setup:
-Gcsv.path=/full/path/to/csv/data/dir/
By saying "current script's absolute physical path", I am guessing OP is referring to the location where the testplan (jmx file) is loaded from. I needed exactly this to generate a CSV file from BeanShell script at the beginning of the run, which is subsequently used in a CSV Data Set Config to read back, so I wanted the script to work just like how the later works when no path is specified. I went through the JMeter source and found this working solution:
import org.apache.jmeter.services.FileServer;
log.info(FileServer.getFileServer().getBaseDir());
I tested this and saw the correct path in the jmeter.log.
My particular issue was that my relative Include Controller path included a backslash which broke on Linux and OSX.
The solution was to use a forward slash in relative paths, which works on all platforms.
From the File class JavaDoc:
An abstract representation of file and directory pathnames.
User interfaces and operating systems use system-dependent pathname strings to name files and directories. This class presents an abstract, system-independent view of hierarchical pathnames.
Why is the method .isAbsolute() platform dependant? (return different result for /tmp on Win and Linux) and doesn't check if the file is absolute either or Linux or Windows? How can the File class guess which platform's file I am trying to represent via the File in my code? I am not necessarily representing local file system's file.
It has to have some idea of which platform you're interested in, and the current platform is a pretty good guess!
On Linux /tmp is absolute. On Windows it isn't - it's relative to your current drive.
I am not necessarily representing local file system's file
Then you should not use File, File provides easy access to the local filesystem and is not meant to represent non-local resources.
There are other System independent classes like URI and URL you should use instead(URL has some design flaws so prefer URI).