Ipad / Windows File Transfer

[RobertJasiek]

I don't because I have no need for this query:) If I did:

Method 1:

Use a search program to find in directory <path>\SGFgames\194x\ in files contents "Seigen"

Method 2:

Use a search program to find in directory <path>\SGFgames\ in files contents "DT[194" AND "Seigen"

Method 3:

- earlier, Kombilo had created its database files
- use kombilo to search for 194? dates and player name contains "Seigen"

EDITS

[John Fairbairn]

Method 1:

Use a search program to find in directory <path>\SGFgames\194x\ in files contents "Seigen"

Method 2:

Use a search program to find in directory <path>\SGFgames\ in files contents "DT[194" AND "Seigen"

Method 3:

- earlier, Kombilo had created its database files
- use kombilo to search for 194? dates and player name contains "Seigen"

None of these is guaranteed to work. Depending on your database, Go may still appear as Go Izumi in 1940. Other databases may have Wu Qingyuan or Unicode, etc.

As to dates, GoGoD often has DT[Published 194x...] Further, the original query was games "played" by Go 1940-49. There are games dated 1940 because they were published then, but were played in 1939.

Further, Seigen may appear elsewhere other than the player rubrics in the contents (eg in GC[...]).

And if the method is generalised, it also fails in cases where more than one player shares the same name.

Don't know whether meta-data can handle this problem easily.

[RobertJasiek]

Yes, I have been aware of such exceptions, but I have not wanted to enter this detail discussion here:) If I really needed to be sure not to overlook anything, I would first filter all dubios files and then check each of them manually (if necessary using a plain text editor).

[RBerenguel]

Yes, I have been aware of such exceptions, but I have not wanted to enter this detail discussion here:) If I really needed to be sure not to overlook anything, I would first filter all dubios files and then check each of them manually (if necessary using a plain text editor).

Robert, are you aware that

1. Indexed searching of meta data properties is way faster than text search, for most file types
2. Given current processor speeds, the time required for searching is way, way sHorter than the time required and cognitive overhead of maintaining a proper hierarchical folder structure?

Maybe it's just me, but I prefer to free my mind and exchange processor time for commodity. Thanks god for Spotlight.

[RobertJasiek]

1. yes, 2. yes.

Creating, managing and updating meta-data consumes the time. Creating a good folder structure can be learnt. CPU time spent on searching is trivial; the bottle neck can be the storage hardware. Unless one uses a computer mainly for searching and if one uses a good folder structure, searching or opening folders amount to peanuts.

[Bantari]

Bantari, access to the file system for application data eases access to the files. Otherwise the object name is the only simple access information. Object names would have to become much longer so as to contain what would otherwise be in the path. When all naming is in the object name, then it becomes a very time consuming burden to find an object. Maybe this is no problem as long as one has only a few objects of a type on one's computer. I have thousands to hundreds of thousands per type. Without file system, access to objects becomes impractical because gaining access consumes as much time as viewing or editing the object. It is the opposite of progress.

(The indexed Windows search also fails. Maybe it works for a few files. For my numbers of files, indexed searching is much slower than ordinary searching. Therefore I deactivate the indexing.)

I think you misunderstand what you say.

Think of Windows Explorer as a app, because this is exactly what it is, really.

It does not really give you access to the "file system" but presents the data to you in the arbitrary and abstract form of file(names) and folder(names). This has absolutely nothing to do with how the files are actually stored, which is the *real* file system or file structure. It is a rather arbitrary type of data presentation, but the only one Explorer understands. You use it because there has not really been much else to use. Just like before that you only had your DOS commands, and before that - you really had to dig into the file system manually to get your data.

Windows Explorer gives you the data in a form it thinks is easier for you, just like any app does. And just like with any app, you have no clue how the data is "really" stored, what is the "real" structure. And you don't really care, all you want is to find it, click on it, and get the data you want. The problem with Explorer is that it is a very generic app, and so it does not present the data in a view specifically tailored to the application you want or to the file type you want, but in a very generic format, one size fits all, so to say. It is vey inefficient, by definition, an does not offer any advanced functionality. All Explorer does for you could be done much much better, depending on what you need.

Some of the shortcomings of presenting data like that, using Windows Explorer, is that it is harder to find stuff. For example: it does not let you search by content of the files, only by names and folders and maybe dates. Another example - it does not let you search across multiple folders for related data unless you start with the root folder and iterate through all sub-folders, which is slow and not efficient. A well designed app can potentially accomplish things like that easily and efficiently, depending on the purpose and the data.

Bottom line:
An app can present the same information in any given form which is suitable for the given application, even in the very inefficient form Windows Explorer uses - if you want to use such app (but why would anybody?) And most apps let you organize the data in a form you want, either generic or better still - suitable for the specific application. An app can also give you more powerful search and sort tools than Explorer can ever do. In terms of data storage and manipulation, an app represents (or can represent) a much higher and more advanced level of abstraction, which potentially lets you do more complex operations. Which is good, especially if the volume of data is large, which seems to be your case.

Your problem is that you got used so much to doing stuff in the inefficient way that it is hard for you to change now.
Its a learning curve, and like with each curve, you need to slow down to navigate it. But once you are past the curve, you will see that the road is wider and straighter and you can go much faster.

[oren]

It sounds like you want an android tablet.

[RobertJasiek]

It is all programs really, but nowadays called software, crapware, malware or app;)

Physical storage -> controller -> low level files system of the operating system -> high level file system a la DOS / Windows Explorer (in its text only view) -> further optional abstraction.

"inefficient, harder": depends on how dull / cute the user, the kind of data and the user's kind of usage of the data.

That a program can present files more nicely than the Windows Explorer does not mean that every program does. In fact, many programs fail. For special purposes, special other file views can be more suitable, such as a picture explorer when the task is picture-orientated rather than picture-file-orientated.

However, do not even pretend that file type specific file management would always the be best even if all programs would handle their files perfectly. E.g., with the Windows Explorer, you can do one-click actions for all files (e.g., in a partition) of all file types and while keeping their different access rights and sandbox rights. If every file type requires an app of its own for file actions, you might need hours for what you can do in seconds with the Windows Explorer (or a command line). Windows integrates file management and security, even if there are sandboxes.

[RobertJasiek]

Android, me? No. Unrooted android security is like Windows security in the 90s (almost non-existent), except that Google and app companies grab user data more greedily and security updates tend to stop soon. Besides, Android tablets (maybe except for Nexus) tend to have a slow GUI.

EDIT:

What I want does not exist yet: Reliable 10" 4:3 matt Windows Pro 64b slate with replacable battery.

[Bantari]

Android, me? No. Unrooted android security is like Windows security in the 90s (almost non-existent), except that Google and app companies grab user data more greedily and security updates tend to stop soon. Besides, Android tablets (maybe except for Nexus) tend to have a slow GUI.

EDIT:

What I want does not exist yet: Reliable 10" 4:3 matt Windows Pro 64b slate with replacable battery.

If you want security that much, then you should not be using Windows at all. Or only from a virtualization.
Just saying...

[RobertJasiek]

Windows security is good if configured well. Out-of-the-box Windows is insufficient, but 10 times better than XP was.

[Bantari]

Windows security is good if configured well. Out-of-the-box Windows is insufficient, but 10 times better than XP was.

If you are ok to settle for that, who am I to argue.
Carry on.

[RobertJasiek]

As I have heard now, transfer of an encrypted gobook file from the Ipad to Windows is difficult but might work via the iPad backup on a Windows PC with a software to extract the app data contents, provided you can identify the files there. Otherwise, at least you get a backup of all app data.

Gobook files sent somehow (don't know about a local method yet) from a Windows PC to the iPad cannot be viewed in SmartgoBooks, but possibly in SmartgoKifu.

[oca]

Simply put :

I love my iPhone / iPad,
but I hate iTune.

I would prefer the device just exposing its file sytem for file transfert

Still :

Smart go Go book's rocks
Smart go kifu rocks
Easy go rocks
Go problems rocks
Champion Go rocks

[oren]

I would prefer the device just exposing its file sytem for file transfert

That is one reason I am much happier with my Android device. It just feels much easier to get things done.