Why does the new Mustang file api have setReadable(), setWriteable(), setExecutable() but not setHidden()? isHidden() has existed since 1.2, surely you can add setHidden() as part of 1.6, no?
No, it's not portable - it's Windows only.
Unix (and unix-like) systems don't have any "hidden" attribute. By convenience, files and directories are considered hidden if their name starts with dot. java.io.File.getHidden() follows this convenience.
Why can't you implement setHidden() on unix as follows?
boolean setHidden(boolean value)
if (value && !isHidden())
return renameTo('.' + getPath());
else if (isHidden())
that is, prefix or strip away '.' from the filename to make the file hidden or not. Seems portable to me.
Not at all!
Imagine a piece of code which use setHidden() then later want to access the same file. It would be totally legitimate to assume looking under the same name - the ultimate identifier for files in any file systems. Except oops, your setHidden() call renames my file under *nix systems?!
Fine, so define setHidden() as returning a File object and null on failure. I should also point out the underlying assumption that files can be hidden and unhidden without changing their filename is implicitly not cross-platform and therefore incorrect. By returning a File object hopefully this will be made more obvious. What do you think?
I think the underlying assumption that the file name and its path pin-points the file is fine, because that's what all file systems based their design upon.
In short, *nix systems doesn't support the hidden attribute fully - they only have a workaround of having a .* naming pattern.
Anyway, to reply your proposal - tell me how I'm going to tell a normal end-user at System.out about his file. A File instance would be useless, so is the attempt to try and convince him/her that yourfile and .yourfile is two faces of the same thing, because the command line arguments etc. will need to be changed for other tasks for the end-user once the file is renamed.
I don't fully understand the last sentence, can you please rephrase it or give an example?
As far the first part of your post... As I know, .* is not a "workaround" but rather a long-established Unix standard for hidden files. Any user who has used Unix for more than five minutes should know this sort of thing, and I don't buy the argument that it would be confusing to users and they would have to be "educated" about this. This is how the operating system works, not some hack that Java is imposing on them.
So far only three people (myself included) posted about this issue. I would really like to find out what more people think about this subject, even if they disagree with me :)
It is a standard, and I do know about it. But still it is a workaround - changing the "hidden" property will alter the name of the file. So this property places additional constraints on the name of the file which I can take.
An example that it will break things is when we have says a config file for an IDE project which have the path and file name pointing to its necessary files. The moment you have (un)hide them with your little Java application, everything will cease to work.
And such behaviour would not happen on Windows, which means a discrepancy in behaviour - so chances are many Windows user will have this "wrong" assumption and make Java applications that will not work on *nixes, oh what's worse they will break your system as well!
The reason why there aren't many responses is probably due to JavaONE - so be patient ;-)
Yeah, wish I was at JavaONE too ;)
I brought up this topic on IRC and pretty much got my ass kicked :) Maybe someone has another idea on how to make this work in a cross-platform way. I give up for now :)
JSR 203 (http://www.jcp.org/en/jsr/detail?id=203) hopefully will address this and a whole lot of other issues with files and the file system. I'm hoping that it does make it into Dolphin and doesn't get pushed back again.
But as for now I agree that setHidden() should not be able to change the name of a file. Trying to run setHidden() on an OS that doesn't fully support the attribute should always fail the same way setExecutable() will always fail on FAT file systems. This doesn't mean there are no executable files on these systems just that it is not a settable attribute, like while there are hidden files on 'nix systems it is also an attribute that cannot be arbitrarily set.
As other replies have noted, the hidden attribute is FAT/NTFS specific. On Unix/Unix-like systems a file name starting with "." is just a convention and it isn't an attribute. At this time there aren't any plans to add a setHidden method to the File class. However we are currently busy with JSR-203 and that will provide efficient access to a wide range of important and well-defined attributes.
Your use of this web site or any of its content or software indicates your agreement to be bound by these Terms of Participation.
Copyright © 2015, Oracle and/or its affiliates. All rights reserved. Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective owners.