VfsFile : support for atime,mtime,ctime

Agreed, but this will require all instances of VfsFile? do the same (Zip, FTP, etc), at the same time (unless you cast the VfsFile? interface to a specific class instance).

Are you up for changing the ZipFolder? and FtpFolder?, larsivi?

I wrote FtpFolder? and there's a problem, FTP has support for mtime and ctime but not atime. What should be the standard way to handle this? I have 3 proposals: 1: return mtime 2: throw an exception 3: access it now and return the time it is now

Also since those functions haven't yet been added to the interface, how would they be defined? Time ctime(); Time atime(); time mtime(); ?

What if we don't support them in the interface, should we write the methods and make them public so that when someone casts from VfsFile? to FtpFile? it will now give access to those methods? In this case I believe casting from VfsFile? to any Vfs Adapter file type will work but it would be ugly to call even file system files FtpFile? when you have something else for it but what if you don't know what it is until runtime........... Should we create a GenericAdapter? for this in case of you don't know which you are using and don't want to create misunderstandings by using FtpFile? everywhere even if it is another Vfs adpater file type?

These are questions to consider............ I won't put my FtpFolder? with these methods into the branch until this is decided because I want all the VfsFile? interfaces to match and not have unstandard behaviour.

Lester L. Martin II

They would need to go into the interface, meaning that all implementations would have to support those methods.

The methods themselves should return a Time instance, in the same manner that tango.io.FilePath? does. I think the bigger question should whether to make three separate calls for this info, or bundle it into one like tango.io.Path does with the Stamps struct. It would be a shame to make three remote FTP calls to get all that info when just one would suffice.

I believe we should first support the Stamps struct as tango.io.Path does, and then see if we need to expose convenience methods on top of that at some later point.

I will see what can be done about the ZipFolder? in Daniel's absence.

And why not using in addition methods like bool atime_support() , bool ctime_support() , bool mtime_support() ?

do you mean, test if the feature is supported?

If so, Tango takes the stance that either an general API is supported on all platforms, or not at all. For those grey areas between, we use explicit modules within tango.sys.xyz, in order to make it abundantly clear there's something platform specific happening.

In particular, Tango does not expose anything in any interface that is not expected to be cross-platform. VfsFile is an interface :)

If you meant something else, would you mind explaining a little further please?

Replying to kris:

do you mean, test if the feature is supported?

Yes, it enable a way to know if the filesystem hook a kind of time or not.

If so, Tango takes the stance that either an general API is supported on all platforms, or not at all. For those grey areas between, we use explicit modules within tango.sys.xyz, in order to make it abundantly clear there's something platform specific happening. In particular, Tango does not expose anything in any interface that is not expected to be cross-platform. VfsFile is an interface :)

But is it really a cross-platform problem ? I think it's rather a supplementary information on the underlying fs to avoid the danger of the use of wrong datas.

yeah, sorry ... I actually meant cross-implementation from the VfsFile? interface perspective. Doh!

Hmm, accessed will be the odd one out here, as it is a value that isn't likely to be present for read-only FS'es, and obviously not in writable FS'es like FTP either. Maybe the interface only should have modified and created?

But what could be done in the case of a FS which, too, has no support for ctime (zip file for example) or mtime ? Of course, the other and more simple way is to use the value of an other date, but this date is , in my point of view, an inexacte date. But maybe, it's the price of a simple interface.

I'm a newbie in Tango and D, so the politicals chooses are ... not for me ;) The choose is your's.

I think we should first take a look at what aspects of this each instance of VfsFile? can actually support (ftp, zip, etc), implementing as we go. Assuming there's some overlap, we'd add that to the VfsFile? interface