When you are designing an application (assumed in English), and you ask the user to provide a path to a directory/folder, do you use the term Directory or Folder?
Is one more understood than the other? Is one more "correct" than the other?
Please note that they are not synonyms. Directories and Folders behave differently. For example, if you want to remove a File from a Folder, you need access to the Folder and the File, because the File is stored inside the Folder.
If, however, you want to remove a File from a Directory, you need access only to the Directory, because a Directory itself is just a regular File that lists the locations of (but does not contain) other Files. So, you just need to strike out that entry from the Directory, no access to the File is required.
This distinction is pretty important, because false and thus misleading metaphors can be at least confusing and in the worst case pretty dangerous when talking about filesystems. (Confusion about filesystem behaviour often translates into accidental information disclosure, data loss or security holes.)
A great percentage of questions on Unix mailinglists, but also here, on ServerFault and on SuperUser, about what to the asker seems to be confusing filesystem behaviour, can be traced directly back to thinking about Folders, when Unix does in fact have Directories.
So, in other words: use "Folder" when dealing with folders and "Directory" when dealing with directories.
In my experience, these tend to be the norm:
on Windows or any Mac OS: "Folder"
on *nix: "Directory"
The correctness of the term is wrapped up in how much your application behaves and talks like other applications on the platform, so it is best to stick with convention as to not confuse your users.
On the other hand, if the term needs to be cross-platform:
We can always use the Folder term,
because even if we use the term Folder in Linux-based platforms,
anyone knowing the technical-difference
(mentioned)
between Folder and Directory would understand that Directory was meant.
For example, in MacOS we use Folder term, while they are technically-speaking directories.
'Directory' is older and usually used on Unix-ish systems. 'Folder' is usually used on Windows. Personally, I use 'folder' even for GUI apps on both Linux and Windows, it just sounds more "user friendly". (And I doubt anyone will really care that I didn't use the "correct" term.)
If you think your users (e.g. technical users) will be happier with 'directory', use that, but otherwise, I would go with 'folder'.
Use whatever the target OS/DE uses. This definitely means "folder" on Win32, not sure about other platforms (though I think it is also definitely "folder" on OS X, and uncertain on Unix-likes). What you want is for your application to use the same terminology as all other apps, and system dialogs.
It also depends on the type of the application. For command-line applications, "directory" rather than "folder" seems to be the norm everywhere (including Win32).
The term Folder has been primary used by windows systems to make a better association to document-organization and is, as others said just another term. If you won't serve different terms for different systems, use the term Directory.
Related
We have customers who deploy our application in WebSphere. Some use Linux others Windows. To minimize testing efforts we were looking to validate the possibility of just testing on Windows.
In theory, the risk is fairly low - the "write once, run anywhere" promise of Java holds up pretty well when you keep the app server and underlying JVM constant. Here are the general areas where (in my experience, at least) you'll need to be careful across the two platforms:
Batch/shell scripts - Not something you'd need to worry about in pure Java, but in the event you've got anything scripted outside the server process, this is something to be aware of. My guess, though, is that you wouldn't be considering skipping Linux testing if you had shell scripts to worry about.
Environment variables - Talking just about OS-level environment variables; anything you define within the server config should be safe.
File/path separators - Hopefully you're careful about using variables rather than hard-coding them so this won't be an issue.
File sorting - This is a sneaky one. Windows will sort files within a directory in a predictable order. Linux will not - it can depend on the vagaries of file system settings and maybe OS levels and whatnot. In a well-packaged app, this won't matter... but if you have any duplicate classes in WEB-INF/lib or EAR/lib, and they're not absolutely identical, it can break you. Make sure that you're not including multiple versions of any dependencies, because it's possible that the contents of those /lib directories will get pulled into the class path in different orders on different OSes (or even different systems with the same OS).
Best of luck!
I would add to #Jarid list the fact that, in Windows, file names are not case sensitive and this can cause problem depending of the technologies you are using in your applications (ie JSP file names, properties files etc). In this regards, if it works on Linux, it will work in Windows but the reverse may not be truw
It happend to us...
And also the underlying JDK may have different "behavior" and also differents "bugs" depending on the platform you use
I thought that symbolic links in Windows 10 behave similarly to Linux symlinks, i.e., they are transparent to the apps. However, I'm confused by the actual behavior.
As an example, I've both softlinked and hardlinked the same CSS file:
$ mklink softlinked.css Default.css
symbolic link created for softlinked.css <<===>> Default.css
$ mklink /H hardlinked.css Default.css
Hardlink created for hardlinked.css <<===>> Default.css
The hardlink behaves predictably (is indistinguishable from the original file) but I don't understand the soft linked one. See for example this:
Also, when the CSS is consumed by the Caret editor, the hardlinked stylesheet works fine:
while the softlinked is broken:
The questions are:
How do the symbolic links actually behave on Windows?
Can soft links be made transparent to the apps? By transparent, I mean the app would always see the file as being on the symlinked path (...\symlinked.css) and never resolve to the original path (...\Default.css). Is there some Windows registry settings or something?
Symlinks are transparent to applications that are using the underlying file system, e.g., CreateFile() and friends, unless the application makes a specific effort to be aware of them.
However, they are not transparent to applications that are using the shell namespace (for example the standard Open File dialog) because the shell treats symlinks as if they were shortcuts, even to the point of modifying the displayed icon. Whether this was a sensible decision on Microsoft's part is a moot point at this stage, since it isn't about to change. So far as I'm aware, it is not configurable.
In practice this usually means that symlinks will behave transparently for non-GUI applications and for internal files (DLLs, built-in templates, configuration files, etc.) in GUI applications, but not for the user's documents.
So your first two examples (the way Explorer displays the files and the behaviour of Notepad++) are features rather than bugs; like it or not, this is the way Windows is designed to work.
Your last example does appear to be a bug (or at best an undesirable design limitation) in the application in question. It might be worth contacting the vendor.
You should also be aware that creating a symlink requires administrative privilege, and by default they don't work at all over network shares. Personally, given all these limitations, I've never found them very useful. For most user tasks I would use shortcuts instead, and for most system administration tasks junction points are more reliable.
They should be transparent to most apps but some apps are to clever for their own good.
They might pass FILE_FLAG_OPEN_REPARSE_POINT to CreateFile, or be too aggressive when "verifying" file attributes and choke on FILE_ATTRIBUTE_REPARSE_POINT.
In your specific case, I'm guessing the advanced editor should use FOS_NODEREFERENCELINKS in their open dialog. The CSS switcher might be using FILE_FLAG_OPEN_REPARSE_POINT and you should be able to verify that with Process monitor.
There is no magical registry entry you can use, you have to contact the application authors.
A file is a pointer to a certain node.
When you create a hard link you are just making a new file that points to the same node as the original file.
When you create a soft link you are not making a pointer to a node, but to a file. Because of that soft link resolves it's path to the file it points to.
Since symlink contains both it's own path and path it points to it really depends on application developers to choose which path they want to put in their UI.
How is it recommended I back up my Xcode projects? Is there a way to backup the whole thing to the web to be pulled from in case the files are somehow deleted from my computer?
Not sure which is the "best", it must surely depend on your budget, development environment, resources, time, etc etc. Here some ideas, I list them in the order of preference, starting with the FREE.
"Git" in effect creates a backup, even if strictly speaking its version control tool.
You can create and save it on your iCloud Drive, Google Drive, Sky Drive, etc etc, of course you need to manually duplicate it on a regular basis.
You can for sure get commercial tools to do this, do a google/wikipedia search, read some reviews.
"Time machine" perhaps overkill, although maybe you can tweek it to focus on your projects.
"rdist" is UNIX utility that you could setup in a "crontab" to do regular copies of files that changed, although a risky strategy.
Just use Finder to manually duplicate the entire folder, you just need to remember to do it.
For naming web folders and downloadable files, there's a standard list of characters to avoid, such as blank spaces and things like (&*#$/)|[{, etc. Are there any good reasons to carry those conventions onto your desktop and/or non-web files and folders, even if these are unlikely to be shared on the web? I'd just like to hear some reasons.
Generally speaking special characters are best to avoid unless you are using them for a reason as some of them tell windows to do specific things with the file. For instance a $ at the end of a share name will make it hidden, / could be ready by some systems as a directory break, * is a wildcard in many programming languages and may cause strange bugs with any program that has to iterate over the files, etc.
I am administering a repository for data analysis stored on the network filesystem, with three of running MsysGit in windows (1.8.4, W7). ignorecase is set to true in the repository.
Does anyone have any best practices for keeping the repository sane w/r/t the insane Windows capitalization settings?
Specifically (sort of), I have a directory that was (probably) changed from Utils, to utils, or vice versa. Now I am seeing all sorts of weird behavior. For instance, if I run
cd Utils
git log ../utils/foo.txt
I see two entries for the file (the original commit and an addition), but if I run
git log foo.txt
I only see one log entry.
I don't have any idea what is going on, and I know we will run into similar issues later, so if anyone has some wisdom to share I would very much appreciate it.
You can find one advise in "Git-windows case sensitive file names not handled properly", which reminds us of the current situation (even though you might be dealing with just Windows):
If you want to do development on multiple different platforms, you have to respect the restrictions of those platforms and you have to confine yourself to the lowest common denominator of all the platforms you support.
Windows supports ADS (Alternate Data Stream), Linux doesn't.
OSX supports resource forks, Windows doesn't.
BSD supports case-sensitivity, Windows doesn't.
So, on a FAT32/NTS case-preserving system:
Does anyone have any best practices for keeping the repository sane w/r/t the insane Windows capitalization settings?
Mainly:
chose a convention for using lower/uper cases, and stick with it,
Put a hook to detect and reject conflicting case conflicts,
set temporarily ignorecase to false if you need to change the case