[FileReference] why this class don't provide a method isAHiddenFile ?
-- Dutriez Clément dutriezcle@gmail.com 0605199489 [image: www.linkedin.com/in/clément-dutriez-407275173] <http://www.linkedin.com/in/clément-dutriez-407275173>
I imagine because it is quite a rare edge-case use and is not easy to implement: - for Linux you check for dot - for Windows you need to either modify the VM (see File class>>lookupDirectory:filename: to provide more information), or directly use WinAPI from Pharo to retrieve the hidden file attribute - for MacOS it is my understanding that you need to do both of the above and then some Peter On Thu, Aug 1, 2019 at 11:46 AM Clément Dutriez <dutriezcle@gmail.com> wrote:
-- Dutriez Clément dutriezcle@gmail.com 0605199489 [image: www.linkedin.com/in/clément-dutriez-407275173] <http://www.linkedin.com/in/clément-dutriez-407275173>
On Thu, 1 Aug 2019 at 20:51, Peter Uhnak <i.uhnak@gmail.com> wrote:
I imagine because it is quite a rare edge-case use and is not easy to implement: - for Linux you check for dot - for Windows you need to either modify the VM (see File class>>lookupDirectory:filename: to provide more information), or directly use WinAPI from Pharo to retrieve the hidden file attribute - for MacOS it is my understanding that you need to do both of the above and then some
Peter
As Peter wrote, this hasn't been requested much, but... In Pharo 8: (aFileReference entry statAttributes at: 13) anyMask: 16r2 Will answer a boolean indicating whether it is hidden or not (only on Windows). "aFileReference entry statAttributes at: 13" is the WIN32_FILE_ATTRIBUTE_DATA: https://docs.microsoft.com/en-us/windows/win32/fileio/file-attribute-constan... HTH, Alistair
It would be good to encapsulate this behavior may be with double dispatch with the platform. Else clients end up to be forced to check. Stef
On 1 Aug 2019, at 21:22, Alistair Grant <akgrant0710@gmail.com> wrote:
On Thu, 1 Aug 2019 at 20:51, Peter Uhnak <i.uhnak@gmail.com> wrote:
I imagine because it is quite a rare edge-case use and is not easy to implement: - for Linux you check for dot - for Windows you need to either modify the VM (see File class>>lookupDirectory:filename: to provide more information), or directly use WinAPI from Pharo to retrieve the hidden file attribute - for MacOS it is my understanding that you need to do both of the above and then some
Peter
As Peter wrote, this hasn't been requested much, but...
In Pharo 8:
(aFileReference entry statAttributes at: 13) anyMask: 16r2
Will answer a boolean indicating whether it is hidden or not (only on Windows).
"aFileReference entry statAttributes at: 13" is the WIN32_FILE_ATTRIBUTE_DATA: https://docs.microsoft.com/en-us/windows/win32/fileio/file-attribute-constan...
HTH, Alistair
Hi Stef, On Fri, 2 Aug 2019 at 09:19, ducasse <stepharo@netcourrier.com> wrote:
It would be good to encapsulate this behavior may be with double dispatch with the platform. Else clients end up to be forced to check.
Why do you think this might need double dispatch? My idea was that it can be added to FileSystemDirectoryEntry and subclasses (FileReference is already fairly heavily loaded, and should be kept to the basic, platform common attributes). The main reason I didn't was because most of the attributes are windows specific, and I was focusing on getting the basic behaviour working and integrated. Adding just this attribute is fairly simple. I'll submit a PR soon(ish). Cheers, Alistair
Stef
On 1 Aug 2019, at 21:22, Alistair Grant <akgrant0710@gmail.com> wrote:
On Thu, 1 Aug 2019 at 20:51, Peter Uhnak <i.uhnak@gmail.com> wrote:
I imagine because it is quite a rare edge-case use and is not easy to implement: - for Linux you check for dot - for Windows you need to either modify the VM (see File class>>lookupDirectory:filename: to provide more information), or directly use WinAPI from Pharo to retrieve the hidden file attribute - for MacOS it is my understanding that you need to do both of the above and then some
Peter
As Peter wrote, this hasn't been requested much, but...
In Pharo 8:
(aFileReference entry statAttributes at: 13) anyMask: 16r2
Will answer a boolean indicating whether it is hidden or not (only on Windows).
"aFileReference entry statAttributes at: 13" is the WIN32_FILE_ATTRIBUTE_DATA: https://docs.microsoft.com/en-us/windows/win32/fileio/file-attribute-constan...
HTH, Alistair
On 6 Aug 2019, at 12:01, Alistair Grant <akgrant0710@gmail.com> wrote:
Hi Stef,
On Fri, 2 Aug 2019 at 09:19, ducasse <stepharo@netcourrier.com> wrote:
It would be good to encapsulate this behavior may be with double dispatch with the platform. Else clients end up to be forced to check.
Why do you think this might need double dispatch?
I thought that it is specific and different on each platform.
My idea was that it can be added to FileSystemDirectoryEntry and subclasses (FileReference is already fairly heavily loaded, and should be kept to the basic, platform common attributes). The main reason I didn't was because most of the attributes are windows specific, and I was focusing on getting the basic behaviour working and integrated.
Adding just this attribute is fairly simple. I'll submit a PR soon(ish).
You see as a user I would like to be able to write. aFileReference allHiddenFiles and do not care that Iâm on windows or mac but this is probably too naive.
Cheers, Alistair
Stef
On 1 Aug 2019, at 21:22, Alistair Grant <akgrant0710@gmail.com> wrote:
On Thu, 1 Aug 2019 at 20:51, Peter Uhnak <i.uhnak@gmail.com> wrote:
I imagine because it is quite a rare edge-case use and is not easy to implement: - for Linux you check for dot - for Windows you need to either modify the VM (see File class>>lookupDirectory:filename: to provide more information), or directly use WinAPI from Pharo to retrieve the hidden file attribute - for MacOS it is my understanding that you need to do both of the above and then some
Peter
As Peter wrote, this hasn't been requested much, but...
In Pharo 8:
(aFileReference entry statAttributes at: 13) anyMask: 16r2
Will answer a boolean indicating whether it is hidden or not (only on Windows).
"aFileReference entry statAttributes at: 13" is the WIN32_FILE_ATTRIBUTE_DATA: https://docs.microsoft.com/en-us/windows/win32/fileio/file-attribute-constan...
HTH, Alistair
On Tue, 6 Aug 2019 at 12:05, ducasse <stepharo@netcourrier.com> wrote:
On 6 Aug 2019, at 12:01, Alistair Grant <akgrant0710@gmail.com> wrote:
Hi Stef,
On Fri, 2 Aug 2019 at 09:19, ducasse <stepharo@netcourrier.com> wrote:
It would be good to encapsulate this behavior may be with double dispatch with the platform. Else clients end up to be forced to check.
Why do you think this might need double dispatch?
I thought that it is specific and different on each platform.
My idea was that it can be added to FileSystemDirectoryEntry and subclasses (FileReference is already fairly heavily loaded, and should be kept to the basic, platform common attributes). The main reason I didn't was because most of the attributes are windows specific, and I was focusing on getting the basic behaviour working and integrated.
Adding just this attribute is fairly simple. I'll submit a PR soon(ish).
You see as a user I would like to be able to write.
aFileReference allHiddenFiles
and do not care that Iâm on windows or mac but this is probably too naive.
Something like this will work: aDirectoryFileReference entries select: [ :each | each isHidden ] Cheers, Alistair
I should have looked before typing :-) My memory of the FileSystemDirectoryEntry hierarchy was wrong, so it isn't as simple as I thought. But I'll still take a look at this. Cheers, Alistair On Tue, 6 Aug 2019 at 12:19, ducasse <stepharo@netcourrier.com> wrote:
Ok then this is good.
Something like this will work:
aDirectoryFileReference entries select: [ :each | each isHidden ]
Cheers, Alistair
For future reference: https://github.com/pharo-project/pharo/issues/4201 On Tue, 6 Aug 2019 at 12:01, Alistair Grant <akgrant0710@gmail.com> wrote:
Hi Stef,
On Fri, 2 Aug 2019 at 09:19, ducasse <stepharo@netcourrier.com> wrote:
It would be good to encapsulate this behavior may be with double dispatch with the platform. Else clients end up to be forced to check.
Why do you think this might need double dispatch?
My idea was that it can be added to FileSystemDirectoryEntry and subclasses (FileReference is already fairly heavily loaded, and should be kept to the basic, platform common attributes). The main reason I didn't was because most of the attributes are windows specific, and I was focusing on getting the basic behaviour working and integrated.
Adding just this attribute is fairly simple. I'll submit a PR soon(ish).
Cheers, Alistair
Stef
On 1 Aug 2019, at 21:22, Alistair Grant <akgrant0710@gmail.com> wrote:
On Thu, 1 Aug 2019 at 20:51, Peter Uhnak <i.uhnak@gmail.com> wrote:
I imagine because it is quite a rare edge-case use and is not easy to implement: - for Linux you check for dot - for Windows you need to either modify the VM (see File class>>lookupDirectory:filename: to provide more information), or directly use WinAPI from Pharo to retrieve the hidden file attribute - for MacOS it is my understanding that you need to do both of the above and then some
Peter
As Peter wrote, this hasn't been requested much, but...
In Pharo 8:
(aFileReference entry statAttributes at: 13) anyMask: 16r2
Will answer a boolean indicating whether it is hidden or not (only on Windows).
"aFileReference entry statAttributes at: 13" is the WIN32_FILE_ATTRIBUTE_DATA: https://docs.microsoft.com/en-us/windows/win32/fileio/file-attribute-constan...
HTH, Alistair
participants (4)
-
Alistair Grant -
Clément Dutriez -
ducasse -
Peter Uhnak