Skip to main content

Why no File.setHidden(boolean)?

10 replies [Last post]
cowwoc
Offline
Joined: 2003-08-24

Hi,

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?

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
podlesh
Offline
Joined: 2004-07-26

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.

cowwoc
Offline
Joined: 2003-08-24

Why can't you implement setHidden() on unix as follows?

boolean setHidden(boolean value)
{
if (value && !isHidden())
return renameTo('.' + getPath());
else if (isHidden())
return renameTo(getPath().substring(1));
else
return false;
}

that is, prefix or strip away '.' from the filename to make the file hidden or not. Seems portable to me.

alexlamsl
Offline
Joined: 2004-09-02

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?!

cowwoc
Offline
Joined: 2003-08-24

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?

alexlamsl
Offline
Joined: 2004-09-02

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.

cowwoc
Offline
Joined: 2003-08-24

Alex,

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 :)

alexlamsl
Offline
Joined: 2004-09-02

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 ;-)

cowwoc
Offline
Joined: 2003-08-24

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 :)

prunge
Offline
Joined: 2004-05-06

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.

alanb
Offline
Joined: 2005-08-08

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.