Does anyone have an example of using CfsFileDescriptor>touch:time: to change the date/times on a file?

Hi All,

Does anyone have an example of using CfsFileDescriptor>touch:time: to change the date/times on a file?  It seems simple enough but I can't get it to work.  I think I'm suppling the date/time array correctly but maybe not.  When I try  CfsFileDescriptor>touch: (without the time, which uses the current time) it works.  So, it would seem my supplied time value has something to do with it.  Thanks in advance for any help or hints.

Lou

Hi All,

Does anyone have an example of using CfsFileDescriptor>touch:time: to change the date/times on a file?  It seems simple enough but I can't get it to work.  I think I'm suppling the date/time array correctly but maybe not.  When I try  CfsFileDescriptor>touch: (without the time, which uses the current time) it works.  So, it would seem my supplied time value has something to do with it.  Thanks in advance for any help or hints.

Lou

Hi Seth,

Thanks for the fix.  The change gets us past the unknown OS error but there is still a little problem.  CfsOSTmPtr>fromDateAndTime: shouldn't subtract 1 from the #dayIndex when it sets #tmYday:.  It causes the date to be one day early.

Lou

It looks like adjustment to the size of the time_t datatype have happened over time in compilers to account for the 2038 bug.

There is more to the store for an ultimate fix, but for now, changing CfsFileDescriptor>>tm: aDateAndTimeArray to look like this should get the behavior needed.

I will open a case on this item

| time |

^(OSUInt32 new: 4)

at: 0 put: (time := (CfsOSTmPtr fromDateAndTime: aDateAndTimeArray) mktime);

at: 2 put: time;

yourself.

-- Seth Berman

On Tuesday, June 10, 2014 6:15:16 PM UTC-4, Louis LaBrunda wrote:

Hi All,

Does anyone have an example of using CfsFileDescriptor>touch:time: to change the date/times on a file?  It seems simple enough but I can't get it to work.  I think I'm suppling the date/time array correctly but maybe not.  When I try  CfsFileDescriptor>touch: (without the time, which uses the current time) it works.  So, it would seem my supplied time value has something to do with it.  Thanks in advance for any help or hints.

Lou

Hi Seth,

I forgot to ask about #date in #MZUnzFileInfo, what is it?  It is mapped to #MZTmZip.  There seems to be two dates and times here but the values I get from a zip file are very odd.  There must be something wrong with the mapping.  One of the dates seems to have a month field with a value of 2014 which is a year and a year of 0.  Some of the other parts look even worse.

Lou

It looks like adjustment to the size of the time_t datatype have happened over time in compilers to account for the 2038 bug.

There is more to the store for an ultimate fix, but for now, changing CfsFileDescriptor>>tm: aDateAndTimeArray to look like this should get the behavior needed.

I will open a case on this item

| time |

^(OSUInt32 new: 4)

at: 0 put: (time := (CfsOSTmPtr fromDateAndTime: aDateAndTimeArray) mktime);

at: 2 put: time;

yourself.

-- Seth Berman

On Tuesday, June 10, 2014 6:15:16 PM UTC-4, Louis LaBrunda wrote:

Hi All,

Does anyone have an example of using CfsFileDescriptor>touch:time: to change the date/times on a file?  It seems simple enough but I can't get it to work.  I think I'm suppling the date/time array correctly but maybe not.  When I try  CfsFileDescriptor>touch: (without the time, which uses the current time) it works.  So, it would seem my supplied time value has something to do with it.  Thanks in advance for any help or hints.

Lou

Hi Seth,

Thanks for the fix.  The change gets us past the unknown OS error but there is still a little problem.  CfsOSTmPtr>fromDateAndTime: shouldn't subtract 1 from the #dayIndex when it sets #tmYday:.  It causes the date to be one day early.

Lou

On Wednesday, June 11, 2014 11:59:11 AM UTC-4, Seth Berman wrote:

It looks like adjustment to the size of the time_t datatype have happened over time in compilers to account for the 2038 bug.

There is more to the store for an ultimate fix, but for now, changing CfsFileDescriptor>>tm: aDateAndTimeArray to look like this should get the behavior needed.

I will open a case on this item

| time |

^(OSUInt32 new: 4)

at: 0 put: (time := (CfsOSTmPtr fromDateAndTime: aDateAndTimeArray) mktime);

at: 2 put: time;

yourself.

-- Seth Berman

On Tuesday, June 10, 2014 6:15:16 PM UTC-4, Louis LaBrunda wrote:

Hi All,

Does anyone have an example of using CfsFileDescriptor>touch:time: to change the date/times on a file?  It seems simple enough but I can't get it to work.  I think I'm suppling the date/time array correctly but maybe not.  When I try  CfsFileDescriptor>touch: (without the time, which uses the current time) it works.  So, it would seem my supplied time value has something to do with it.  Thanks in advance for any help or hints.

Lou

Hi Seth,

Thanks for looking into all this.  Big picture - I'm playing with MZZipArchive and friends to zip/unzip zip files.  After unzipping and writing a file to disk I want to change the date/time info to match the file in the zip file.

I was misinterpreting the date related fields but only because I didn't look at them very carefully.  I noticed the resultant dates were off by one day (early) and just removed the -1.  Without the -1 all my tests of dates look good.

As for MZTmZip and MZZipFileInfo>>date can you please post your change here, I would like to play with it a bit.

Also, do you know what date/time MZZipFileInfo>>date is?  Is it better to use for my purposes than dosDate?

While you are looking at all this, you might want to think about adding MZUnzFileInfo>dateAndTimeFromDosDate to answer a date/time array (and maybe one for date/time from the #date field).  I have added this as an extension and since I think others could use the method, you are welcome to the code.

Lou

Hi Louis,

Did you mean #tmWday?  If so, I see that dayIndex is the day of the week...so Sunday is 1.  I see the tm struct field tm_wday is "days since Sunday" which begins at 0.

I'm assumming that's why I see the "tmWday: (aDateAndTimeArray at: 1) dayIndex - 1".  Is this how you are interpreting it?

-- Seth

On Thursday, June 12, 2014 5:11:06 PM UTC-4, Louis LaBrunda wrote:

Hi Seth,

Thanks for the fix.  The change gets us past the unknown OS error but there is still a little problem.  CfsOSTmPtr>fromDateAndTime: shouldn't subtract 1 from the #dayIndex when it sets #tmYday:.  It causes the date to be one day early.

Lou

On Wednesday, June 11, 2014 11:59:11 AM UTC-4, Seth Berman wrote:

It looks like adjustment to the size of the time_t datatype have happened over time in compilers to account for the 2038 bug.

There is more to the store for an ultimate fix, but for now, changing CfsFileDescriptor>>tm: aDateAndTimeArray to look like this should get the behavior needed.

I will open a case on this item

| time |

^(OSUInt32 new: 4)

at: 0 put: (time := (CfsOSTmPtr fromDateAndTime: aDateAndTimeArray) mktime);

at: 2 put: time;

yourself.

-- Seth Berman

On Tuesday, June 10, 2014 6:15:16 PM UTC-4, Louis LaBrunda wrote:

Hi All,

Does anyone have an example of using CfsFileDescriptor>touch:time: to change the date/times on a file?  It seems simple enough but I can't get it to work.  I think I'm suppling the date/time array correctly but maybe not.  When I try  CfsFileDescriptor>touch: (without the time, which uses the current time) it works.  So, it would seem my supplied time value has something to do with it.  Thanks in advance for any help or hints.

Lou

Hi Seth,

Everything looks good so far.  Below are the methods I've added, in case anyone is interested.  I will also submit them to tech support.

Lou

MZTmZip>dateAndTime
"Answer a two element array with our date and time."
| date time |

date := Date newDay: self day monthIndex: (self months + 1) year: self years.
time := Time fromSeconds: ((self hours * 3600) + (self minutes * 60) + self seconds).
^Array with: date with: time.

MZUnzFileInfo>dateAndTimeFromDate
"Answer an array with date and time from #date."

^self date dateAndTime.

MZUnzFileInfo>dateAndTimeFromDosDate
"Answer an array with date and time from #dosDate."
"Both MS-DOS date and time are 16-bit unsigned integers (2 bytes) which contain date or time components in different bits of a Word.
Their format is (taken from DosDateTimeToFileTime() Windows function):
date: YYYYYYYM MMMDDDDD
time: HHHHHMMM MMMSSSSS
note:
day of month is in 1-31 range
month is in 1-12 range
year starts from 1980 and continues for 127 years
seconds are not 0-59 but 0-29 (only 5 bits or 32 possible values) – to get seconds multiply field by 2
minutes are in 0-59 range
hours are in 0-23 range"

| dosDateTime year month day hour minute second dateAndTime |

dosDateTime := self dosDate.
year := ((dosDateTime bitAnd: 16rFE000000) >> 25) + 1980.
month := (dosDateTime bitAnd: 16r01E00000) >> 21.
day := (dosDateTime bitAnd: 16r001F0000) >> 16.
hour := (dosDateTime bitAnd: 16r0000F800) >> 11.
minute := (dosDateTime bitAnd: 16r000007E0) >> 5.
second := (dosDateTime bitAnd: 16r0000001F) * 2.
dateAndTime := Array with: (Date newDay: day monthIndex: month year: year) with: (Time fromSeconds: ((hour * 3600) + (minute * 60) + second)).
^dateAndTime.

I forgot that  little-endian format is required for zip.

You won't currently see an functional impact, but just to be safe, I am attaching an update.

-- Seth

On Friday, June 13, 2014 10:34:31 AM UTC-4, Louis LaBrunda wrote:

Hi Seth,

Thanks for looking into all this.  Big picture - I'm playing with MZZipArchive and friends to zip/unzip zip files.  After unzipping and writing a file to disk I want to change the date/time info to match the file in the zip file.

I was misinterpreting the date related fields but only because I didn't look at them very carefully.  I noticed the resultant dates were off by one day (early) and just removed the -1.  Without the -1 all my tests of dates look good.

As for MZTmZip and MZZipFileInfo>>date can you please post your change here, I would like to play with it a bit.

Also, do you know what date/time MZZipFileInfo>>date is?  Is it better to use for my purposes than dosDate?

While you are looking at all this, you might want to think about adding MZUnzFileInfo>dateAndTimeFromDosDate to answer a date/time array (and maybe one for date/time from the #date field).  I have added this as an extension and since I think others could use the method, you are welcome to the code.

Lou

On Thursday, June 12, 2014 5:26:59 PM UTC-4, Seth Berman wrote:

Hi Louis,

Did you mean #tmWday?  If so, I see that dayIndex is the day of the week...so Sunday is 1.  I see the tm struct field tm_wday is "days since Sunday" which begins at 0.

I'm assumming that's why I see the "tmWday: (aDateAndTimeArray at: 1) dayIndex - 1".  Is this how you are interpreting it?

-- Seth

On Thursday, June 12, 2014 5:11:06 PM UTC-4, Louis LaBrunda wrote:

Hi Seth,

Thanks for the fix.  The change gets us past the unknown OS error but there is still a little problem.  CfsOSTmPtr>fromDateAndTime: shouldn't subtract 1 from the #dayIndex when it sets #tmYday:.  It causes the date to be one day early.

Lou

On Wednesday, June 11, 2014 11:59:11 AM UTC-4, Seth Berman wrote:

It looks like adjustment to the size of the time_t datatype have happened over time in compilers to account for the 2038 bug.

There is more to the store for an ultimate fix, but for now, changing CfsFileDescriptor>>tm: aDateAndTimeArray to look like this should get the behavior needed.

I will open a case on this item

| time |

^(OSUInt32 new: 4)

at: 0 put: (time := (CfsOSTmPtr fromDateAndTime: aDateAndTimeArray) mktime);

at: 2 put: time;

yourself.

-- Seth Berman

On Tuesday, June 10, 2014 6:15:16 PM UTC-4, Louis LaBrunda wrote:

Hi All,

Does anyone have an example of using CfsFileDescriptor>touch:time: to change the date/times on a file?  It seems simple enough but I can't get it to work.  I think I'm suppling the date/time array correctly but maybe not.  When I try  CfsFileDescriptor>touch: (without the time, which uses the current time) it works.  So, it would seem my supplied time value has something to do with it.  Thanks in advance for any help or hints.

Lou